traefik-kop

A niche but sharp tool that solves exactly one problem, and solves it well.

TL;DR

• What it is: A lightweight Go agent that reads Docker container labels on one server and publishes them to Redis, so a Traefik instance on a different server can discover and route to those containers [README].
• Who it’s for: Sysadmins and technical self-hosters running a multi-host Docker setup with a single Traefik edge node — who refuse to adopt Docker Swarm or Kubernetes just to get cross-host service discovery [README].
• Cost savings: Not a SaaS replacement in the traditional sense. Saves you from adopting Kubernetes or Docker Swarm (both of which carry significant operational overhead) just to solve one routing problem. The tool itself is free; the value is avoiding the complexity tax.
• Key strength: Does one thing — publishes Docker labels to Redis for Traefik to consume — and does it with minimal configuration. No new concepts beyond what you already know from Traefik labels [README].
• Key weakness: Tightly coupled to the specific trio of Docker + Redis + Traefik. If you change any leg of that triangle, traefik-kop becomes irrelevant. At 462 GitHub stars, the community is small and third-party documentation is thin [GitHub].

---

What is traefik-kop

Traefik is one of the most popular self-hosted reverse proxies because of its Docker-native service discovery: add labels to a container, Traefik picks them up automatically, no config file editing required. The problem is that this only works when Traefik and the container live on the same Docker host. As soon as you have two physical servers — say, a beefy application server and a small edge node handling TLS and routing — Traefik can’t see the containers on the other machine.

The conventional answers to this are Docker Swarm (adds complexity and a shared networking model), Kubernetes (heavyweight, completely changes your operational model), or Consul (another service to deploy and maintain). traefik-kop proposes a simpler path: a small sidecar agent on each non-Traefik host that reads container labels locally and writes them to a shared Redis instance. Traefik, configured with a Redis provider instead of (or alongside) the Docker provider, reads from Redis and builds its routing table accordingly [README].

The ASCII diagram from the README captures it cleanly:

                    +---------------------+          +---------------------+
                    |                     |          |                     |
+---------+  :443   |  +---------+        |   :8088  |  +------------+     |
|   WAN   |-------->|  | traefik |<-------|---------->| svc-nginx  |     |
+---------+         |  +---------+        |          |  +------------+     |
                    |       |             |          |                     |
                    |  +---------+        |          |  +-------------+    |
                    |  |  redis  |<-------|---------->| traefik-kop |    |
                    |  +---------+        |          |  +-------------+    |
                    |             docker1 |          |             docker2 |
                    +---------------------+          +---------------------+

The project is written in Go, maintained by the jittering GitHub account, sits at 462 stars and 24 forks, and is MIT licensed [GitHub]. It reuses Traefik’s own docker-provider logic internally, which is why the label syntax is identical — no new label format to learn [README].

---

Why People Choose It

The use case is specific enough that the people who reach for traefik-kop have usually already exhausted the alternatives and found them too heavy.

The Swarm problem. Docker Swarm gives you built-in multi-host service discovery but requires every host to join the Swarm and imposes a shared overlay network. For many setups — especially when hosts are on different providers, or when you want the edge node to be completely isolated from the application nodes — Swarm’s networking model creates more problems than it solves.

The Kubernetes argument. If you’re running two hosts and a handful of containers, Kubernetes is overkill by an order of magnitude. The operational surface (etcd, kubelet, kube-proxy, ingress controllers, CRDs) dwarfs the problem being solved.

The Consul option. Traefik natively supports a Consul provider, which would work architecturally. But Consul is another stateful service to run, monitor, and back up. Redis is already in most self-hosted stacks.

traefik-kop’s value proposition is that it adds almost nothing to a stack that already has Traefik and Redis. If those two services are already running, the marginal cost of deploying traefik-kop is one Docker container per additional host and a few environment variables.

Independent reviews of traefik-kop specifically are scarce — the project is narrow enough that it doesn’t generate much blog content. The primary evidence base is the GitHub repository itself, issues, and community discussions in self-hosted forums.

---

Features

Core mechanism:

• Reads Docker container labels from the local Docker socket [README]
• Publishes them to Redis using the same key structure Traefik’s Redis provider expects [README]
• Watches for container start/stop events and updates Redis accordingly [README]
• Configured entirely through environment variables or CLI flags — no config file required [README]

IP binding options:

• BIND_IP: hardcode the IP address containers should be reached at from the Traefik host [README]
• BIND_INTERFACE: derive the bind IP from a network interface name (requires network_mode: host) [README]
• --skip-replace: disable IP replacement entirely if your container networking handles it [README]

Load balancer merging:

• If the same service runs across multiple hosts and all traefik-kop instances publish to the same Redis, Traefik will merge them into a single load balancer automatically [README]
• This is how you get horizontal scaling without Swarm: run the same container on N hosts, each with its own kop instance, and Traefik distributes traffic [README]

