Traefik vs Nginx: Why My Whole Fleet Moved

I used to deploy every client site the classic way: an Nginx vhost file, a systemd unit, a certbot cron. I even wrote up that setup — it was rock-solid for one app. Today the same VPS runs 40+ Docker containers behind a single Traefik instance, and every one of those vhost files and systemd units is gone. This is the comparison I wish I’d read before migrating.

The config model is the real difference

Nginx configuration is centralized: every site gets a file in sites-available/, a symlink, a nginx -t, a reload. The proxy owns the routing knowledge.

Traefik flips that. Routing lives on the service itself, as Docker labels:

services:
  client-site:
    image: client-site:latest
    labels:
      traefik.enable: "true"
      traefik.http.routers.client.rule: Host(`client-domain.com`)
      traefik.http.routers.client.tls.certresolver: letsencrypt
      traefik.http.services.client.loadbalancer.server.port: "3000"

Deploying a new client site is docker compose up -d — Traefik notices the container, wires the route, and requests the certificate. There is no proxy config to edit, no reload to schedule, no way for the routing file and the running service to drift apart. When you’re running one site, that’s a convenience. When you’re running forty, it’s the difference between infrastructure and chores.

Certificates: automatic, with one sharp edge

Nginx + certbot works, but it’s a bolt-on: a cron job rewrites your config and you find out about failures when a renewal email arrives (or doesn’t).

Traefik has ACME built in — declare a resolver once and every router that references it gets issued and renewed automatically.

The sharp edge nobody tells you about: HTTP-01 challenges and Cloudflare’s proxy don’t mix. If your DNS is proxied (orange cloud), Let’s Encrypt’s validation request hits Cloudflare instead of your origin, issuance quietly fails, and you never notice — because Cloudflare’s edge certificate is what browsers see. Your origin serves Traefik’s default self-signed cert while everything looks fine. If you front Traefik with Cloudflare, either use the DNS-01 challenge with an API token, or accept that origin certs only matter for hosts you unproxy. Audit it; don’t assume.

Middlewares: one change, whole fleet

Traefik’s file provider lets you define middleware once and attach it everywhere. All of my client sites share one security-headers middleware — HSTS, frame policy, referrer policy — defined in a single YAML file that hot-reloads on save. When I needed to adjust the frame policy across every site recently, it was one edit, zero restarts, fleet-wide.

The Nginx equivalent is an include snippet — workable, but every change still means a reload, and per-site drift creeps in over the years.

Where Nginx still wins

Being honest about the trade:

• Raw static serving. Nginx serving files from disk is still the fastest, simplest thing in web infrastructure. Traefik doesn’t even try — it’s a proxy, not a web server.
• Inside containers. I still ship Nginx inside some containers — as the static file server or app-local reverse proxy behind Traefik. The two aren’t mutually exclusive; Traefik replaced my edge, not every Nginx.
• Documentation gravity. Twenty years of Stack Overflow answers exist for Nginx. Traefik’s docs are good, but the long tail of weird edge cases is thinner.
• Non-Docker hosts. If your apps aren’t containerized, Traefik’s best feature — label-based discovery — does nothing for you. Nginx doesn’t care how your app runs.

The verdict

For a fleet of containerized sites on one box, it isn’t close: Traefik’s service discovery, built-in ACME, and shared middlewares remove entire categories of maintenance. For a single app on a bare VPS, the classic Nginx setup is still perfectly respectable — I ran it for years and it never once fell over.

The migration test is simple: count your vhost files. If the answer is “a folder full,” you’re maintaining a routing database by hand, and Traefik will happily take that job off you.