The Dashboard and API

Traefik can tell you what it is doing, in two voices: a web dashboard for looking, and a REST API for scripts. Both are served by Traefik itself, on their own entrypoint — port 8080 by convention — and both were live for every chapter so far. Transcript t03 is the raw material for most of this chapter.

What they show

• /api/version — the running build. The first thing to check when behaviour surprises you and the internet's advice assumes another version.
• /api/overview — counts of routers, services and middlewares, with warning and error totals. A nonzero error count here is the smoke alarm for a dynamic file Traefik refused.
• /api/http/routers (and services, middlewares) — the configuration Traefik has actually applied, with each router's rule, status and priority. This is the ground truth that settles every "but I edited the file" argument: if your router is not here, Traefik never accepted it, whatever your editor says.
• /api/rawdata — everything, in one document, for when you want to search the whole applied configuration.
• /ping — a two-letter health answer, OK, on its own entrypoint; made for service managers and load balancers to ask "are you alive" without touching a real site. It exists in the lab because chapter 3's static file asked for it.

The dashboard at /dashboard/ presents the same facts as pages — routers, services, middlewares, entrypoints — and is genuinely useful while learning, because it draws the moving parts of chapter 2 with your names in them. A detail worth knowing: the dashboard's URL needs its trailing slash.

The insecure mode, taken seriously

The lab runs with:

api:
  insecure: true
  dashboard: true

insecure is the project's own word and it is accurate: in this mode the API and dashboard answer anyone who can reach the port, with no password, and the API is not read-only trivia — it exposes your whole routing table, backend addresses included. That is the right setting for a sandbox and the wrong one for any machine with anything on it. The grown-up options, in order of preference:

1. Don't serve it at all on a machine that doesn't need it: omit dashboard and leave insecure unset; the API then exists only as an internal router you can publish deliberately.
2. Publish it like any other site: a router for the dashboard on an HTTPS entrypoint, behind basicAuth or better (the middleware of chapter 6 works on Traefik's internal services — the dashboard's router is dashboard@internal), ideally on an entrypoint your firewall keeps off the internet entirely.
3. At the very least, bind the traefik entrypoint to localhost (address: "127.0.0.1:8080"), so only someone already on the machine can reach it.

Notice what option 2 demonstrates: the dashboard is a service behind the proxy like any other — api@internal and dashboard@internal were in t03's router list all along.

Reading, not writing

The API is a window, not a control panel: it reports configuration, it does not accept changes. You change Traefik by changing what a provider watches — editing a file, relabelling a container — and the API is how you verify the change landed. Workflows that script against it are health checks and inventories, and that is the honest scope of the tool.