Both Traefik and Caddy provide automatic HTTPS support and support for Docker.
What makes this decision important
For a multi-application Docker server, the reverse proxy is the heaviest piece of infrastructure you run – all requests go through it, all TLS termination is performed on it, and it is responsible for making the deployment completely seamless. Traefik and Caddy are the two modern products providing native support for auto HTTPS and dynamic configuration, and that’s why they have effectively replaced custom nginx deployments.
Philosophies of Two Proxies
Traefik uses the dynamic approach. The proxy listens to the Docker socket, analyzes labels for your containers and creates a routing table instantly when your containers start/stop. No action needed for any new application – you just tag your containers with some labels (hostname, port, TLS resolver, middlewares), and routing is done immediately. That's why so many deployment systems are built around Traefik.
Caddy uses a configuration-first approach with its famous humane syntax: a two-line configuration for Caddy allows you to serve your site via HTTPS. Its dynamism through Docker labels is implemented using the caddy-docker-proxy extension, which is good but an add-on, not the core concept of the project. Caddy is about elegant static configuration; Traefik is about dynamic providers.
Comparison of Automatic HTTPS
Both automatically obtain and renew Let’s Encrypt certificates and manage the renewal challenge without ever having to consider expiry issues. The Caddy approach is the one to beat: HTTPS is enabled by default, on-demand TLS can create certificates for unknown hostnames (great for multi-tenant apps that cannot use wildcard certificates), and its ACME implementation includes more clever fallbacks out of the box.
The Traefik certificate resolvers require only a small amount of static configuration once (type of challenge, storage file, e-mail address), after which the issuance of certificates becomes container label-driven per domain. Both are good at handling large numbers of certificates, with hundreds per host, but their operational experiences vary greatly with how much tweaking was required.
Configuration, side by side
Routing one app with HTTPS in each system:
# Traefik (labels on the app container)
traefik.enable: "true"
traefik.http.routers.app.rule: Host(app.example.com)
traefik.http.routers.app.entrypoints: https
traefik.http.routers.app.tls.certresolver: letsencrypt
traefik.http.services.app.loadbalancer.server.port: "3000"
# Caddy with caddy-docker-proxy (labels on the app container)
caddy: app.example.com
caddy.reverse_proxy: "{{upstreams 3000}}"
Middlewares, Metrics, and Ecosystem
The middleware system provided by Traefik is more capable for use on a platform than that provided by Caddy, which allows redirects, compression, basic auth, rate limiting, IP allowlisting, header management and retries through per-router configuration using labels. It also supports native Prometheus metrics and has an integrated dashboard that enables one to debug any issue with routing a particular hostname.
Caddy, however, offers extensibility through the ability to build plugins right into the binary (from DNS providers to security extensions). The readability of Caddy’s configuration makes configuration errors less likely.
Conclusion
When it comes to deploying the system in a setup where there are containers coming and going all the time, Traefik with its label-based configuration, middleware power, and observability is the way to go; that is how Peon sets things up by default. When you have a simple setup where you manage your server and just a few stable services, Caddy becomes quite appealing. Peon works with both, but you can always switch at any time.
Top comments (0)