Caddy 2.11: Automatic HTTPS and Modular Config in a Go Web Server
Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
At a glance
- What is it?
- Caddy is a Go-based web server that makes TLS default, not optional. This review covers its automatic HTTPS, Caddyfile and JSON config, and where its zero-dependency build trades flexibility for control.
- Who is it for?
- Adopt Caddy if you want HTTPS without certificate management and a config that stays readable. Skip it if you need a plugin ecosystem without a custom build, or if you cannot compile Go binaries in your deployment pipeline.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Caddy Solves and Who It Is For
Caddy addresses the operational burden of TLS. Most web servers treat HTTPS as an add-on that requires certificates, renewal, and OCSP handling. Caddy makes TLS the default. The README states that it uses TLS by default and manages certificates automatically through ZeroSSL and Let's Encrypt for public names, and a fully-managed local CA for internal names and IPs. This is for teams that want a web server that stays up when certificate-related issues occur, and for individuals who want a simple static file server or reverse proxy without reading a certificate manual. The project is written in Go, which the README notes has higher memory safety guarantees than other servers, and it runs anywhere with no external dependencies, not even libc. If your pain is certificate rotation or TLS configuration sprawl, Caddy is aimed directly at you.
The Mechanism: Automatic HTTPS and CertMagic
Caddy's automatic HTTPS is not a bolt-on. It is built around CertMagic, which the README credits as the power behind it. CertMagic handles issuance, renewal, and OCSP stapling, and it can coordinate with other Caddy instances in a cluster. The README also lists multi-issuer fallback and Encrypted ClientHello (ECH) support. The practical effect is that when you point Caddy at a domain, it obtains and renews certificates without a separate tool. This is a different mechanism from a server like nginx, where you must configure certbot or another client. The README claims that Caddy stays up when other servers go down due to TLS or OCSP issues, which is a direct consequence of this built-in management. The architecture is modular, so CertMagic is a separate component that Caddy uses, and that separation is visible in the repository layout.
Configuration: Caddyfile, JSON, and the API
Caddy offers three ways to configure it, and they serve different needs. The Caddyfile is the easy path: a human-readable format that the README recommends for most users. The native JSON config is the powerful path, and the JSON API allows dynamic configuration without restarting. There are also config adapters if you do not like JSON, which means you can write in a format you prefer and have Caddy convert it. The README does not give a full Caddyfile example, but the quick start points to the Getting Started guide. The JSON API is a notable feature because it enables programmatic control, which is useful for orchestration. The trade-off is that you have to learn a new config model. If you come from nginx or Apache, the Caddyfile is different enough to require a learning curve, and the JSON schema is even more distinct.
Getting It Running: Install and Build Commands
The simplest install is to download a binary from GitHub Releases and place it in your PATH. The README also documents building from source with Go 1.25.0 or newer. For development, you clone the repo, go into cmd/caddy, and run go build. The README warns that this will not embed proper version information, and for that you should use xcaddy. The build commands are straightforward: git clone, cd cmd/caddy, go build. On Linux, binding to low ports requires elevated privileges, and the README suggests sudo setcap cap_net_bind_service=+ep ./caddy. There is also a setcap.sh script for use with go run. For production builds with plugins, you use xcaddy, which automates creating a new module, copying Caddy's main.go, and adding imports for custom plugins. The build command includes tags like -tags=nobadger,nomysql,nopgx, which are worth noting because they disable certain storage backends by default.
Modular Architecture and the xcaddy Build Process
Caddy is not a single monolithic binary. The README describes it as highly extensible with a modular architecture that lets Caddy do anything without bloat. The way you add functionality is through xcaddy, which builds a custom binary with your chosen plugins. The process involves creating a new folder, copying Caddy's main.go, adding imports for plugins, and running go build. This is a different model from a server like nginx, where you compile in modules at build time too, but Caddy's plugin system is Go-based and community-driven. The README does not list any specific plugins, but the architecture is clear. The cost is that you need a Go toolchain to add plugins. If you only use the default binary, you get HTTP/1.1, HTTP/2, and HTTP/3, and automatic HTTPS, but you miss out on anything else. The build tags in the xcaddy command suggest that some storage backends are optional, which is a sign that the default build is intentionally lean.
Limitations and Wrong Tool Cases
Caddy is not the right tool in every situation. The README notes that it may try to bind to low ports, which requires elevated privileges on most systems. If you cannot run setcap or run as root, you will need to configure a high port and reverse proxy, which defeats some of the simplicity. Another limitation is the plugin build process. If you need a plugin that is not in the default binary, you must compile it yourself with xcaddy. That requires Go 1.25.0 and a working build environment. For teams that avoid custom builds, this is a barrier. The README also warns that the development build does not embed version information, which can make debugging harder. Finally, Caddy's config model is its own. If you have a large existing nginx or Apache configuration, migrating to Caddy is not a drop-in replacement. You will rewrite your config in Caddyfile or JSON, and that takes time and carries risk.
Alternatives: nginx and the Difference in Approach
The most direct alternative is nginx. nginx is a high-performance web server and reverse proxy that has been around for a long time, and it is known for its configuration flexibility and ecosystem of modules. The key difference is in TLS handling. nginx does not manage certificates for you. You need a separate tool like certbot to obtain and renew certificates, and you have to configure the paths and reload the server. Caddy automates that with CertMagic. Another difference is configuration style. nginx uses a block-based config that many administrators already know, while Caddy uses a simpler Caddyfile or a JSON API. If you already have nginx expertise and a working certificate pipeline, switching to Caddy may not save you much. But if you are starting fresh and want HTTPS without extra moving parts, Caddy's approach is more direct. The README does not compare itself to nginx, but the difference is clear from the features listed.
Maintenance, Upgrades, and License
Caddy is released under Apache-2.0, which is a permissive license that allows commercial use and modification. The repository is actively maintained, with recent releases in 2026, including v2.11.4 in June 2026. The maintenance cost is moderate. Upgrading is typically just replacing the binary, but if you have a custom build with plugins, you need to rebuild with xcaddy each time you upgrade. The README does not document an upgrade path, but the binary replacement is straightforward. The build tags in the xcaddy command (nobadger, nomysql, nopgx) suggest that some storage backends are compiled out by default, which means you need to know which backends you rely on. The documentation is a key part of the maintenance story; the README points to the website and community forum for help. The project is a ZeroSSL project, according to the README, which means there is a corporate sponsor behind it, but the license remains open.
Editorial conclusion
Adopt Caddy if you want HTTPS without certificate management and a config that stays readable. Skip it if you need a plugin ecosystem without a custom build, or if you cannot compile Go binaries in your deployment pipeline. Verify first that your OS allows binding to low ports or that you can apply setcap, and confirm that the plugins you need are available as xcaddy modules. Caddy's automatic HTTPS and config adapters are the concrete reasons to choose it, but they come with the cost of learning its own config model and the occasional need to build from source.
Community notes