Caddy Web Server: Why Developers Are Ditching

There's a specific kind of panic that comes with production systems going down at 5 a.m. DevOps Toolbox creator Omer experienced it firsthand in August 2016 when an expired wildcard SSL certificate paralyzed his entire infrastructure. "One manual avoidable task paralyzed our entire infrastructure," he recalls in his latest video exploring Caddy, the web server that's quietly accumulating devotees.

The pitch is straightforward: a server that handles SSL certificates automatically, configures itself with minimal syntax, and doesn't require you to become a configuration file archaeologist. After spending 30 days stress-testing Caddy—pushing it through load tests and production Kubernetes clusters—Omer's verdict suggests this might be more than hype.

The Certificate Problem Nobody Talks About

SSL certificate management is one of those infrastructure tasks that's simultaneously critical and tedious. Miss a renewal, and you're explaining to executives why the company website is serving browser warnings. Automate it poorly, and you're debugging certificate chains at 3 a.m.

Caddy's approach: just handle it. No Let's Encrypt plugins to configure, no cron jobs to maintain, no manual renewal processes. The server obtains and renews certificates automatically. In Omer's demonstration, he spins up a local file server with HTTPS—on localhost—in seconds. The browser shows a valid certificate issued by "Caddy Local Authority." For local development, this is absurdly convenient.

The real test comes with actual domains. Omer sets up a CNAME record for a subdomain and points it at his Caddy instance. Within seconds, while the browser performs a TLS handshake, Caddy provisions a certificate dynamically. "You just got served a newly dynamically provisioned certificate without having to lift a finger," he notes.

This isn't novel technology—Let's Encrypt has existed since 2015, and automation tools abound. What's different is the default behavior. With Nginx, you add SSL as a layer of complexity. With Caddy, you opt out if you don't want it.

Configuration as a Selling Point

Nginx configuration files are infamous. They're powerful but verbose, filled with nested blocks and directives that require consulting documentation even for routine tasks. Caddy takes a different approach.

For a simple reverse proxy in Nginx, you're looking at multiple lines defining server blocks, location directives, and proxy parameters. In Caddy, the equivalent is:

:port
reverse_proxy target

That's it. A port declaration and a destination. The configuration format—Caddyfile—reads almost like pseudocode. You can also use JSON if you prefer structured data, but the point is reduction of ceremony.

Omer demonstrates setting up a file server with directory browsing enabled. The Caddyfile: file_server browse. Two words. The result: a functional file server with an interface showing file sizes and modification dates.

Simplicity has limits, though. For complex routing logic, multi-stage authentication, or elaborate conditional rules, the question becomes whether Caddy's syntax scales or whether you're eventually wrestling with the same complexity, just in a different dialect.

Performance: The Traefik Comparison

Popularity metrics are noisy. Caddy has 69,000 GitHub stars versus Traefik's 50,000 and Nginx's 25,000. But stars don't serve traffic. Omer ran comparative load tests between Caddy and Traefik—both written in Go, both designed for modern infrastructure needs.

The methodology: local machine testing with each container allocated two cores and 4GB RAM. Multiple test runs with varying load profiles. The disclaimer: "It's not an indication of any production grade option, but rather a comparison of A to B."

The results showed Caddy maintaining more stable memory usage under load. As request volume increased, Traefik's memory consumption spiked and stayed elevated even after load decreased. At peak load—when both systems showed high P95 latency—Traefik used more than double Caddy's memory.

Omer notes he ran these tests "probably over 30 times" with different configurations. Caddy consistently performed as "the more stable, memory efficient system that actually excels with lower available resources."

These are synthetic benchmarks on local hardware, not production traffic patterns. But the consistency across runs suggests something real about resource efficiency.

The Kubernetes Question

Modern web servers need to play nice with container orchestration. Caddy ships with a Prometheus metrics endpoint—standard practice for Kubernetes environments. Curl the metrics endpoint and you get Go garbage collection timings, memory usage, routine counts, everything you'd want to scrape into a time-series database.

The Caddy organization maintains a Kubernetes Ingress controller, though the last release is three years old. More actively developed is their Gateway implementation, which targets the Kubernetes Gateway API—the next-generation successor to Ingress.

Omer tested Caddy in his production Kubernetes cluster. His assessment: for local development and side projects, it's climbing to the top of his list. For production-scale cluster ingress? "I don't think it's on par when it comes to an ingress controller for a full-scale cluster."

That's an honest evaluation. Caddy works in Kubernetes, but if you're running massive clusters with complex routing requirements, you're probably still looking at established ingress controllers with years of production hardening.

The Module System Problem

Caddy's extensibility comes through modules—plugins that add functionality. Standard modules ship with the distribution. Non-standard modules require rebuilding Caddy with the plugin compiled in.

This is where Omer's enthusiasm noticeably drops. To add a non-standard module (like DNSimple integration), you need xcaddy, a tool that rebuilds Caddy with your chosen plugins. "Please, please, God, make it so that I'm completely off here, but I do not wish to rebuild this for a custom plug-in," he says while walking through the process.

The workflow: clone xcaddy, build it, use xcaddy to rebuild Caddy with your module, then run your custom Caddy build. It works, but it's friction. Compared to dropping a plugin into a directory or installing via a package manager, this feels regressive.

The module ecosystem itself is extensive—integrations with AWS S3, Git, various authentication providers, caching systems. But the installation experience for non-standard modules undercuts Caddy's simplicity argument.

What This Actually Means

Caddy isn't replacing Nginx across the internet. It's been around for 10 years and still occupies a fraction of market share. But market share is a trailing indicator of utility, especially for developer tools.

The strongest case for Caddy: local development and small-to-medium production deployments where automatic SSL and simple configuration remove entire categories of problems. If you're spinning up services frequently, not having to think about certificates is worth a lot.

The weaker case: large-scale production systems with complex requirements, established Nginx configurations, and teams already fluent in traditional web server architectures. Migration costs are real, and "simpler config" might not justify rewriting battle-tested infrastructure.

Omer's final position after 30 days of testing: Caddy is becoming his default for most use cases, with explicit exceptions for full-scale Kubernetes ingress. That's not universal endorsement, but it's meaningful validation from someone who spent 15 years building infrastructure and initially believed "Nginx is king."

The certificate story he opens with—the 5 a.m. page about an expired cert—isn't dramatic or unusual. It's normal. That's exactly the problem Caddy solves most elegantly. Sometimes the best feature is the fire you never have to fight.

—Marcus Chen-Ramirez, Senior Technology Correspondent