Bleh, this is embarassing. Node in my bottom-tier Lightsail instance is unable to handle the traffic (big surprise) and now I'm starting a bigger instance from

Bleh, this is embarassing. Node in my bottom-tier Lightsail instance is unable to handle the traffic (big surprise) and now I'm starting a bigger instance from a snapshot. In response to some of the comments: 1. I absolutely agree that knowing exactly what something does line by line is much better than "magic". But that's the thing, if you know Caddy as much as you know Nginx, you'd be able to explain every single one of those 4 lines: > blog.kixpanganiban.com Because I didn't bind it specifically to a port (didn't add :80 or :443), I know that Caddy will automatically serve it over HTTPS for me and bind it to both. I could have written `blog.kixpanganiban.com:80` instead if I wanted it to be HTTP-only, or even `http://blog.kixpanganiban.com/blog/` http://blog.kixpanganiban.com/blog/` if I wanted to serve it on the `/blog` path. > proxy / localhost:2386 { Pretty self-explanatory, it proxies all requests to `/` to the `localhost:2386` (Ghost) backend. I could attach a list of backends to make it act as a load-balanced reverse proxy similar to nginx, like so: `proxy / localhost:2375 somesite.com:2312 {`. > transparent Caddy configs call this a "preset", basically a shorthand for: header_upstream Host {host} header_upstream X-Real-IP {remote} header_upstream X-Forwarded-For {remote} header_upstream X-Forwarded-Proto {scheme} 2. I'm not trying to sell snake-oil, I'm trying to introduce a perfectly good alternative which I've been meaning to try for a while. Also, Caddy docs: https://caddyserver.com/docs/ https://caddyserver.com/docs/