Caddy for Automatic HTTPS Reverse Proxying

Caddy is the reverse proxy that removes the two most annoying parts of running a site: obtaining certificates and remembering to renew them. Point its Caddyfile at a domain and Caddy fetches the certificate automatically, serves HTTPS, and proxies to your app — with the certificate renewal handled silently for the life of the site. For a single VPS running a handful of services, the configuration cost is close to zero.

How the automatic bits work

When Nginx sees a server_name it still needs a certificate from somewhere else. Caddy inverts this: the server_name is also the certificate name. Caddy talks to the certificate authority over HTTP and DNS to prove domain ownership, stores the key material, and sets up the renewal timers itself. The magic only works when two conditions hold: the domain must actually point at your server's public IP, and ports 80 and 443 must be reachable from the internet. If either is missing, the first load will fail with a clear error.

The entire config for one site

A reverse proxy that terminates TLS and forwards to a local app is four lines in a Caddyfile.

green.example.com {
    reverse_proxy 127.0.0.1:3000
}

That is the whole file. The directive reverse_proxy sets all of the headers upstream services expect, including X-Forwarded-For, and Caddy picks sensible timeouts. Start Caddy, open the domain, and you get a valid certificate with no manual steps in between. There is no file watching or reload ceremony — Caddy picks up Caddyfile changes automatically, though reloading on a schedule is still fine.

Two sites on one Caddyfile

Multiple apps share a single Caddy process; each site is just another block.

api.green.example.com {
    reverse_proxy 127.0.0.1:8001
}

app.green.example.com {
    root * /srv/app
    file_server
    reverse_proxy /api/* 127.0.0.1:8001
}

The second block shows a common pattern: static files are served by Caddy itself with file_server, while paths under /api are proxied to the backend. Order matters in a different way than it does in Nginx — directive matchers like the leading path are the way you steer traffic, and Caddy logs a warning if the same path appears twice.

Managing the service

Caddy ships official packages that register a systemd unit, so lifecycle management is boring in the best way.

systemctl enable --now caddy
systemctl reload caddy
journalctl -u caddy -e -n 40

The reloads are graceful, and the journal is where you will find certificate errors, DNS problems, and upstream connection failures explained in plain text. If a certificate cannot be obtained, the log line usually tells you why — a blocked port or a DNS record that has not propagated.

Takeaway

If you would rather spend your afternoon on the application than on certificate plumbing, Caddy is the faster path. One block per site, automatic renewal, and graceful reloads mean the proxy part of your stack quietly looks after itself. Install the official package on a Netbay VPS, drop a Caddyfile together, and watch the HTTPS certificate appear on first request — netbayhosts.in has an instance ready in under a minute.