What Is Traefik and Why It's the Go-To Reverse Proxy for Homelabs

You have six Docker containers running on a single machine, each on a different port. You are typing http://server-ip:8080 for one service and http://server-ip:3000 for another, and you have no TLS on any of them. Maybe you forwarded a port on your router and hoped for the best. This is how most homelabs start, and it is the reason most homelabs stay fragile. A reverse proxy fixes this, and Traefik is the one that fits Docker-based setups with the least friction.

TL;DR

• A reverse proxy sits between the internet (or your LAN) and your backend services, handling routing, TLS, and access control in one place.
• Traefik auto-discovers Docker containers via labels — no manual config file updates when you add a service.
• Its core concepts are entrypoints, routers, middlewares, and providers.
• For Docker-heavy homelabs, Traefik eliminates the config-file churn that makes Nginx and HAProxy tedious at small scale.

Why This Matters

If you run more than two services behind a domain, you need something to route requests to the right container, terminate TLS, and enforce basic security policies. Doing this per-service is error-prone and does not scale, even in a homelab.

Traefik solves this with automatic service discovery. You add a container, slap on a few Docker labels, and Traefik picks it up. No config reload. No manual upstream block. That feedback loop matters when you are iterating fast on a homelab stack.

What a Reverse Proxy Actually Does

A reverse proxy is a server that sits in front of your backend services and forwards client requests to the correct destination. From the client’s perspective, it looks like they are talking to one server. Behind that server, you might have a dozen containers.

The reverse proxy handles:

• Routing — directing pihole.example.com to the Pi-hole container and paperless.example.com to Paperless-ngx.
• TLS termination — managing HTTPS certificates so your backend services do not have to.
• Middleware — injecting authentication, rate limiting, headers, or redirects before requests hit the backend.
• Load balancing — distributing traffic if you run multiple instances of a service.

Without one, you are managing all of this per-service or not at all.

What Traefik Does Differently

Traefik is a reverse proxy built for dynamic, containerized environments. Three things set it apart from traditional options like Nginx or HAProxy.

Auto-discovery via providers. Traefik watches Docker (or Kubernetes, or file configs) for changes and reconfigures itself in real time. When a container starts with the right labels, Traefik creates a route. When it stops, the route disappears. No config reload required.

Native Let’s Encrypt integration. Traefik can automatically request, renew, and manage TLS certificates through ACME. Point it at Let’s Encrypt (or a DNS challenge provider like Cloudflare), and your services get valid HTTPS without manual cert management.

Docker labels as configuration. Instead of maintaining a central config file with upstream blocks, you declare routing rules directly on each container:

labels:
  - traefik.enable=true
  - traefik.http.routers.myapp.rule=Host(`myapp.example.com`)
  - traefik.http.routers.myapp.entrypoints=https
  - traefik.http.routers.myapp.tls.certresolver=cloudflare
  - traefik.http.services.myapp.loadbalancer.server.port=8080

That is the entire routing config for a service. It lives with the service, not in a separate file you have to keep in sync.

Core Concepts

Traefik’s architecture has four key building blocks. Once you understand these, the rest is configuration detail.

Entrypoints are where traffic enters Traefik. Typically you define two: one for HTTP on port 80 (usually just to redirect to HTTPS) and one for HTTPS on port 443. Think of these as the front doors.

Routers match incoming requests to backend services based on rules. The most common rule is Host() matching, but you can also route on path, headers, or combinations. Each router is tied to an entrypoint.

Middlewares modify requests or responses between the router and the service. Common examples: basic auth, IP allowlists, rate limiting, header injection, and redirect rules. You can chain multiple middlewares on a single router.

Providers are Traefik’s sources of configuration. The Docker provider watches the Docker socket for container events. The file provider reads static YAML/TOML configs. You can use both simultaneously — Docker labels for dynamic services, file configs for static rules or middlewares.

The flow looks like this:

Client request
  -> Entrypoint (port 443)
    -> Router (matches Host rule)
      -> Middleware chain (auth, headers, etc.)
        -> Service (your container on its internal port)

Every request follows this path. If you can trace a request through these four stages, you can debug any Traefik routing issue.

Traefik vs. the Alternatives

Nginx is the incumbent. It is battle-tested, performant, and well-documented. But in a Docker homelab, you are manually editing nginx.conf or templating upstream blocks every time you add a service. There is no native auto-discovery. Nginx Proxy Manager adds a GUI layer, but it is still a separate tool wrapping Nginx.

Caddy is the closest competitor for simplicity. It has automatic HTTPS and a clean config syntax. For purely static sites or simple setups, Caddy is excellent. But its Docker integration is not as mature as Traefik’s label-based discovery, and the ecosystem of middleware plugins is smaller.

HAProxy is a load-balancing powerhouse used in high-traffic production environments. It is overkill for most homelabs and requires more manual configuration than Traefik for basic reverse-proxy use cases.

For a Docker-centric homelab where you are frequently adding and removing services, Traefik’s auto-discovery and label-based config is the practical choice. You spend less time managing the proxy and more time building things behind it.

Are you currently running Nginx or another proxy in your homelab? The migration to Traefik is usually smoother than you expect — most of the work is translating your existing routes into Docker labels.

How It Fits in a Homelab Stack

In a typical Docker homelab, Traefik runs as a container on a shared proxy network. Every service that needs to be reachable through the proxy also joins that network. Traefik reads the Docker socket (mounted read-only) to detect containers and their labels.

The typical setup:

1. Traefik binds to ports 80 and 443 on the host.
2. A DNS wildcard or individual records point your subdomains to the host IP.
3. Each service container gets Traefik labels defining its hostname, entrypoint, and TLS settings.
4. Traefik handles certificate provisioning and renewal automatically.

From there, you can layer on security middlewares — authentication, CrowdSec integration, security headers — at the entrypoint or per-router level.

Summary

• A reverse proxy centralizes routing, TLS, and security policy enforcement for all your services.
• Traefik’s auto-discovery via Docker labels eliminates the manual config churn that slows down Nginx and HAProxy in homelab environments.
• The four core concepts — entrypoints, routers, middlewares, and providers — cover everything you need to understand Traefik’s routing model.
• Traefik’s native Let’s Encrypt support means valid HTTPS certificates with no manual renewal.
• For Docker-heavy homelabs, Traefik is the practical default. It is not the only option, but it is the one with the least operational friction.

What’s Next?

If you are running Traefik or thinking about setting it up, the next step is hardening it. A reverse proxy without behavioral threat detection is just a traffic forwarder. For a deeper dive into wiring CrowdSec into Traefik’s forwardAuth middleware for real-time threat blocking, see our post on Traefik + CrowdSec forwardAuth.

Have questions about getting Traefik running in your stack, or hit a routing issue you cannot debug? Share what you are working with — comparing configs is one of the fastest ways to find what you are missing.