Service port binding:

• Auto-detects the host port from Docker’s port mappings — no need to hardcode it in labels [README]
• Can be overridden explicitly via traefik.http.services.<name>.loadbalancer.server.port label [README]

Namespaces:

• When multiple kop instances share one Redis, a namespace prefix prevents key collisions [README]
• Can be set per-instance or per-container via a label prefix [README]

Configuration options (full list):

• --hostname / KOP_HOSTNAME: identifies the node in Redis
• --redis-addr / REDIS_ADDR: Redis address (default 127.0.0.1:6379)
• --redis-user, --redis-pass, --redis-db, --redis-ttl: Redis auth and tuning
• --docker-host / DOCKER_ADDR: Docker endpoint (default Unix socket)
• All options available as both CLI flags and environment variables [README]

What it doesn’t do:

• No web UI, no dashboard, no metrics endpoint
• No health checking of discovered services (delegates to Traefik)
• No support for non-Docker runtimes (Podman, containerd directly)
• No built-in TLS between kop and Redis (you’d handle that at the network level)

---

Pricing: Self-Hosted Infrastructure Math

traefik-kop has no paid tier, no SaaS offering, no licensing fee. MIT license means you can use it in commercial setups, fork it, modify it — no restrictions [GitHub].

The infrastructure you need to run it:

Component	What it is	Approx. monthly cost
traefik-kop container	One per non-Traefik host	$0 (software)
Redis instance	Shared, already in most stacks	Already running, or ~$0 if containerized
Traefik (main host)	Already required	Already running
Second Docker host	The problem you’re solving for	~$4–15/mo on Hetzner/Contabo

If you’re already running Traefik and Redis, adding traefik-kop costs exactly the compute time of a Go binary that sleeps between Docker events — negligible.

The alternative cost comparison that matters here isn’t against a SaaS but against the operational overhead of Kubernetes or Docker Swarm. Those aren’t paid services, but they are expensive in engineering time and ongoing maintenance. A misconfigured Swarm or a Kubernetes upgrade gone wrong costs hours. traefik-kop has one job.

---

Deployment Reality Check

The README is clear and the setup is genuinely simple for anyone already running Traefik with Docker labels [README].

Prerequisites:

• Traefik running on the edge host, configured with a Redis provider
• Redis accessible from both the Traefik host and the application hosts
• Docker on the application hosts
• Network connectivity between the Redis instance and the kop agent (private network or VPN)

Step 1: Add the Redis provider to traefik.yml:

providers:
  redis:
    endpoints:
      - "redis:6379"

Step 2: Add traefik-kop to each application host’s docker-compose:

services:
  traefik-kop:
    image: "ghcr.io/jittering/traefik-kop:latest"
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - "REDIS_ADDR=192.168.1.50:6379"
      - "BIND_IP=192.168.1.75"

Step 3: Use normal Traefik labels on your containers. No changes needed.

What can go wrong:

• Redis exposure: The Redis instance must be reachable from all Docker hosts. If your hosts are on different providers or networks, you’ll need a VPN or private network tunnel — Redis should not be exposed to the public internet without auth and TLS.
• IP binding confusion: If BIND_IP is wrong, Traefik will route traffic to the wrong address. The BIND_INTERFACE option is cleaner when the interface name is stable, but requires network_mode: host on the kop container.
• Redis TTL: If kop crashes or the host goes down, stale Redis entries will persist until TTL expires (default: 0, meaning no expiry). Setting REDIS_TTL means Traefik will eventually clean up dead routes, but during the TTL window it will attempt connections that fail.
• No graceful deregistration by default: TTL-based cleanup is the main mechanism, not an explicit deregister call. This is a tradeoff worth knowing.
• Small project: 231 commits, one maintainer, 24 forks [GitHub]. No dedicated issue tracker activity visible in the provided data. For a critical path infrastructure component, this is a risk to acknowledge.

Realistic setup time for someone who already runs Traefik with Docker labels: 15–30 minutes to a working multi-host setup. For someone learning Traefik from scratch while also setting this up: much longer.

---

Pros and Cons

Pros

• Solves a real gap in Traefik’s Docker provider. The single-host limitation is a genuine pain point for anyone scaling beyond one machine without embracing Swarm or Kubernetes [README].
• Zero label changes required. Your existing Traefik labels work identically — kop mirrors the Traefik docker-provider logic internally [README].
• MIT license. Use it commercially, embed it, modify it — no restrictions [GitHub].
• Tiny operational surface. One stateless container per host, configured with environment variables. No database, no config files, no web UI to maintain.
• Load balancer merging works. The same service running on multiple hosts gets auto-merged in Traefik’s routing table, giving you basic horizontal scaling without Swarm [README].
• Namespace support prevents collisions when multiple kop instances share a Redis [README].

Cons

