caddyserver/caddy

The problem

Running your own web server means managing TLS certificates: obtaining them, renewing them, handling OCSP, and recovering when an ACME endpoint misbehaves. With nginx or Apache you usually bolt on Certbot and a cron job, then discover the failure mode the day a renewal silently breaks. Caddy's pitch is that certificates are the server's job, not yours — it provisions and renews them by default, including for internal names and IPs via its own local CA.

What's different

Compared with nginx and Apache, the trade-off is configuration model. Caddy's native config is JSON and it is driven through an admin API, with the Caddyfile as a compact human-facing front end and adapters that convert formats such as NGINX config. The API-first design allows live config changes without restart. The other real differentiator is a plugin system that compiles extensions into the binary, so a feature you don't need isn't shipped. nginx offers dynamic modules too, but Caddy's stance — no external dependencies, not even libc — makes the binary a single deployable artifact. It also speaks HTTP/1.1, HTTP/2 and HTTP/3 by default.

Who it's for

Self-hosters, small teams and platform engineers who terminate TLS for internal or public services and would rather not own a certificate pipeline. It is a good fit for anyone running many small sites or containers where automated cert issuance matters more than raw tuning knobs. People with heavy existing nginx configs, mature tuning workflows, or who need a module for something not yet ported should look elsewhere first; migrating is real work, and the plugin ecosystem, while broad, is not nginx's.

Cost of adoption

You download a single binary and put it on PATH, or build from source with Go 1.26.0 or newer. Plugins require rebuilding via xcaddy build, which means a Go toolchain in your CI. Low ports may need setcap on Linux. The license is Apache-2.0, so no commercial restriction. The main risk is conceptual: the JSON config structure and API-driven model are more to learn than a flat nginx conf, and the README itself points users to a getting-started guide before anything else. The README is otherwise marketing-heavy and light on migration details; the documentation site carries the real weight.

Verdict

Caddy is not new. It was created in 2015 and has 78,353 stars after 4,301 days, so this is a mature project with a long track record rather than a spike. The recent signal is modest — one day on the daily board at +56 stars, though +2,477 stars this month and #2 on the Go monthly board suggests steady, broad interest rather than a surge. For a project that has been in production for years and manages certificates as a core concern, the adoption question is about configuration philosophy, not survival. If you want automatic HTTPS with minimal moving parts, it earns its place; if you have deep nginx investment and no certificate pain, the migration isn't obviously worth it.