Caddy vs Traefik

Last reviewed Aug 22, 2026 · 630 words

Both proxies solve the same homelab problem — many containers, one IP, automatic HTTPS — and both solve it well, so the choice is about configuration philosophy, not capability. Caddy is imperative simplicity: you write down your routes. Traefik is declarative automation: your containers announce their own. Neither is faster in any way you will measure at homelab scale; TLS termination for a family's traffic is a rounding error on any CPU that can run Docker.

The same job, expressed two ways

Publishing Jellyfin with automatic TLS in Caddy is the entire config:

jf.example.com {
    reverse_proxy jellyfin:8096
}

In Traefik, the equivalent lives on the Jellyfin container itself:

    labels:
      - traefik.enable=true
      - traefik.http.routers.jf.rule=Host(`jf.example.com`)
      - traefik.http.services.jf.loadbalancer.server.port=8096

plus a one-time static config for entrypoints and the ACME resolver. The Caddyfile version is easier to read six months later; the Traefik version means adding service number fifteen touches only that service's compose file, and the route dies automatically when the container does. At three services the difference is taste. At twenty-five, Traefik's self-registration starts paying real dividends — and Caddy's single file starts becoming the one place you forget to remove dead entries.

Certificates: both automatic, one more battle-tested at the edges

Automatic Let's Encrypt is table stakes for both, including HTTP-01 out of the box and DNS-01 for wildcard certs (Traefik ships dozens of DNS provider integrations; Caddy gets them via plugin builds, which means a custom Docker image — its one notable friction point). Two operational notes from the trenches: persist Caddy's /data volume or every container recreation re-issues certificates and walks you into Let's Encrypt rate limits, and give Traefik's acme.json file 600 permissions or it refuses to start. Both handle HTTP/3; Caddy enables it by default. For the wider TLS picture, see TLS certificates done right.

Debugging and day-2 life

This is Traefik's honest weakness: when a route doesn't work, the answer is buried in label typos, router/service name mismatches, or middleware ordering, and the error surface is opaque — the dashboard helps, but "why is this 404ing" sessions are a rite of passage. Caddy fails more legibly: the Caddyfile either parses or it doesn't, and caddy validate tells you before reload. Traefik counters with live reconfiguration (no reloads, ever) and genuinely excellent observability — built-in metrics that feed Prometheus and Grafana dashboards with per-route latency and status codes, which Caddy matches only with more assembly. Both hot-reload config in practice; neither drops connections doing it.

Beyond the homelab

Caddy is also a first-rate web server — static files, PHP, templates — so a blog plus five proxied apps can be one process. Traefik is also a Kubernetes ingress controller, so labels learned in the homelab transfer to clusters at work. If either of those futures is yours, weight it accordingly; the full field including Nginx and HAProxy is covered in the reverse proxy showdown.

Decision table

What I'd do

Start with Caddy — every homelab should experience how little a reverse proxy can hurt. Move to Traefik when, and only when, editing the Caddyfile for every new container starts feeling like toil; the migration is an afternoon, nothing about Caddy locks you in, and plenty of us have run both for years depending on the box.