Traefik High Availability: Distributed Deployment Setup (2026)

Traefik’s high availability isn’t about having multiple instances running side-by-side; it’s about how those instances coordinate their understanding of your services.

Let’s see Traefik in action with a distributed setup. Imagine we have two Traefik instances, traefik-a and traefik-b, running behind a load balancer (like HAProxy, AWS ELB, or even another Traefik instance in TCP mode). They both need to see the exact same configuration.

# traefik-a.yml
entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

providers:
  docker:
    exposedByDefault: false
    network: traefik-net
  # This is the crucial part for HA
  file:
    directory: /etc/traefik/dynamic_conf
    watch: true

api:
  dashboard: true
  insecure: true # For demo purposes, use auth in production!

log:
  level: INFO

# traefik-b.yml (identical to traefik-a.yml)
entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

providers:
  docker:
    exposedByDefault: false
    network: traefik-net
  file:
    directory: /etc/traefik/dynamic_conf
    watch: true

api:
  dashboard: true
  insecure: true # For demo purposes, use auth in production!

log:
  level: INFO

Now, how do these two instances share their knowledge of services, especially when those services are managed by something like Docker? If traefik-a sees a new Docker container, how does traefik-b know about it instantly?

The key is the providers section, specifically how Traefik interacts with your orchestration layer.

Docker Example:

When Traefik is configured with the Docker provider, it connects to the Docker API on each node where it’s running.

traefik-a connects to docker-a’s API.
traefik-b connects to docker-b’s API.

If you deploy a new service container on docker-a and it’s labeled for Traefik (e.g., traefik.enable=true), traefik-a will pick it up. But traefik-b won’t automatically know about it unless it also has access to the same state.

This is where the shared configuration backend comes in. Traefik supports several:

File Provider (with shared storage):
- What it solves: Synchronizes static and dynamic configuration files across all Traefik instances.
- How it works: All Traefik instances read configuration from a common network filesystem (like NFS, CephFS) or a shared object storage bucket. When a file is updated in the shared location, all Traefik instances reload their configuration.
- Example Config:
```
providers:
  file:
    directory: /mnt/shared-config/traefik # Mounted NFS share
    watch: true
```
- Deployment: Mount the same NFS directory or object storage path to /mnt/shared-config/traefik on all Traefik nodes.
Consul Catalog Provider:
- What it solves: Dynamically discovers services registered in Consul and uses them as routing rules.
- How it works: Traefik queries Consul for services. If a service is tagged appropriately (e.g., traefik-router), Traefik automatically creates a router for it. When services are added or removed in Consul, Traefik updates its routes.
- Example Config:
```
providers:
  consulCatalog:
    endpoint: "127.0.0.1:8500" # Address of your Consul agent
    prefix: "traefik"
    exposedByDefault: false
```
- Deployment: Ensure your services register themselves with Consul and include the necessary tags. Traefik instances should be able to reach the Consul endpoint.
Etcd Provider:
- What it solves: Similar to Consul, it uses Etcd as a distributed key-value store to manage routing rules dynamically.
- How it works: Traefik watches specific keys in Etcd for service definitions and creates/updates routes accordingly.
- Example Config:
```
providers:
  etcd:
    endpoint: "http://127.0.0.1:2379" # Address of your Etcd endpoint
    prefix: "traefik"
```
- Deployment: Configure your services or an intermediary process to write their routing information into Etcd under the specified prefix.
Kubernetes CRD Provider:
- What it solves: Leverages Kubernetes Custom Resource Definitions (CRDs) like IngressRoute for defining routing rules within a Kubernetes cluster.
- How it works: Traefik watches for IngressRoute objects in the Kubernetes API. When an IngressRoute is created, updated, or deleted, Traefik automatically configures its routing table.
- Example Config:
```
providers:
  kubernetesCRD:
    allowCrossNamespace: true # Or false, depending on your security needs
```
- Deployment: Deploy Traefik with the Kubernetes CRD provider enabled in your Kubernetes cluster. Then, define your routes using IngressRoute YAML manifests.
Docker Provider (with Swarm or Kubernetes):
- What it solves: Traefik can be deployed as a service in Docker Swarm or Kubernetes and automatically discover services managed by the orchestrator.
- How it works: When Traefik is deployed within the same Swarm/Kubernetes cluster, its Docker provider connects to the orchestrator’s API (e.g., Docker Swarm manager API, Kubernetes API server). It then discovers containers/services based on labels.
- Example Config (for Swarm):
```
providers:
  docker:
    swarmMode: true
    exposedByDefault: false
    network: traefik-net # The network Traefik is attached to
```
- Deployment: Deploy Traefik as a Swarm service or Kubernetes Deployment, ensuring it has network access to the orchestrator’s API and is on the same network as the services it needs to route.

The core idea is that all Traefik instances must be able to access the same source of truth for your routing configuration. This source of truth could be a shared file system, a service registry like Consul, a distributed key-value store like Etcd, or the orchestrator’s API itself (Kubernetes, Swarm).

The most common and robust setup for distributed deployments involves using a dynamic configuration provider. For instance, if you’re running Traefik across multiple Docker hosts or Kubernetes nodes, you’d typically use the Docker provider (if Traefik is part of the orchestrator) or a backend like Consul or Etcd.

When you deploy a new application container, you label it for Traefik. If Traefik is configured with the Docker provider and running in Swarm mode, it will see the label and add the service. If you have multiple Traefik instances, they all connect to the Swarm manager API and will independently discover the same service, ensuring consistent routing.

If you’re not in a Swarm or Kubernetes environment and are just running independent Docker hosts, you’d typically use the File provider with a shared network filesystem (like NFS) where you store your dynamic configuration. All Traefik instances would mount this shared directory, and updates to configuration files there would be picked up by all instances.

The next step after achieving HA routing is managing TLS certificates across these distributed instances.

More Deep Dives in Traefik