Caddy

What Caddy actually is

Caddy is an open source web server written in Go whose defining behavior is automatic HTTPS: declare a site name in its config and Caddy obtains, installs, and renews TLS certificates for it without you running separate certificate tooling. First released on 28 April 2015 by Matthew Holt and rewritten from scratch as Caddy 2.0 in May 2020, it is now less a single web server than a small extensible server platform. The core loads "apps" (HTTP server, TLS automation, PKI) from a unified JSON configuration that can be replaced at runtime over a REST API, and the familiar Caddyfile is one of several adapters that compile down to that JSON. YAML, TOML, and even Nginx config adapters exist too.

Under the HTTP app, Caddy ships as a static file server and a reverse proxy with load balancing: multiple upstreams, health checks, retries, and several balancing policies. That combination — reverse proxy plus certificate lifecycle management in one static binary with no runtime dependencies — is what most people actually deploy it for. Two less advertised capabilities matter in practice. On-Demand TLS issues certificates during the TLS handshake for domains it has never seen, which is why white-label SaaS platforms use Caddy in front of customer-owned domains. And the internal PKI mode runs a private CA that Caddy installs into local trust stores, so localhost and internal services get real TLS instead of browser warnings. Point several instances at shared storage and they coordinate certificate work as a fleet, sharing keys and OCSP staples.

