I realised one day that I was spending more time maintaining reverse proxies than the applications behind them. Every new service meant another server block. Another certificate renewal to think about. Another opportunity to mistype a configuration directive and spend twenty minutes wondering why a perfectly good site had started returning a 502 error.
None of it was difficult. It was just repetitive. Then I started experimenting with Caddy. It didn’t take long before every new project I built started with Caddy instead of nginx.
HTTPS became someone else’s problem
The feature everyone talks about first is automatic HTTPS, and for good reason. Point a domain at your server, write a simple configuration, and Caddy requests and renews certificates automatically. No cron jobs. No Certbot. No renewal scripts. No wondering whether a certificate is going to expire while you’re away for the weekend.
That alone removes one of the most common maintenance tasks on a small server. You still need working DNS and firewall rules, of course. Caddy doesn’t remove the fundamentals. It just handles the certificate management cleanly once those pieces are in place. After using it for a while, manually managing certificates starts to feel like unnecessary work.
The configuration is refreshingly simple
A basic reverse proxy in nginx often involves a server block, several proxy headers, SSL configuration, logging directives, and a handful of settings that get copied from one configuration file to the next. The same thing in Caddy is often just a few lines.
The configuration reads more like a description of what you want than instructions for how to build it. That makes it much easier to come back six months later and immediately understand what’s happening. I spend less time reading documentation and less time searching old configuration files for something I know I’ve already done once.
Reverse proxying just works
Most of what I host is fairly ordinary: internal web applications, self-hosted services, monitoring dashboards, documentation, a handful of applications exposed securely to the Internet. Caddy handles those jobs extremely well.
WebSockets work. HTTP-to-HTTPS redirects happen automatically. Headers are sensible by default. Configuration changes are straightforward enough that I rarely need to keep a reference guide open beside me. For the vast majority of homelab and small business workloads, that’s exactly what I want.
The defaults are surprisingly good
One thing I’ve grown to appreciate is how much Caddy does without asking. It assumes secure defaults. It enables modern TLS. It handles certificate renewal. It compresses responses where appropriate.
Instead of building a secure configuration from dozens of options, you’re mostly deciding what behaviour you want. That’s a very different philosophy from nginx, which gives you tremendous flexibility but expects you to assemble many of those pieces yourself. Neither approach is wrong. One simply requires more effort.
nginx is still incredibly capable
None of this makes nginx obsolete. There are still situations where I’d reach for it. Its ecosystem is enormous. There are years of documentation, tutorials, and community examples available. If you’re running highly customised configurations, advanced load balancing, complex caching rules, or specialised modules, nginx still has advantages.
It’s also the platform many experienced Linux administrators already know inside and out. If you’ve built years of operational knowledge around nginx, there may not be a compelling reason to change.
But most people don’t need all of that
Most people running a homelab aren’t operating infrastructure at Internet scale. They want a reverse proxy that’s secure, reliable, and easy to understand. The fewer moving parts, the better.
When I help someone troubleshoot a self-hosted application, I want to eliminate variables wherever possible. A simpler proxy configuration means fewer places for mistakes to hide. That’s valuable whether you’re hosting one application or twenty.
Less maintenance means more building
Infrastructure should quietly do its job. The reverse proxy shouldn’t become the most interesting part of the environment. Since moving to Caddy, I spend less time maintaining certificates, less time debugging configuration files, and less time thinking about the proxy layer in general. That’s exactly what I wanted.
If you’re already comfortable with nginx and it’s doing everything you need, there’s no urgent reason to replace it. But if you’re building a new server, a fresh homelab, or a small self-hosted environment, I’d seriously consider starting with Caddy instead. You’ll probably spend more time working on the services you actually care about, and less time maintaining the software that sits in front of them.
Questions or corrections? info@mb-networks.ca