Caddy vs Nginx

Caddy gets a TLS certificate from Let's Encrypt automatically the first time it serves a hostname, and it renews on its own. You write a hostname and a reverse-proxy target, and HTTPS just happens. For a homelab where you are putting a dozen apps behind clean URLs, that removes the single most annoying recurring chore.

Nginx does not do this on its own. You pair it with certbot to obtain and renew certificates, which works well and is thoroughly documented, but it is another moving part to set up and keep healthy. If your reason for running a reverse proxy is mostly to get HTTPS in front of your apps, Caddy is doing that job for you out of the box.

A Caddyfile to proxy an app is a few lines, and HTTP/3 is on by default. The syntax is readable and hard to get badly wrong. That simplicity is exactly what you want for a homelab full of small services.

Nginx config is more verbose, but that verbosity buys precision. Twenty years of Stack Overflow answers and production configs mean almost any routing, caching, or rewrite scenario already has a documented solution you can copy. If you need fine-grained control or an unusual setup, that depth is worth a lot.

At homelab scale, both are far faster than your workload needs, so performance is not the deciding factor for most people. At the extreme high end, serving very high request rates, Nginx still edges ahead and uses less memory, which is why it remains a default in front of large production sites.

For a self-hoster, the honest framing is this: Caddy saves you time on the common case, and Nginx is the tool to grow into if you hit a specific need it serves better. Many people run Caddy as the main reverse proxy and only reach for Nginx when a particular app or performance requirement calls for it.

The reason people fall for Caddy is how little config it takes. Proxying an app behind HTTPS is three lines: the hostname, the reverse_proxy directive, and the address of the app. Caddy fetches and renews the certificate, redirects HTTP to HTTPS, and turns on HTTP/3, all without you asking. Add a second app and it is three more lines.

The equivalent in Nginx is a server block plus a separate certbot setup to get and renew the certificate, plus the HTTP-to-HTTPS redirect written by hand. None of it is hard, and there are a thousand examples to copy, but it is more moving parts to keep healthy. For a lab full of small services, those parts add up.

If you run everything in Docker, also look at Traefik, which discovers containers by their labels and configures routes automatically. The rough split: Traefik for dynamic container environments, Caddy for a simple static config you can read at a glance, and Nginx when you need its depth or raw performance.