The project is maintained by Dyanim, LLC — the company of original author Matt Holt — alongside a global contributor community, and the GitHub README positions Caddy as "a ZeroSSL project." License is Apache 2.0 (it was fully open sourced with Caddy 2; the Caddy 1 era's commercial binary licensing was controversial and is gone). Roughly 78,000 GitHub stars and 138 releases at the time of writing, with the 2.11.x line current.

Pricing: what you really pay

The software costs nothing. Caddy is free for personal and commercial use, with no feature tiers, no license server, and no "pro" build — the binary you compile from source is the same code the project ships. That matters when you compare it to Nginx, where some features live only in the paid Nginx Plus tier, or to F5/BIG-IP-class appliances.

The project's funding model is sponsorship, and it is explicit about expectations: per caddyserver.com/sponsor, "all professional and business users of Caddy are expected to invest in a sponsorship." Listed tiers run $2,999/mo for businesses and $5,900/mo for enterprises, fulfilled by Dyanim, LLC. The project is careful to say these are not software licenses — your license to the code stays the same regardless. What you get is support, training, onboarding, custom development, and a support relationship instead of a forum thread. There is also a low-cost individual tier.

Our read: budget $0 if you are comfortable self-supporting, but treat the sponsorship ask as a real line item for production use in a company. It is cheaper than a support contract from a large vendor and it buys you an escalation path when certificate renewal breaks at 3 a.m. The honest framing is that Caddy is free like a fire extinguisher you install yourself — the hardware is free, the readiness is on you.

Performance & infrastructure

Caddy has no datacenters and no SLA because it is software you run on your own metal, VMs, or containers (see our infrastructure benchmarks for what to run it on). Official builds cover Linux, macOS, Windows, BSDs, and Plan 9, on x86, ARM, MIPS, and s390x. Deployment is a single static binary; plugins are compiled in with xcaddy rather than loaded as shared objects, which makes deployment tidy and rebuilds mandatory when you add modules.

On raw throughput, the Go implementation is close to but generally behind Nginx at extreme concurrency — the standard-library HTTP core plus garbage collection set a ceiling that C-core servers do not have. In our view the gap only shows up when you are pushing very high connection counts or saturating multi-gigabit links; for the reverse-proxy-in-front-of-an-app pattern that covers most deployments, the difference is not what decides the outcome. What you get in exchange is operational: certificate renewal, HTTP/3 (QUIC) support, HTTP/2, sane TLS defaults (the project states they pass PCI, HIPAA, and NIST requirements out of the box), and a config API that lets automation reconfigure a running server without restarts. Memory use is higher than Nginx per idle worker but predictable.

For fleets, the shared-storage coordination is the feature we would design around: no external certbot cron jobs, no shared secret distribution for ACME account keys, no custom glue. The trade-off is that storage becomes a coordination dependency, so plan it deliberately.

One design point worth understanding before you commit: Caddy's native config is the JSON document, and the admin endpoint that accepts it is powerful by definition — anyone who can reach it can reconfigure the server. The project locks it down by default (localhost binding), but if you expose it for automation, authentication and network policy are your job. The same applies to cluster mode: shared storage means shared risk, so treat that storage like the credential store it effectively is.

Where it falls short

Three things we would flag before recommending Caddy. First, the ecosystem is thinner than Nginx's. The module count is large but the third-party module you want may need to be compiled into a custom binary, and a custom binary is your build pipeline to maintain. If you rely on exotic modules or on commercial support from a big vendor, Nginx or Envoy is the safer institutional choice.

Second, the sponsorship expectation is a soft cost that catches teams off guard. Nothing stops you from running Caddy free in production, but the project's stance is that businesses should pay, and community support responsiveness follows that reality. If you need contractual SLAs, Caddy itself does not sell them — you are buying professional services from a small LLC.

There is also history to be aware of. Caddy 1 distributed binaries under a license that restricted commercial use, which caused a real community backlash and sent some users compiling from source to avoid the EULA. Caddy 2 ended that experiment: the code is Apache 2.0 and there is no commercial build. We consider the matter settled, but it is the reason the project's funding page talks so explicitly about sponsorships — the business model was rebuilt around services rather than licenses, and that shapes how support works today.

Third, performance headroom. We would not put Caddy at the front of a CDN-tier deployment without load testing your exact traffic shape first. For everything from single-host reverse proxy to a few hundred sites, we consider this a non-issue; past that, benchmark. Also worth knowing: automatic HTTPS depends on DNS pointing at the machine and on reaching the ACME endpoints, so in locked-down networks you will be configuring Caddy's on-demand and CAA details yourself.

Who should pick this

We pick Caddy when the goal is HTTPS everywhere with the least possible certificate plumbing. Concrete fits: a developer or small team reverse-proxying apps and static sites on a VPS; a SaaS platform issuing certificates for customer domains at scale with On-Demand TLS; internal tooling where a private CA beats clicking through browser warnings; and any shop that wants one binary instead of Nginx plus certbot plus cron plus reload scripts.

We would pick something else when you need maximum raw throughput at the edge, a module ecosystem with commercial backing, or a vendor that can sign an SLA. Teams standardized on Nginx tuning knowledge will also feel friction: Caddy's config model is different enough that porting is a rewrite, not a translation.

A practical deployment note: because certificate issuance needs inbound reachability on port 443 and working DNS, Caddy is happiest with an A/AAAA record per hostname pointing at it before you enable a site. Behind another proxy or NAT you will need alternative challenge handling. None of this is hard, but it is the part that trips up first-time setups, and the docs cover it under the automatic HTTPS section rather than the getting-started guide. If you want our take on pairing Caddy with cheap, reliable VMs, the benchmarks page shows which hosts give it enough network headroom.

Match it to your category on /category/load-balancers if you are evaluating it as a proxy layer.

Key takeaways

• Automatic HTTPS is real and default: Caddy obtains and renews certificates for every configured site, including at scale with On-Demand TLS.
• Completely free, Apache 2.0, one static Go binary; no feature tiers and no proprietary build.
• Sponsorships ($2,999/mo business, $5,900/mo enterprise) buy support and training, not a license — budget for them in production use.
• Reverse proxy with load balancing, health checks, HTTP/2 and HTTP/3, plus a live REST config API; fleet-wide cert coordination via shared storage.
• Throughput trails Nginx at extreme concurrency and the module ecosystem is smaller; both rarely matter outside CDN-scale or heavily customized deployments.
• Best fit: developers and SaaS teams who want HTTPS handled for them; poor fit: teams needing a big-vendor SLA or maximum edge throughput.

Sources

• https://caddyserver.com/
• https://caddyserver.com/sponsor
• https://github.com/caddyserver/caddy
• https://github.com/caddyserver/caddy/releases/tag/v2.0.0
• https://en.wikipedia.org/wiki/Caddy_(web_server)
• https://caddy.community/t/caddy-server-its-free-for-live-server/3371