Caddy Web Server: Where 'Easy' Gets Complicated

Christian Lempa heard what I've been hearing for years: use Caddy, it's so much easier. After watching him put it through its paces in a recent video, I can report that both claims are true. It is easier. And the question of whether that matters depends entirely on what you're trying to do.

Caddy is a single binary that handles web serving and reverse proxying with automatic TLS certificates from Let's Encrypt. No complex configuration files. No certificate renewal scripts. Lempa spins up a VPS, installs Caddy via package manager, edits three lines in a config file, and has a working HTTPS site. The entire process takes minutes.

"It's really ridiculously easy and simple," Lempa says in the video. "Just a single binary that you can run or install on your server. Add a few lines of configs and you've got yourself a fully working web server and reverse proxy and it's all protected with automatic TLS certificates."

For basic deployments, this is accurate. Point a domain at your server, tell Caddy which directory contains your site, reload the service. Caddy handles certificate acquisition, renewal, and configuration automatically. Lempa demonstrates this with both a static site and a Portainer instance running in Docker. The config file is readable by humans who aren't systems administrators.

Compare this to nginx, which I've watched grow from a niche performance tool to the default choice for reverse proxies over the past two decades. Nginx is powerful and flexible, but you pay for that flexibility in configuration complexity. Getting HTTPS working properly requires understanding certificate chains, renewal mechanisms, and about fifteen different directives. Caddy handles all of this invisibly.

The automatic HTTPS works through Let's Encrypt's HTTP-01 challenge. Caddy requests a certificate, Let's Encrypt checks that you control the domain by making a test connection to your server on port 80, and if everything checks out, you get your certificate. Lempa walks through this process clearly, noting the specific requirements: a registered public domain, external access to ports 80 and 443, and DNS records pointing to your server's IP.

These requirements are where "easy" starts developing asterisks.

If you're running Caddy inside a private network—common in homelab setups—the HTTP-01 challenge won't work. You can't allow public connections to verify domain ownership. The solution is DNS-01 challenges, which verify ownership by checking DNS TXT records instead of making HTTP connections.

Caddy supports DNS-01 challenges. It just doesn't include them by default. You need to rebuild Caddy from source using xcaddy, a build tool that compiles custom versions with specific DNS provider modules. Lempa demonstrates this process: install Go, install xcaddy, find your DNS provider's plugin from a community repository, compile a new binary with that plugin included.

"What I personally don't like so much about this and what I think is not very easy and not very straightforward is just rebuilding the caddy packages using Xcaddy," Lempa says. He understands the reasoning—including every DNS provider module would bloat the binary unnecessarily—but notes it creates friction for a common use case.

This is a legitimate design trade-off, not a failure. The Caddy developers prioritized simplicity for the majority use case: public-facing servers with standard HTTP challenges. Users with more complex requirements need to do more work. That's defensible. But it does mean "easy" has boundaries.

The Docker deployment reveals similar tensions. Caddy has an official Docker image and recommended compose configuration. Lempa sets it up, mounts the config file and site directory as volumes, starts the container. Everything works. Then he points out the problem: every time you want to expose a new application, you edit the Caddy config file and restart the container.

Traefik, by contrast, supports Docker labels that let you define routing rules in the application's own compose file. Add a container, add its labels, Traefik picks it up automatically. No central config file to maintain. Lempa's point is that Caddy's simplicity in one area—static config files—creates complexity in another area—dynamic container environments.

The video ends mid-sentence, but Lempa's position is clear enough: Caddy delivers on its promise for straightforward deployments. If you're hosting a few sites on a VPS with public IP addresses and standard domain configurations, it removes real friction. The automatic HTTPS alone justifies the choice.

But environments with locked-down networks, frequent container deployments, or non-standard certificate requirements will encounter limitations. Not bugs—limitations. The tool was designed to excel at specific tasks, and that design produces both strengths and constraints.

I've covered enough technology cycles to recognize what's happening here. Caddy simplifies the common path aggressively, which creates a genuinely better experience for users on that path. Users off that path discover they're doing more work than they expected. Both groups are correct in their assessments.

The question isn't whether Caddy is easy. It's whether Caddy's easy path aligns with your path. Lempa's testing suggests that for public-facing servers with straightforward requirements, the answer is yes. For everything else, you're trading one kind of complexity for another.

—Bob Reynolds, Senior Technology Correspondent