It’s my first time deploying Trellis to DigitalOcean. Everything seems to be going fine, except i’m receiving the following message going to my droplet’s IP: 146.185.132.84 didn’t send any data. ERR_EMPTY_RESPONSE
Reading up it seemed perhaps it had to do with SSH agent forwarding (which i’m not familiar with). I followed this tutorial and the response seemed fine.
Locally: You've successfully authenticated...
On the server: You've successfully authenticated...
I agree with @ben
Given that I had most of this typed, I’ll still send it along…
If you’re saying you’ve run server.yml and deploy.yml then you point your web browser at your IP and get an empty response, I speculate that it is because your Nginx isn’t configured to process requests to the IP name, only the domain name. Here are the site_hosts for which your server will process requests. By default, this doesn’t include the IP.
Ultimately, you’ll want to connect using a fqdn once you have DNS set up. If that is not yet set up, I’d recommend making an entry in your local machine’s /etc/hosts 146.185.132.84 mydomain.com
then point your browser at mydomain.com instead of the IP.
Maybe it would work to add the IP to the site_hosts list (but I vaguely remember that may have other issues with css/js relative paths not resolving).
Thanks guys, for the quick help. I get what the problem is now: using the IP.
I did not, i’m using the droplet’s IP, which, I believe now, is causing the issue.
Indeed I would. Normally before I would put a site live, I want to have it running on an IP to test and show clients (after the local build).
What would be your workflow to test a site live without having to use the actual domain?
Hopefully you are able to help me adjust my strategy.
If you’re showing the client the site on your machine, you could use the approach I mentioned of adding a temporary entry to your /etc/hosts. But more likely, you want enable the client to visit the site on their own devices and you don’t expect them to mess with /etc/hosts.
There could be many approaches, but if I had to do it right now, I’d set up DNS to point staging.mydomain.com to a different IP, for a new staging droplet (e.g., IP in hosts/staging). I’d ask clients to visit staging.mydomain.com to preview the site (and to preview ongoing changes after the site is launched). This staging site shouldn’t be indexed by search engines if you’re using bedrock (here’s why), but you may still want to put the staging site behind basic auth like in “Bedrock site protect” here.
Of course, when you’re ready to launch, add a DNS entry to point mydomain.com to your original IP (e.g., IP in hosts/production). You end up with staging and production on different droplets, different IPs, which gives you good flexibility in development. You can do anything you want to your staging server without affecting your production server.