Traefik Manager edits dynamic.yml instead of leaving it to a text editor

What it edits: dynamic.yml, acme.json and traefik.yml

Traefik Manager's scope is the whole configuration surface of a Traefik instance, not just the routing layer. That is what distinguishes it from a dashboard that only reads.

The primary target is the dynamic configuration file, mounted into the container as a volume. The compose file mounts three paths and two of them are marked required:

volumes:
  - /path/to/traefik/dynamic.yml:/app/config/dynamic.yml
  - /path/to/traefik-manager/config:/app/config
  - /path/to/traefik-manager/backups:/app/backups

Three more mounts are optional and each one enables a specific tab, which is the clearest statement of the design in the whole repository:

- `acme.json` mounted read only enables the Certificates tab - `traefik.yml` mounted read-write enables the Plugins and Static Config tabs - `access.log` mounted read only enables the Logs tab

So the tool's capability is gated on what you choose to expose. Not mounting `traefik.yml` means the static configuration editor is simply unavailable, and not mounting `acme.json` means the certificate inventory is unavailable. That is a sensible default posture for a tool with this much reach.

The static config editor goes further than writing a file. The README says you can apply changes with a one-click restart through a socket proxy, a poison pill or a direct socket. A poison pill here means writing a file that Traefik watches and acts on, which is how you make a running proxy reload without an orchestrator.

Two install paths, and the curl one runs a remote script

The quick start offers an installer script:

curl -fsSL https://get-traefik.xyzlab.dev | bash

That installs a `tm` CLI and immediately runs `tm install`. The script reports six modes: Traefik and Traefik Manager together, Traefik Manager alone in Docker or native, or an agent for a remote host in three variants. After that, `tm` manages the install through `tm status`, `tm update`, `tm logs`, `tm reconfigure` and `tm doctor`.

This is a pipe-to-shell from a domain separate from the GitHub repository. That is a normal thing for a project to offer and an unusual thing for an infrastructure engineer to run unreviewed on a machine that fronts their services. The Docker Compose path is the one to prefer if you want to see every line before it executes.

The compose file is short. The image comes from ghcr.io, the container maps port 5000, and it restarts unless stopped:

services:
  traefik-manager:
    image: ghcr.io/chr0nzz/traefik-manager:latest
    container_name: traefik-manager
    restart: unless-stopped
    ports:
      - "5000:5000"
    environment:
      - COOKIE_SECURE=false

Open http://your-server:5000 and a setup wizard takes over from there. Note that `COOKIE_SECURE=false` is the shipped default, which is correct for a bare HTTP install and wrong the moment you put it behind TLS, since the compose comment says to set it true when running behind an HTTPS proxy.

Ownership tracking on services it did not write

The detail in this project that most impressed me, and the one most likely to cause a data loss if you miss it, is the ownership model for services.

Traefik Manager will show you services in your configuration that it did not create, from a file you wrote by hand or another tool. Those stay read only until you take them over. Taking over records ownership without touching the file, which is the correct sequencing: you claim it first, then your next edit writes it.

The same idea governs backups. There are timestamped local backups before every change, and a git push mode with commit history, diffs and one-click restore. For anyone whose dynamic.yml is their production routing table, that combination of before-change backups and a restore path is what makes a web editor acceptable at all.

Certificate management follows the same pattern of showing you things you probably forgot. You get every certificate in `acme.json`, with expiry dates, plus two specific failure categories: certificates no router serves, and certificates whose resolver has been deleted from your static config. You can filter by domain or by either condition. Removing them requires the file mounted read-write plus a configured restart method, one at a time or in bulk, with a timestamped backup you can restore.

Monitoring reads the Traefik API, not just your own file

Live router and service health comes from the Traefik API, so Traefik Manager needs that API enabled on your instance. That is a configuration change to Traefik itself and the README does not spell out the flag, so expect to check your own Traefik configuration for it.

Provider tabs are automatic. Docker, Kubernetes, Swarm, Nomad, ECS, Consul, Redis and others appear only the first time Traefik actually reports routers from them. That is a better design than a settings page where you enable a provider and nothing appears because Traefik has none.

There is also a CVE advisory view scoped to your running Traefik version, which means the tool reads somewhere to know what advisories apply.

Background monitoring is the feature that outlasts the browser tab. The server checks your routes on a schedule and reports when a backend goes down or a pool degrades, alongside certificate expiry, Traefik and agent reachability, CrowdSec activity, GeoIP freshness and new releases. The README's phrasing is that alerts arrive whether or not the interface is open, and the notification system covers nine destinations: Discord, Slack, ntfy, Gotify, Pushover, Pushbullet, Telegram, UnifiedPush and generic webhooks, routed by category and severity, with quiet hours, hourly or daily digests, and errors that break through anyway.