• Tight three-way dependency. Requires Docker + Redis + Traefik specifically. If you switch from Traefik to Caddy, or from Redis to Consul, traefik-kop is useless.
• Small community. 462 stars, 24 forks, one primary maintainer [GitHub]. Limited third-party documentation. If you hit an edge case, you may be on your own.
• Stale entry risk. Without TTL configured, crashed hosts leave phantom routes in Redis until manually cleaned. Default TTL of 0 (no expiry) is the wrong default for production use.
• No built-in Redis security. No TLS to Redis out of the box — you secure the network separately. Fine for private LANs, a footgun for cross-datacenter setups.
• Not for non-technical users. This tool assumes comfort with Docker networking concepts, Traefik providers, and Redis. There is no setup wizard, no GUI, no guided troubleshooting.
• No metrics or observability. You can’t tell from kop itself whether it’s healthy, how many entries it has published, or when it last synced. You’d infer this from Redis keyspace inspection.
• Podman/non-Docker not supported. If you’re moving toward rootless containers or Podman, this tool doesn’t help.

---

Who Should Use This / Who Shouldn’t

Use traefik-kop if:

• You already run Traefik with Docker labels and want to extend the same pattern to a second (or third) physical host.
• You have Redis in your stack already — or are comfortable adding it.
• You’re explicitly avoiding Docker Swarm or Kubernetes because the operational overhead doesn’t fit your use case.
• You want horizontal scaling across physical hosts without a full orchestration layer.
• You’re comfortable reading Go source code if something goes wrong and no one answers your GitHub issue.

Skip it if:

• You’re a non-technical founder. This is an infrastructure plumbing tool — it requires understanding of Docker networking, Traefik providers, and Redis. The learning curve isn’t the tool, it’s the surrounding concepts.
• You’re starting from scratch. If you don’t already have Traefik and Redis running, the simpler path is to use Nginx Proxy Manager or a managed load balancer.
• You need production-grade SLAs. A project with 24 forks and one maintainer is not a bet-the-company dependency.
• You’re considering Kubernetes anyway. If Kubernetes is on the roadmap, skip this intermediate step.
• You want Podman, containerd, or any non-Docker runtime support. Not there yet.

---

Alternatives Worth Considering

Docker Swarm with Traefik. The “official” multi-host solution. Traefik’s Swarm mode provider handles service discovery natively. More moving parts, but better supported and documented. Right choice if you’re willing to manage a Swarm cluster.

Consul + Traefik provider. Architecturally similar to traefik-kop (agent on each host publishes to a central store, Traefik reads from it), but Consul is a mature, production-grade service mesh. More complex to run than Redis, but more observable and reliable. Better choice for larger or more critical deployments.

Kubernetes + Traefik ingress controller. The canonical solution at scale. Too much overhead for a two-host hobby stack; the right answer for anything with real traffic and a team to manage it.

Nginx Proxy Manager. No multi-host story out of the box, but dramatically simpler for single-host deployments. If you haven’t hit the multi-host problem yet, don’t introduce traefik-kop preemptively.

Caddy with reverse_proxy. Simpler reverse proxy, great for small stacks, but doesn’t have the same Docker-native label system. Not a drop-in for a Traefik setup.

Traefik Hub. Traefik’s managed multi-agent tunnel product. SaaS pricing, no Redis required, handles multi-host routing as a service. Relevant if you want to stay in the Traefik ecosystem but don’t want to self-manage Redis and kop. Data not available on exact pricing at time of writing.

---

Bottom Line

traefik-kop is a precise tool for a precise problem. If you’re running Traefik on one host and Docker containers on another, and you want Traefik’s label-based routing to just work across both machines without adopting Swarm or Kubernetes, traefik-kop is the shortest path. It’s not exciting software — it’s a bridge between two existing systems. It works because it doesn’t try to do anything else.

The risks are real: small community, one maintainer, no built-in observability, stale entry behavior that needs deliberate configuration to handle correctly. Use it knowing those constraints. For a hobby homelab or a small production stack where you control the full environment, those are acceptable tradeoffs. For a high-traffic, high-availability production system, the lack of community support and observability are harder to justify.

If the self-hosted infrastructure setup is the blocker — whether it’s Traefik, traefik-kop, or anything else in the stack — upready.dev deploys these configurations for clients. One-time setup, you own the infrastructure.

---

Sources

1. jittering/traefik-kop — GitHub Repository — README, configuration documentation, architecture diagram, license. https://github.com/jittering/traefik-kop
2. GitHub — jittering/traefik-kop — Repository metadata: 462 stars, 24 forks, 231 commits, MIT license. https://github.com/jittering/traefik-kop

Note: Independent third-party reviews of traefik-kop are not available in published form — the tool is narrow enough that it hasn’t generated significant review content outside the GitHub repository itself. All claims in this article are sourced directly from the README and repository metadata above.