[Idea] I built Home Assistant Apps for both Traefik Manager and Traefik Manager Agent

[charlestephen]

What problem does this solve?

I hope you can include them in your upstream repo for anyone using Traefik with Home Assistant. They are the thinnest wrapper around your upstream repository images and build automatically.

Proposed solution

Links:
https://github.com/charlestephen/hassio-apps/tree/main/traefik-manager-agent
https://github.com/charlestephen/hassio-apps/tree/main/traefik-manager

Alternatives you've considered

Nothing, as Traefik is the most robust and I use it everywhere I can, thus why I built these.

Which area does this relate to?

Other

Additional context

No response

[chr0nzz]

Thanks for putting these together, @charlestephen! Building straight on the official images and tracking releases automatically is a good setup. I pulled your amd64 Traefik Manager image and started it with a test options.json. It booted cleanly, stored everything under /data/config and served the login page.

While I was looking through the wrappers, I noticed a few things:

1. The TM entrypoint skips the image's own startup

ha-entrypoint.sh runs:

exec gunicorn --bind 0.0.0.0:5000 --workers 2 app:app

That bypasses /app/gunicorn.conf.py. As a result you get gunicorn's default sync workers with no threads and a 30s timeout, instead of the gthread workers (4 threads each, 60s timeout) the app is tuned for. With only two sync workers, a couple of slow requests can stall the whole UI. It also skips /app/scripts/docker-entrypoint.sh. That script only matters for PUID/PGID today, but it's where future startup logic will go. I'd suggest:

cd /app
exec /app/scripts/docker-entrypoint.sh gunicorn --config /app/gunicorn.conf.py app:app

The agent wrapper can do the same with exec /usr/local/bin/docker-entrypoint.sh tma.

2. The agent's default Traefik API URL looks like your own setup

traefik-manager-agent/config.yaml defaults traefik_api_url to http://69356281-traefik:8080, which looks like the hostname of your own Traefik add-on. DOCS.md says the default is http://traefik:8080. In the same file, DOCS.md says config_path defaults to /data/config, but config.yaml sets /config/traefik/dynamic. It would help to make the defaults and the docs say the same thing.

3. The agent add-on shows an "Open Web UI" button

The agent add-on sets webui: http://[HOST]:[PORT:8090], but port 8090 is the agent API, not a browser UI. Users will get a button that leads to a blank or error page. Dropping webui (and panel_icon) would avoid that.

4. A blank cert resolver isn't really unset

The upstream image sets ENV CERT_RESOLVER=cloudflare, so leaving the option blank still gives cloudflare (you can see it in the boot log). Your docs say blank options fall back to "not set". You could either note that cloudflare is the default or put it in options so people can see it.

5. Minor

• A comment in the TM entrypoint says COOKIE_SECURE defaults to true upstream. It actually defaults to false. It has no effect because the option is always passed through, but the comment is misleading.
• The TM add-on doesn't map /ssl. If someone's Traefik writes acme.json there, the Certificates tab won't be able to read it unless they move the file to /share. You might add ssl:ro or mention this in the docs.

One more thing that's on our side, not yours: on first boot both gunicorn workers each generated and logged an auto-generated password, so the log showed two different ones and only one worked. This happened with the plain upstream image too. It's fixed on dev and will ship in the next release, so your add-on will pick it up on the next bump. Until then, setting Admin password in the add-on options avoids it.

Thanks again for sharing these!

[charlestephen]

Working on correcting the issues you pointed out right now.