CrowdSec integration shows attacks, bans and decisions, with optional country flags and a world map that the README says is resolved on your own server.

Security features, and what the cookie flag really controls

The security list is long enough that it deserves scrutiny rather than acceptance. bcrypt for passwords, TOTP two-factor, OIDC single sign-on, per-device API keys, CSRF protection, rate limiting, and secrets encrypted at rest.

The Python dependency list shows the implementation. `bcrypt==5.0.0` and `pyotp==2.10.0` cover password hashing and TOTP. `cryptography==50.0.0` and `PyJWT==2.15.0` cover the encryption and token handling. `flask-limiter==4.1.1` is the rate limiter, and `Flask-Babel==4.0.0` with `Babel==2.18.0` handles localisation, which matches the `locale/` directory and the pybabel compile step in the Dockerfile. `maxminddb==3.1.1` is the GeoIP database reader behind the country flags, and `docker==7.2.0` is how it talks to the Docker socket if you enable that.

`COOKIE_SECURE` is the setting to understand first. The compose comment sets it to false by default and tells you to set it true when running behind an HTTPS proxy. It controls whether the session cookie carries the Secure attribute. On a bare HTTP install on a LAN, leaving it false is what makes login work at all. When TLS terminates upstream, set it to true so browsers only send the session cookie over HTTPS.

Multi-server access uses a Go agent rather than SSH or a VPN, and every tab works against whichever server you select.

The Dockerfile vendors its frontend assets with pinned checksums

The build image is python:3.11-alpine, and it compiles translations at build time with `pybabel compile -d locale -D messages --statistics`.

The interesting part is how third-party frontend assets get in. Tailwind CSS, Phosphor icons, Monaco and Inter and JetBrains Mono fonts are downloaded during the build, not vendored in git. The Dockerfile contains a comment explaining the mechanism and the reason:

RUN /app/scripts/fetch-asset.sh \
    "https://github.com/tailwindlabs/tailwindcss/releases/download/v3.4.17/tailwindcss-linux-x64" \
    /usr/local/bin/tailwindcss \
    && chmod +x /usr/local/bin/tailwindcss

The comment says every download goes through `scripts/fetch-asset.sh`, which fails on an HTTP error instead of saving the error page, and refuses anything whose SHA-256 does not match the one recorded in `scripts/vendor-assets.sha256`. And it points out this binary is executed during the build, so it matters most.

That is a supply chain defence implemented at the right layer. A fetch script that validates checksums for a binary the build then executes prevents a compromised release URL from becoming a compromised image, which most projects do not bother with. The tailwindcss build is pinned to v3.4.17 and the icon package to web-2.1.1.

The Dockerfile uses `su-exec` alongside curl, tar, git and tzdata, which is how the container drops privileges on start rather than running as root throughout.

Python tooling, tests, docs and the tm CLI

Development infrastructure is visible in the root layout. `pytest.ini` and `tests/` for the test suite, `ruff.toml` for linting and formatting, `requirements.txt` and `requirements-dev.txt` for dependencies, `Makefile` for task running, and `renovate.json` for automated dependency updates. There are separate GitHub Actions workflows for the Docker build and for tests, and the tests workflow badge points at the `dev` branch.

Documentation is a VitePress site built from the `docs/` directory, and the root `package.json` is named `traefik-manager-docs` and is private, confirming that the Node side of this project is documentation tooling rather than application code. Three scripts exist: `docs:dev`, `docs:build` and `docs:preview`.

Translations are handled through Weblate, which the README badges reference, so the locale set grows outside the release cycle.

There is also a native Android app on Google Play and a PWA install path for the web app on any platform, and two layout options named Fluid and Fixed.

On releases: v1.15.2 on 2026-10-11, v1.15.1 on 2026-10-07, v1.15.0 on 2026-10-01. Patch releases within days of a minor suggests fast iteration, and the repository is not archived with the last push on 2026-10-13. Licence is GPL-3.0, which matters if you intend to modify and redistribute it, and the documentation lives at https://traefik-manager.xyzlab.dev/.

Editorial conclusion

Traefik Manager earns its place if you already run Traefik on a homelab and edit dynamic.yml by hand at inconvenient hours, since every route change becomes a form and every change gets a timestamped backup. It is the wrong tool for a team that keeps Traefik configuration in Git with reviews, because the UI writes the same file and offers to push it for you afterwards. Before exposing it, set `COOKIE_SECURE=true` behind an HTTPS proxy, add a TOTP account, and mount `traefik.yml` read-write only if you actually want the static config tab, since that file can restart your proxy.

Frequently asked questions

Official sources

1. chr0nzz/traefik-manager on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases