Glossary term

Traefik

Traefik sits at the edge of an infrastructure and directs HTTP, TCP, or UDP traffic to the right services. Its strength is keeping routes in sync with a changing environment—not making an application secure automatically.

In brief

A dynamic proxy between clients and running services.

Traefik is a specific implementation of a reverse proxy. Clients communicate with its public address and do not need to know an application’s internal address or port. Traefik selects the matching router, applies the configured middleware, and forwards the request to a service. It is not a web application framework and does not handle backend business logic.

Dynamic means that routing configuration can come from a provider and change without restarting the proxy. In a Docker environment, for example, Traefik watches the Docker API and reads container labels. Docker is not required, however: the same model works with file configuration, Kubernetes, and other supported providers.

What problem it solves

One entry layer for services that change over time.

When several websites, APIs, or application instances share one public IP address, the infrastructure must decide safely where each request belongs. Manually rewriting configuration whenever a container appears or disappears is slow and error-prone in a dynamic environment.

accepting HTTP and HTTPS traffic on shared ports 80 and 443
routing domains and paths to different applications, administration interfaces, and APIs
continuously loading routing configuration from providers
terminating TLS and optionally obtaining certificates through ACME
distributing traffic among multiple instances of one service
applying redirects, headers, rate limits, or authentication middleware before the backend

Practical example

An e-commerce application discovered through the Docker provider

Traefik listens on the web and websecure entrypoints. The Docker provider discovers the application container and creates a router for shop.example.cz from its labels. The router accepts HTTPS traffic, uses the named certificate resolver, and forwards the request to the service on its internal port 8080.

In the install configuration, providers.docker.exposedByDefault=false is a sensible default so that only explicitly enabled containers are published. Labels are not suitable for passwords, certificates, or other secrets. This example assumes the entrypoints and certificate resolver have already been configured securely outside the application labels.

Docker Compose / Traefik labels

services:
  shop:
    image: example/shop:1.0
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.shop.rule=Host(`shop.example.cz`)"
      - "traefik.http.routers.shop.entrypoints=websecure"
      - "traefik.http.routers.shop.tls=true"
      - "traefik.http.routers.shop.tls.certresolver=letsencrypt"
      - "traefik.http.services.shop.loadbalancer.server.port=8080"

How it works

Internet → entrypoint → router → middleware → service → App A / App B

The flow separates the network entrypoint, routing decision, and target instances. Its parts may come from different providers; cross-provider references include the provider namespace.

An entrypoint accepts the connection Traefik listens on a configured address, port, and protocol—typically 80/TCP and 443/TCP. An entrypoint is a network listener, not the target application.
A provider supplies routing configuration The Docker provider, a Kubernetes provider, or a file describes the available routers, middleware, and services. A provider can watch for changes and keep Traefik updated.
A router selects a service A rule such as Host or PathPrefix determines whether the request belongs to that router. This is not the router inside a PHP or frontend application.
Middleware processes the request It can redirect, modify headers, limit request rates, or provide infrastructure-level authentication. Middleware runs in the configured order.
A service forwards traffic to a backend The service contains a load balancer and one or more application instances. Traefik distributes traffic among them, but it neither creates the instances nor synchronises their data.
The response returns to the client Traefik relays the response and may record an access log, metric, or trace according to its configuration. Operators still need to distinguish an application failure from a proxy failure or unavailable backend.

Core concepts

Install configuration controls the proxy; routing configuration controls the request path.

Current documentation distinguishes these two configuration categories. Older guides may still use the earlier terms static configuration and dynamic configuration.

Install configuration

Settings that require a restart, especially entrypoints, providers, the API and dashboard, and logging. Depending on the installation, they can be supplied through a file, command-line arguments, or environment variables.

Routing configuration

Routers, middleware, services, and TLS certificates that can be updated at runtime. A provider determines where the configuration comes from, and available options vary among providers.

Entrypoints and routers

An entrypoint opens a network listener. A router evaluates the domain, path, header, or another rule and connects the request to a service. Only then does the application router select a controller or page inside the backend.

Middleware

An optional step can modify the request or response, or decide whether processing should continue. Infrastructure authentication and rate limiting do not replace business authorisation and application validation.

Services and load balancers

A service describes target servers and traffic distribution. A load balancer is part of the service even when it has only one server; Traefik does not thereby provide clustering, data replication, or shared sessions.

Providers and service discovery

A provider reads the state of an external system and derives routing from it. DNS only resolves names to network information; it does not replace service discovery or Traefik rules.

Benefits, limitations, and common mistakes

Automated routing helps operations, but misconfiguration has a wider blast radius.

Practical benefits

routes can follow services as they appear and disappear without manually restarting the proxy
a shared HTTP and TLS boundary for multiple applications and APIs
natural integration with dynamic platforms as well as support for file-based configuration
load balancing among instances, optional health checks, and shared operational observability

Limitations and common mistakes

automatic configuration does not make publishing a service automatically safe
an overly broad Host or PathPrefix rule can expose the wrong backend
unrestricted access to the Docker socket is a serious risk to the host
a public dashboard or API can expose active routes and sensitive operational context
secrets placed in Docker labels may be visible to users with access to the Docker API
middleware does not replace validation, authentication, and authorisation inside the application

When to use it and how it compares

Traefik is most valuable when routing changes along with services.

Typical deployments include several Docker applications behind shared ports 80 and 443, or a Kubernetes ingress. For one stable service, dynamic configuration may offer less value and a simpler explicit proxy configuration may be easier to understand.

nginx and Traefik can both act as reverse proxies and load balancers. nginx is a general-purpose web server with extensive explicit configuration and static-content capabilities; Traefik places more emphasis on providers and continuously derived routing. The environment should drive the choice—not a blanket claim that one tool is better.

Reverse proxy describes the role in front of a backend; Traefik is a particular tool that fills that role. An application server executes code and business logic, while Traefik routes traffic to it. Service discovery finds available services and their metadata, whereas DNS resolves names. A load balancer distributes requests among existing instances but does not create or synchronise them.

HTTPS and TLS can terminate directly at Traefik. Automatically obtaining a certificate still requires a correctly configured certificate resolver and ACME challenge, DNS records that point to Traefik, and access to the required entrypoint. Simply enabling the TLS field on a router does not create those prerequisites.

Operational checklist

Published services, provider permissions, and routing rules must be traceable.

Traefik is a public infrastructure boundary. Its configuration deserves the same review, testing, and monitoring as every other part of a deployment.

enable only the providers and entrypoints the environment actually needs
prefer explicit service publishing with the Docker provider and restrict access to the Docker API
protect the dashboard and API with authentication, authorisation, and network controls; insecure mode belongs in development only
test rule collisions, router priorities, redirects, and TLS certificate renewal
monitor configuration-loading errors, backend health, status codes, and response times
version both install configuration and file-based routing configuration, but keep secrets out of them

Frequently asked questions

Traefik without confusing infrastructure responsibilities

Does Traefik require Docker?

No. Docker is one provider. Traefik can also obtain configuration from sources such as files or Kubernetes and can work with manually defined backends.

Is Traefik the same thing as a load balancer?

Not exactly. Load balancing is one of its features. Traefik also accepts traffic on entrypoints, evaluates routers, runs middleware, and can terminate TLS.

Is a Traefik router an application route?

No. A Traefik router selects an infrastructure service from request properties. The router inside the backend then selects a specific controller, handler, or page.

Will Traefik obtain an HTTPS certificate automatically?

Only when the TLS router, certificate resolver, and ACME challenge are configured correctly. The domain must point to Traefik and the infrastructure must permit the selected validation method.

Is it safe to mount the Docker socket directly into the Traefik container?

Direct access to the Docker API is a sensitive permission and must fit the threat model. Access to the socket or API needs to be restricted, with the impact of a compromised proxy taken into account.

How I design operational boundaries

Proxies, applications, and internal services should have clear responsibilities.

I separate the public entry layer, application logic, and data services so that a routing change cannot expose an unintended part of the system.

How I design application and infrastructure boundaries Discuss your project