Caddy vs Traefik

The feature lists for these two overlap almost completely. Both are Go binaries, both do ACME, both do HTTP/3, both hot reload, both are free and permissively licensed. Comparing them on features produces a tie and tells you nothing.

The real decision is where your routing table lives. In Caddy it lives in a file you wrote and can read end to end. In Traefik it is assembled at runtime from labels scattered across every compose file on the host, and the only place you can see the assembled result is the dashboard. That is a genuine advantage when containers appear and disappear, and it is a genuine liability when something does not match, because there is no single file to read.

Ask yourself how often you add a service. If the answer is "a few times a year", the file wins. If the answer is "most weeks, and I redeploy stacks constantly", labels win.

The numbers that actually differ#

Idle memory and ops load are the only spec rows where these two separate meaningfully. Everything else is a tie, so read the table for those two and for the datastore row, which explains why Traefik cannot be run in a pair.

Caddy scores 1 on the ops load rubric and Traefik scores 3. That gap is not about install difficulty. Both are one container. It is that Traefik's configuration surface has moved twice in the project's life, label errors fail silently, and every upgrade is worth reading notes for.

What a working config looks like in each#

Caddy, complete, with automatic certificates and an HTTP to HTTPS redirect included:

jellyfin.example.com {
	reverse_proxy jellyfin:8096
}

paperless.example.com {
	reverse_proxy paperless:8000
}

Traefik, same two services, expressed as labels on the containers themselves:

services:
  jellyfin:
    image: jellyfin/jellyfin
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.jellyfin.rule=Host(`jellyfin.example.com`)"
      - "traefik.http.routers.jellyfin.entrypoints=websecure"
      - "traefik.http.routers.jellyfin.tls.certresolver=le"
      - "traefik.http.services.jellyfin.loadbalancer.server.port=8096"

Five labels against one line. That ratio is the tradeoff in miniature: Traefik's labels are more typing per service but nobody has to touch the proxy, and a service that is removed takes its route with it.

The v3 syntax change is the single biggest source of broken configs#

Traefik v3 changed the rule language, and the internet is still full of v2 snippets that look correct. Running v3.7.x as of early September 2026, these are the changes that bite:

The headers middleware also lost sslRedirect, sslHost and featurePolicy outright. None of this produces a red error in the log. The router just does not exist, and the request falls through to whatever else matched, which is usually a 404 from a different service.

There is an escape hatch: traefik.http.routers.myapp.ruleSyntax=v2 on a per-router basis makes Traefik parse that one rule with the old grammar. It works. It has also been deprecated since v3.4 and is scheduled for removal in the next major, so it buys you an afternoon, not a strategy.

Caddy's cost is the DNS challenge, and it is a build pipeline#

Caddy's reputation for simplicity is earned right up to the moment you need a wildcard certificate, or your server is not reachable on port 80. Both require the DNS-01 challenge, and the official binary and the official caddy Docker image contain no DNS provider modules at all.

The fix is a custom build:

FROM caddy:2-builder AS builder
RUN xcaddy build --with github.com/caddy-dns/cloudflare

FROM caddy:2
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

That is five lines and it works. What it also means is that you now own an image, and every Caddy upgrade is a rebuild before you can move. caddy add-package looks like an easier route, but it is marked experimental and it replaces the binary on disk, which a docker compose up --force-recreate discards.

Traefik has no equivalent problem. Its ACME support uses the Lego provider list, which is broad, and configuring a DNS provider is environment variables on the existing image. If wildcard certificates across many subdomains are central to your setup, that is the strongest single argument for Traefik in this comparison. See DNS for self-hosters for whether you need a wildcard at all.

The failure modes are different in kind#

Caddy's classic mistakes are ordering and persistence:

• Directive order is fixed, not textual. Caddy executes directives in a built-in order regardless of how you wrote the file. Putting redir above reverse_proxy does not make it run first. Wrap them in a route block, or use mutually exclusive handle blocks, when order matters.
• No volume on /data means re-issuing every certificate on every redeploy. A few loops during setup and Let's Encrypt rate limits you for the week. Mount a named volume before you point real DNS at it, and use acme_ca https://acme-staging-v02.api.letsencrypt.org/directory while experimenting.
• Bind mounting the Caddyfile by path breaks reloads, because editors replace the inode on save and the container keeps reading the old one. Mount the directory.

Traefik's classic mistakes are structural:

• Editing traefik.yml does nothing until restart. Entry points, providers and certificate resolvers are static config. Only routers, middlewares and services reload live. docker compose up -d --force-recreate traefik is the fix, and forgetting this is why people conclude Traefik ignored their change.
• Docker creates a directory where you wanted acme.json. Bind mount a path that does not exist and you get a directory with that name, certificates never persist, and you re-request them on every restart until you are rate limited. Run touch acme.json && chmod 600 acme.json first. The 600 mode is enforced.
• The Docker socket is root on the host. Traefik's Docker provider needs it. Read access exposes every container's environment and mounts to a compromised proxy; write access is game over. Mount it :ro at minimum and consider a socket proxy that whitelists only the container and event endpoints. This is covered further in A security baseline for a home server.

The uncomfortable part: Traefik's strength is idle on most home stacks#

Traefik was built for churn. Its value is proportional to how often your service inventory changes. A homelab running Jellyfin, Immich, Paperless-ngx and a wiki, all of which will still be there in two years, generates approximately zero churn. You get the dynamic discovery machinery, the two-tier config model, the silent-failure rule language and the socket exposure, in exchange for a feature you use twice a year.

The cost is not paid at install time, which is why people do not notice it. It is paid the evening something breaks at 11pm and you have to reconstruct a routing table from labels in six compose files. Caddy's equivalent evening is cat Caddyfile.

The counter-argument, and it is fair: if you already run Kubernetes and use Traefik as your ingress controller there, using it at home too means one mental model instead of two. That is a real reason.

Which one for your situation#

Running both is a legitimate answer#

Nothing stops you from putting Caddy on 443 for the handful of stable public services and running Traefik on an internal network for the churn-heavy development stacks. It is more moving parts than most people want, and it is still less confusing than one Traefik with forty labels.

What to do next#

If you have not chosen yet, start with Caddy. Migrating a Caddyfile to Traefik labels later is an afternoon; unpicking a label estate is a weekend. Generate a starting config with Reverse proxy generator, read Reverse proxy and TLS for the certificate and DNS decisions that sit underneath either choice, and if you want a login gate in front of apps that have none, Authelia vs authentik covers what to put behind the forward_auth directive. The rest of the category is at Networking.