Caddy Web Server Review: Automatic HTTPS in Go
/caddy
Caddy is a web server that makes HTTPS the default: it issues and renews TLS certificates automatically through Let's Encrypt or ZeroSSL, and config lives in a short Caddyfile. It ships as a single static Go binary with no dependencies. The catch is documentation gravity — most tutorials online target other servers, so you'll lean on Caddy's own docs. Reach for it on a new deployment; think twice before migrating a tuned, working setup just for the convenience.
What is Caddy?
Caddy is an extensible, multi-platform web server written in Go that supports HTTP/1.1, HTTP/2, and HTTP/3, and turns on HTTPS automatically by default instead of leaving it optional. Nearly all configuration lives in one JSON document, and the Caddyfile — plus adapters for JSON5, YAML, TOML, or even NGINX config — gets translated into that JSON. It's maintained by ZeroSSL, an HID Global company.
Key Features of the Caddy Web Server
- ✓Automatic HTTPS by default: Caddy obtains and renews certificates through Let's Encrypt or ZeroSSL for public hostnames, and runs a fully-managed local CA for internal names and IPs, with multi-issuer fallback if one CA is unavailable.
- ✓HTTP/1.1, HTTP/2, and HTTP/3 support out of the box — no separate module or QUIC library to wire in yourself.
- ✓Two config formats: the Caddyfile for readable text config, or native JSON for full control and live API-driven changes.
- ✓Config adapters convert JSON5, YAML, TOML, or existing NGINX config into Caddy's native JSON, per the README.
- ✓Modular architecture: Caddy is a platform for Go "apps" (modules) — tls and http ship standard, and third-party modules extend it via xcaddy builds.
- ✓Single static binary with no external dependencies, not even libc, per the README, so deployment is one file copy.
- ✓Encrypted ClientHello (ECH) support, plus coordination between multiple Caddy instances managing certificates for the same site.
Getting Started: How to Install Caddy
The simplest, cross-platform route is to download Caddy from GitHub Releases and put the executable in your PATH — the README calls this the easiest option, with fuller install instructions on the official docs site. To build from source you need Go 1.25.0 or newer: git clone the repo, cd into caddy/cmd/caddy/, then go build. Note that this development build won't embed proper version information, a known limitation the README links out to a Go issue about. Binding to low ports like 80 or 443 usually needs root privileges; on Linux the README suggests sudo setcap cap_net_bind_service=+ep ./caddy, or running go run -exec ./setcap.sh main.go for temporary binaries. Tests run with go test ./... or against a specific module, e.g. go test ./modules/caddyhttp/tracing/. For a version-stamped build or one with custom plugins, the README points to the xcaddy tool: create a folder, copy in Caddy's main.go, run go mod init, optionally pin a version with go get, add plugin imports, then go build -tags=nobadger,nomysql,nopgx — or just run xcaddy build directly. The GitHub README itself doesn't document Caddyfile or JSON syntax; that's left entirely to the caddyserver.com docs and its quick-start tutorials.
Strengths
- ✓A working HTTPS site config in the Caddyfile is a handful of lines — no separate certificate or renewal setup to write.
- ✓Ships as a single static Go binary with no external dependencies, not even libc, so deployment is one file copy.
- ✓Config changes can be pushed live through the JSON API without restarting the process.
- ✓Supports HTTP/1.1, HTTP/2, and HTTP/3 without adding a separate module.
- ✓Config adapters mean you're not locked into JSON or the Caddyfile — YAML, TOML, and even existing NGINX configs can be converted in.
Considerations When Using Caddy
- △Building with plugins isn't a simple flag — it needs the separate xcaddy tool, a custom main.go, or Go module wrangling; there's no built-in plugin installer.
- △The GitHub README doesn't document Caddyfile or JSON config syntax at all; it defers entirely to the external caddyserver.com docs, so the repo alone won't teach you the config language.
- △Development builds made with plain go build don't embed version info, a limitation the README links out to a Go issue for.
- △No production support is bundled in: the README specifically recommends companies secure a paid contract through Ardan Labs before they need it, and free help runs through a community forum rather than the issue tracker.
- △Binding to ports 80/443 needs OS-level privilege setup (setcap on Linux) on a from-source build — a step some other servers avoid via install scripts or packages.
Caddy Alternatives for Web Serving
Frequently Asked Questions about Caddy
Caddy is released under the Apache-2.0 license, which permits commercial use, modification, and redistribution without licensing fees.
The Caddyfile is Caddy's plain-text configuration format; a config adapter converts it into Caddy's native JSON before the server applies it.
Caddy supports HTTP/1.1, HTTP/2, and HTTP/3 out of the box, and it obtains and renews TLS certificates automatically by default.
Caddy is commonly deployed as a reverse proxy; the GitHub repo carries the reverse-proxy topic tag and can sit in front of any long-running backend.
Caddy is written in Go, which the project says gives it stronger memory-safety guarantees than servers written in languages like C.
Caddy issues certificates through Let's Encrypt or ZeroSSL for public hostnames and runs its own local CA for internal names and IPs, with fallback between issuers if one is unavailable.
The problem it solves
Getting a web server onto HTTPS usually means bolting several separate tools together: the server itself, plus certbot or acme.sh for certificates, plus a cron job to renew them before they expire, plus a config reload so the renewal actually takes effect. Caddy folds that whole chain — obtaining, renewing, and applying TLS certificates — into the server process itself, using Let's Encrypt or ZeroSSL by default and its own local CA for internal hostnames that public CAs won't issue for. That also solves a narrower problem: internal services and IP addresses that need TLS but can't get a publicly trusted certificate.
Best use cases
- •Fronting a small set of sites or apps where you want HTTPS working without setting up certbot separately.
- •Acting as a reverse proxy in front of one or more backend services — the repo is tagged reverse-proxy on GitHub.
- •Internal or homelab services on private IPs or hostnames that need TLS but can't get a public CA certificate; Caddy's local CA covers that.
- •Running any long-running Go program, since the README describes Caddy as a platform for Go apps, not only an HTTP server.
- •Clustered deployments where multiple Caddy instances need to coordinate certificate issuance for the same domains.
Who should try it — and who should skip
Try Caddy if you're standing up a new service and don't want to hand-roll a certbot renewal script, or if you're running internal tools on hostnames a public CA won't certify — the local CA handles that without extra tooling. It's also worth a look if you write Go and like the idea of your web server and application logic sharing one process through Caddy's module system. Skip it if you've already got nginx or Apache configs tuned over years and no HTTPS pain to solve — the migration cost buys you convenience you may not need. Skip it too if managing plugins outside the standard build, via xcaddy, feels like more Go tooling than your team wants to own.
Related repositories
Still deciding about caddy?
One click hands the question to an AI along with this page — see what it says about caddy.