Caddy

What it is

Caddy is a web server, written in Go, that does automatic HTTPS by default — it provisions and renews TLS certificates (via Let's Encrypt or ZeroSSL) with zero manual cert management. It also handles reverse proxying, static file serving, and load balancing. Config is either a Caddyfile (human-readable, minimal) or JSON (for full API-driven control). Worth flagging: the category tag here says "Orchestration & Management," but that's a stretch — Caddy is a web/proxy server, not an orchestrator. Don't confuse it with something like Kubernetes ingress controllers that handle cluster-wide traffic policy, though it's commonly used as the underlying engine for exactly that (e.g., via the Caddy ingress controller).

Who builds it and why

Maintained by Matt Holt and a community of 411 contributors, with commercial backing through Ardan Labs and Caddy's own enterprise support arm (Caddy Community LLC / Zerossl relationship). The project's stated goal is to make HTTPS the default, not an afterthought — a direct reaction to the operational pain of manual cert renewal with nginx + certbot. Founding date isn't publicly documented, but the project has been stable and actively maintained for years judging by commit cadence.

Production readiness signal

73,650 GitHub stars, 411 contributors, and a commit as recent as 2026-06-30 — this is an actively maintained project, not an abandoned one. Latest release v2.11.4 indicates a mature major version (v2) with ongoing patch/minor releases rather than churn-heavy rewrites. Apache-2.0 license means no copyleft entanglement for commercial use. CNCF maturity level is not publicly available — Caddy is not (as of this writing) a CNCF project, so don't expect it under CNCF governance/security audits the way you'd get with, say, Envoy or containerd. If you need that governance signal for a compliance checklist, note its absence explicitly.

Who should use this

• Teams that want dead-simple automatic HTTPS without wiring together nginx + certbot + cron jobs.
• Small-to-mid scale deployments where a Caddyfile's simplicity beats the complexity of an nginx.conf or Envoy config.
• Go shops that want to embed Caddy as a library into their own binaries (it's designed for that).
• Homelab, internal tooling, and edge use cases where operational simplicity matters more than raw throughput benchmarks.
• Kubernetes users running the Caddy ingress controller who want automatic cert lifecycle without cert-manager as a separate moving part.

Who should NOT use this

• High-throughput, latency-sensitive edge/CDN infrastructure at massive scale — nginx and Envoy have more production mileage and tuning knobs for extreme concurrency.
• Teams already deeply invested in Envoy/Istio for service mesh and L7 traffic management — Caddy doesn't do mTLS service mesh, traffic shadowing, or the observability integrations Envoy has.
• Organizations that require CNCF-graduated governance for vendor/security review checklists — Caddy isn't a CNCF project, so it won't tick that box.
• Shops needing deep community familiarity with config syntax at hire-time — nginx config knowledge is far more common in the job market than Caddyfile/JSON.
• Anyone needing complex, highly custom load-balancing algorithms or WAF-grade request filtering out of the box — you'll be reaching for modules or a different tool.

Alternatives

• nginx — the incumbent, battle-tested at massive scale, but no automatic HTTPS without bolting on certbot/cert-manager.
• Envoy — built for service mesh and complex L7 traffic management; heavier operational footprint, steeper learning curve, but the standard for cloud-native architectures.
• Traefik — closer analog to Caddy: automatic HTTPS, Kubernetes-native, more built-in service discovery integrations out of the box.

Pricing

Fully open source under Apache-2.0 — no license cost, no feature gating. Commercial/enterprise support is available separately through Caddy's affiliated support offerings, but the software itself carries zero licensing cost.