Viewing logs of the Traekif-Manager-Agent in the binary installation

[shrimphorticulturist]

Is there any log availables of the TMA service binary ?

In fact, my installation of the binary TMA on a second LXC instance works (seen in green in Traefik-Manager) but makes errors :

Maybe it's a permission issue on yml files but without logs it's hard to investigate.

Thx.

[yhay81]

Yes. The binary installation runs TMA as a systemd service, so its stdout/stderr is in the system journal rather than a separate log file.

Use:

sudo systemctl status tma --no-pager -l
sudo journalctl -u tma -n 200 --no-pager
sudo journalctl -u tma -f

The last command follows new messages while you reproduce the error. This is the unit name used by the documented binary install: https://github.com/chr0nzz/traefik-manager/blob/e9ad656a3e27c9f0429b96de0c7e172753746ccd/docs/agent.md#install-via-binary

For the suspected YAML permission issue, also inspect the exact unit configuration and path permissions:

sudo systemctl cat tma
sudo namei -l /path/from/CONFIG_PATH

The service needs access not only to each .yml file, but also execute/traverse permission on every parent directory and write permission on the config directory when it creates backups or replaces files. After changing the unit or environment, run:

sudo systemctl daemon-reload
sudo systemctl restart tma

If journalctl -u tma says there is no such unit, run systemctl list-unit-files | grep -i tma and substitute the actual unit name created by your installer.

[shrimphorticulturist]

Hi, thx for the answer.

The only lines in journactl are those even if i reproduce the error :

Jul 24 13:09:24 rev-prox-ext systemd[1]: Stopped tma.service - Traefik Manager Agent.
Jul 24 13:09:24 rev-prox-ext systemd[1]: Started tma.service - Traefik Manager Agent.
Jul 24 13:09:24 rev-prox-ext tma[4977]: 2026/07/24 13:09:24 TMA v1.7.3 listening on :8090 (traefik=https://urlobfuscated/, insecure-tls=false)

On sur Traefik-Manager instance, there's a specific traefik-manager user who own the yaml files or conf.d folder.
On TMA, no specific users, what kind of permission should i grant ?

[yhay81]

The ownership on the central Traefik Manager host does not carry over to the remote TMA host. TMA only needs access to the paths on the LXC where tma.service runs.

First, check the effective account:

systemctl show tma -p User -p Group
pid=$(systemctl show tma -p MainPID --value)
ps -o user=,group=,cmd= -p "$pid"

The documented binary unit has no User= line, so an empty User value means the system service runs as root. If that is your setup, it already has filesystem permission and changing modes is unlikely to fix this. The first thing I would verify is the configured path: /app/config is the container-oriented example, not usually the native Traefik path. Point TMA at the real path on this LXC, for example:

[Service]
Environment=CONFIG_DIR=/etc/traefik/conf.d
Environment=BACKUP_DIR=/var/lib/traefik-manager/backups
# Or, for one file:
# Environment=CONFIG_PATH=/etc/traefik/dynamic.yml

Then run systemctl daemon-reload && systemctl restart tma. You can safely show the non-secret path/account lines with:

systemctl cat tma | grep -E '^(User|Group)=|Environment=(CONFIG_PATH|CONFIG_DIR|CONFIG_PATHS|BACKUP_DIR)='
namei -l /etc/traefik/conf.d

Please do not paste the complete unit because it contains TMA_API_KEY.

If you intentionally run TMA as a dedicated user, give that user group-based access (not chmod 777): it needs read/write on the YAML files, traverse/write on the containing directory so it can create or atomically replace files, and write access to BACKUP_DIR. For example, add both the Traefik and TMA users to a shared group, set the directory group and setgid bit, then configure User=tma, Group=traefik-config, and UMask=0007 in the service. Verify with:

sudo -u tma test -r /etc/traefik/conf.d/example.yml
sudo -u tma test -w /etc/traefik/conf.d/example.yml
sudo -u tma test -w /etc/traefik/conf.d
sudo -u tma test -w /var/lib/traefik-manager/backups

Given the unit shown in the project docs, though, I would check the actual CONFIG_PATH/CONFIG_DIR before changing any permissions.

[shrimphorticulturist]

I got no TMA account :

User=
Group=
root     root     /usr/local/bin/tma

The service constants :

Environment=CONFIG_PATH=/etc/traefik
Environment=CONFIG_DIR=/etc/traefik/conf.d
f: /etc/traefik/conf.d
drwxr-xr-x root    root    /
drwxr-xr-x root    root    etc
drwxr-xr-x traefik traefik traefik
drwxr-xr-x traefik traefik conf.d

I made some progress, i assume the errors were in CONFIG_PATH and CONFG_DIR.
Now i have this message :

It come from the basic_auth middleware i have on the api.
I looked in the documentation I dindn't see any possibility to configure a user and password just like the traefik-manager host.

[chr0nzz]

That 401 is the whole answer, and it's good news - it rules out permissions and TLS entirely. TMA reached your Traefik fine; Traefik's API replied 401 Unauthorized. So this isn't a yml permission issue at all (the binary agent runs as root anyway, and it never got that far).

What's happening: TRAEFIK_API_URL is pointed at a Traefik endpoint that's behind authentication - a dashboard/API route with basicAuth, forwardAuth, or similar in front of it (your earlier startup line showed https://.../, a public URL). TMA has no way to send Traefik dashboard credentials - the internal API isn't meant to be authenticated - so every call comes back 401, and the Manager shows "Could not load routes."

The fix is to point the agent at Traefik's internal, unauthenticated API, not the public URL. On the same LXC as Traefik that's normally:

TRAEFIK_API_URL=http://localhost:8080

which needs Traefik's admin API on :8080 (api.insecure: true, bound to localhost - it stays local-only on that box, so it's off the internet). Edit the Environment=TRAEFIK_API_URL=... line in /etc/systemd/system/tma.service, then:

sudo systemctl daemon-reload
sudo systemctl restart tma

You can confirm which endpoint is which by curling from the LXC:

curl -si http://localhost:8080/api/http/routers | head -1    # want: HTTP/1.1 200 OK
curl -si https://your-public-url/api/http/routers | head -1  # this is the one returning 401

Point TMA at whichever returns 200. That's the same internal API the Host Manager uses, which is why it works there but not through the public URL.

One thing that's on me: the agent only returns these errors to the Manager UI and doesn't write them to its own journal, which is why journalctl was a dead end here - a 401 should have been obvious from the start. The next release adds an optional TMA_DEBUG=true that logs each failed Traefik call (status and URL) to the journal, so this is visible next time. Thanks for the detailed reproduction, and thanks @yhay81 for jumping in.

[chr0nzz]

Quick follow-up: rather than only pointing the agent at an unauthenticated API, the next release lets it authenticate to a protected Traefik API directly. Set TRAEFIK_API_USER and TRAEFIK_API_PASSWORD on the agent and it'll send basic auth on every Traefik API call, so you can keep your existing setup as-is. The installer will also ask for it when you tell it the API is behind basic auth. Shipping alongside the TMA_DEBUG logging in the same release. Thanks again for the detailed report - it turned into two improvements.

[shrimphorticulturist]

Thx again and sorry to add you some more work ;-)
My Traefik API is on port 6081. But if I don't use the FQDN to access it, Traefik return à 404 error.

Maybe it's because of my traefik.yml configuration :

  traefik:
    address: :6081
    http:
      middlewares:
        - auth@file
    forwardedHeaders:
      trustedIPs: 10.0.10.0/24
      insecure: false
    proxyProtocol:
      trustedIPs: 10.0.10.0/24
      insecure: false

[yhay81]

The 404 is consistent with a Host rule mismatch, not with the port being wrong. Your secure api@internal router likely matches the FQDN, so a request whose Host is localhost falls through to Traefik's default 404.

You can prove that without changing the config:

curl -si -H 'Host: your-api-fqdn.example' \
  http://127.0.0.1:6081/api/http/routers | head -1

If that changes the result from 404 to 401, the router matched and only Basic Auth remains. Your auth@file middleware on the entrypoint explains the 401.

For the upcoming version, keep the FQDN in TRAEFIK_API_URL and set the new TRAEFIK_API_USER / TRAEFIK_API_PASSWORD. If you want the request to stay inside this LXC while still satisfying the Host rule, map that FQDN to 127.0.0.1 in /etc/hosts; using the FQDN in the URL also preserves TLS hostname validation.

The other safe design is a separate loopback-only API router/entrypoint without auth@file, bound to 127.0.0.1, for TMA. Do not expose an unauthenticated api@internal entrypoint on the LAN. Given that credential support is already coming, the FQDN + Basic Auth approach is the smallest change.

[shrimphorticulturist]

I get a 404 error with this command.

Anyway, I will wait for the implementation of TRAEFIK_API_USER / TRAEFIK_API_PASSWORD to keep the API securized.

Greetings

[chr0nzz]

v1.8.0 is out, and it has two things aimed straight at what you hit here.

You can now keep your authenticated Traefik API and give the agent credentials. Set TRAEFIK_API_USER and TRAEFIK_API_PASSWORD on the agent and it sends HTTP Basic Auth on every Traefik API call, so the 401 goes away without having to expose an unauthenticated endpoint. (Pointing the agent at the internal http://localhost:8080 API still works too, if you'd rather do that instead.)

TMA_DEBUG=true makes the agent log each failed Traefik call - the URL and the returned status - to the journal, so a 401 or a connection error shows up in journalctl -u tma instead of only in the Manager UI.

To upgrade your binary install, grab the new agent binary:

sudo systemctl stop tma
sudo curl -fsSL https://github.com/chr0nzz/traefik-manager/releases/latest/download/tma-linux-amd64 -o /usr/local/bin/tma
sudo chmod +x /usr/local/bin/tma

(swap amd64 for arm64 or armv7 if that matches your box)

Then add the credentials to /etc/systemd/system/tma.service under [Service]:

Environment=TRAEFIK_API_USER=your-username
Environment=TRAEFIK_API_PASSWORD=your-password
Environment=TMA_DEBUG=true

and reload:

sudo systemctl daemon-reload
sudo systemctl restart tma

The startup line now reports whether auth and debug are active, so you can confirm it picked them up:

sudo journalctl -u tma -n 20 --no-pager
# ...listening on :8090 (traefik=..., traefik-auth=true, debug=true)

Give it a try and let me know how it goes. Thanks again for the detailed report - it's what drove both of these.

[shrimphorticulturist]

Hi,

Okay, I made it, TMA is correctly connected to Traefik API with TLS and BasicAuth. Thanks for the functionality.

But it can only see "Certs", "Logs" and "Services" but "Routes" and "Middlewares" are count to 0 despite it seen 8 routes on top charts.

Maybe it's a permission issue on /etc/traefik/conf.d folder ?
drwxr-xr-x 2 traefik traefik 13 Jul 26 11:16 conf.d

Nothing on service journal.

[chr0nzz]

That's not a permission problem either, and it's the same root cause as the 401 was not: the agent runs as root, so it reads /etc/traefik/conf.d regardless of the traefik:traefik ownership.

What's happening: the Routes and Middlewares tabs are built from the dynamic-config files the agent reads at CONFIG_PATH, while Services, Certs, Logs, and the top-of-page counts come from the Traefik API and other paths. Your 8 routes are file-provider (@file), and the agent deliberately does not re-list file-provider routers from the API (they are meant to show from the files themselves). So if CONFIG_PATH is not pointed at the directory holding your router .yml files, Routes and Middlewares come back empty while everything API-based still works.

Check it:

sudo systemctl cat tma | grep CONFIG_PATH

It should be your dynamic-config directory:

Environment=CONFIG_PATH=/etc/traefik/conf.d

Then:

sudo systemctl daemon-reload
sudo systemctl restart tma

One caveat: the agent reads .yml / .yaml files directly in that folder, not recursively, so if your routers live in subfolders point it at the right level. If it is already set to /etc/traefik/conf.d, tell me and we will look closer.

[shrimphorticulturist]

I was confused by your previous post about CONFIG_DIR and CONFIG_PATH

[Service]
Environment=CONFIG_DIR=/etc/traefik/conf.d
Environment=BACKUP_DIR=/var/lib/traefik-manager/backups
# Or, for one file:
# Environment=CONFIG_PATH=/etc/traefik/dynamic.yml

With this configuration I have an error on loading routes :

Environment=CONFIG_PATH=/etc/traefik/conf.d
#Environment=CONFIG_DIR=/etc/traefik/conf.d
Environment=BACKUP_DIR=/var/lib/traefik-manager/backups
Environment=STATIC_CONFIG_PATH=/etc/traefik/traefik.yml

Same with this one :

Environment=CONFIG_PATH=/etc/traefik/conf.d
Environment=CONFIG_DIR=/etc/traefik/conf.d
Environment=BACKUP_DIR=/var/lib/traefik-manager/backups
Environment=STATIC_CONFIG_PATH=/etc/traefik/traefik.yml

This configuration make no errors, but do not load routes :

Environment=CONFIG_PATH=/etc/traefik
Environment=CONFIG_DIR=/etc/traefik/conf.d
Environment=BACKUP_DIR=/var/lib/traefik-manager/backups
Environment=STATIC_CONFIG_PATH=/etc/traefik/traefik.yml

[chr0nzz]

That confusion is my fault, and the docs made it worse. Let me clear it up.

The agent has no CONFIG_DIR. It reads CONFIG_PATH only. CONFIG_DIR and CONFIG_PATHS exist on the Traefik Manager server, not on TMA - the snippet you found with CONFIG_DIR is from the native Linux install page, which covers installing the manager on a host, not the agent. Setting CONFIG_DIR on the agent does nothing at all; it is silently ignored.

CONFIG_PATH handles both cases on its own - it takes either a directory or a single file:

Environment=CONFIG_PATH=/etc/traefik/conf.d

That is the right setting for your layout. You can drop CONFIG_DIR entirely.

Why your third attempt showed no routes and no error: with CONFIG_PATH=/etc/traefik, the agent reads the .yml files sitting directly in that folder and does not recurse into subdirectories. So it found traefik.yml - your static config, which contains no routers - parsed it fine, and reported zero routes. No error, nothing to show. Pointing at /etc/traefik/conf.d is correct.

I have updated the agent docs to say this explicitly, and added a note to the Linux page clarifying that it is the manager install, not the agent.

For the error you get with CONFIG_PATH=/etc/traefik/conf.d - that one I do not want to guess at, since the last time I guessed on this thread I was wrong and your exact error text is what solved it. Could you paste the exact message?

It also helps to see what the agent itself returns, which rules out the manager entirely:

curl -s -H "X-Api-Key: YOUR_TMA_API_KEY" http://localhost:8090/api/configs | head -c 600

Run that on the agent box with the key from /etc/systemd/system/tma.service. It should list each .yml file in conf.d with its contents. If that looks right, the problem is on the manager side parsing them; if it errors or comes back empty, it is the agent.

One thing worth checking while you are there: does conf.d contain any .yml file that is not a Traefik dynamic config - a template, a backup, a partial file? The agent hands every .yml in the folder to the manager, and one file that does not parse can surface as a load error for the tab.

[shrimphorticulturist]

Ok it's way clearer that way.
I corrected my tma.service and I have this error message on the WebUI :

This is the output from your command (I obfuscated the name of the yml file, router and service name and domain) :

{"files":[{"name":"CustomRoute.yml","content":"http:\n  # Add the router\n  routers:\n    CR-router:\n      entryPoints:\n      - websecure\n      service: CR-service\n      rule: Host(`customroute.mydomain.net`)\n      tls:\n#        passthrough: false\n        certResolver: \"letsencrypt-dns\"\n        domains:\n          - main: \"mydomain.net\"\n            sans:\n              - \"*.mydomain.net\"\n              - \"*.sub.mydomain.net\"\n\n\n  # Add the service\n  services:\n    CR-service:\n      loadBalancer:\n        servers:\n        - url: \"http://ipaddress:port\"\n

This output is truncated (-c 600) since I have 11 yml files (10 for routes and http services and 1 for middlewares) and nothing else in the conf.d folder

The Logs from TMA daemon are not very wordy :

Jul 28 15:37:13 rev-prox-ext systemd[1]: Stopped tma.service - Traefik Manager Agent.
Jul 28 15:37:13 rev-prox-ext systemd[1]: Started tma.service - Traefik Manager Agent.
Jul 28 15:37:13 rev-prox-ext tma[9479]: 2026/07/28 15:37:13 TMA v1.8.0 listening on :8090 (traefik=customroute.mydomain.net, insecure-tls=false, traefik-auth=true, debug=true)

[shrimphorticulturist]

Hello,
I continue my investigation for the "Could not load routes" error.
I have identify those python errors in the traefik-manager service when I request routes to a TMA :

Aug 22 11:00:39 rev-prox-int gunicorn[35745]: 2026-08-22 11:00:39,791 [ERROR] [traefik-manager] Agent routes error
Aug 22 11:00:39 rev-prox-int gunicorn[35745]: Traceback (most recent call last):
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:   File "/opt/traefik-manager/app.py", line 5364, in api_agent_routes
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:     apps.extend(_build_apps(config, config_file=fname,
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                 ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             extra_http_svcs=combined_http,
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             extra_tcp_svcs=combined_tcp,
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             extra_udp_svcs=combined_udp,
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             api_svc_urls=svc_urls))
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:   File "/opt/traefik-manager/core/routes_build.py", line 260, in _build_apps
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:     target = servers[0].get('address', 'N/A')
Aug 22 11:00:39 rev-prox-int gunicorn[35745]:              ^^^^^^^^^^^^^^
Aug 22 11:00:39 rev-prox-int gunicorn[35745]: AttributeError: 'str' object has no attribute 'get'
Aug 22 11:00:39 rev-prox-int gunicorn[35745]: 2026-08-22 11:00:39,826 [INFO] [traefik-manager] 10.0.10.107 → POST /api/notifications/log
Aug 22 11:00:40 rev-prox-int gunicorn[35745]: 2026-08-22 11:00:40,439 [INFO] [traefik-manager] 10.0.10.107 → GET /api/agents/a45cd7d4-1b93-4757-8142-730e29776e27/routes
Aug 22 11:00:40 rev-prox-int gunicorn[35745]: 2026-08-22 11:00:40,755 [ERROR] [traefik-manager] Agent routes error
Aug 22 11:00:40 rev-prox-int gunicorn[35745]: Traceback (most recent call last):
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:   File "/opt/traefik-manager/app.py", line 5364, in api_agent_routes
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:     apps.extend(_build_apps(config, config_file=fname,
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                 ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             extra_http_svcs=combined_http,
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             extra_tcp_svcs=combined_tcp,
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             extra_udp_svcs=combined_udp,
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             api_svc_urls=svc_urls))
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:                             ^^^^^^^^^^^^^^^^^^^^^^
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:   File "/opt/traefik-manager/core/routes_build.py", line 260, in _build_apps
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:     target = servers[0].get('address', 'N/A')
Aug 22 11:00:40 rev-prox-int gunicorn[35745]:              ^^^^^^^^^^^^^^
Aug 22 11:00:40 rev-prox-int gunicorn[35745]: AttributeError: 'str' object has no attribute 'get'
Aug 22 11:00:40 rev-prox-int gunicorn[35745]: 2026-08-22 11:00:40,784 [INFO] [traefik-manager] 10.0.10.107 → POST /api/notifications/log

I am not fully trained on python, so I won't dig deeper, but maybe this is a consitant lead.

[chr0nzz]

That message is generic, and that is our fault - the server knows why it failed
and the UI throws the reason away. I am fixing that so it names the cause.

Meanwhile, two things will tell us which failure it is.

The response itself. Open the browser devtools Network tab, reload the
Routes tab, and find the request to /api/agents/<id>/routes. The status and
body are what matter:

• 502 with Cannot reach agent means the manager cannot open a connection to
  the agent at all
• 500 with a message means it reached the agent and something else broke
• no response at all points at the browser to manager hop, not the agent

The manager's own log, which records the traceback for the 500 case:

docker compose logs traefik-manager | tail -40

Worth ruling out one thing while you are there: your curl ran on the agent box
against localhost, which proves the agent works but not that the manager can
reach it. From the manager's container:

docker exec traefik-manager wget -qO- --header="X-Api-Key: YOUR_TMA_API_KEY" \
  http://AGENT_IP:8090/api/configs | head -c 200

If that fails, the problem is the manager to agent hop and nothing to do with
your config files.

For what it is worth, I ran the CustomRoute.yml you pasted through the parser
and it loads correctly - one router, TLS with the resolver and both SANs. So the
file is not what is breaking this.

[shrimphorticulturist]

Hi

Here is the navigator side error HTTP500 when accessing routes.

On https://traefik-manager.xxxxxxx/api/agents/a45cd7d4-1b93-4757-8142-730e29776e27/routes

and

The wget command on the agent machine and from the distant Traefik-Manager output the same :
{"files":[{"name":"xxxx.yml","content":"http:\n # Add the router\n routers:\n HA-router:\n entryPoints:\n - websecure\n service: HA-service\n rule: Host(xxxx`

[chr0nzz]

That is the last piece, thank you. Between the traceback and this, the picture
is complete: the agent is reachable, it serves the file correctly, and the
Manager crashes while parsing it. Your wget returning the same output from
both machines rules out connectivity entirely.

Also, apologies for the Docker commands in my last message. Your Manager is a
systemd install, so journalctl was right all along and you had already found
the answer there.

The cause. One of your services has its servers entry written as a bare
string instead of a mapping. Traefik Manager assumed a mapping, called .get()
on a string, and the whole request died with the 500 you are seeing. That is
why the entire tab is empty rather than just that one service, and it explains
the very first symptom in this thread back in July: Routes and Middlewares
showing 0 while the charts showed 8 routes. The charts read Traefik's API, the
tab reads your files.

Find it on the agent box:

grep -rn -A2 'servers:' /etc/traefik/conf.d/*.yml \
  | grep -E '^\S+[-:][0-9]+[-:]\s*-\s+[^ ]' \
  | grep -vE '\b(url|address):'

Anything it prints is the culprit. The fix is to name the key:

# crashes
servers:
  - 10.0.10.50:8123

# correct, TCP or UDP
servers:
  - address: "10.0.10.50:8123"

# correct, HTTP
servers:
  - url: "http://10.0.10.50:8123"

That gets your Routes tab back straight away on the version you are running.

The crash is fixed and ships in the next release. A bare string is read as
the address now instead of throwing, so one malformed service can no longer hide
every other route in the file. The generic "Could not load routes" is going too,
replaced by whatever the server actually reported.

If you want to confirm it before release, a native install follows the branch
rather than a Docker tag:

cd /opt/traefik-manager
git fetch origin && git checkout dev && git pull
source venv/bin/activate
pip install -r requirements.txt gunicorn
bash scripts/setup-assets.sh
sudo systemctl restart traefik-manager

git checkout main and repeat the last four lines to go back. Your config and
settings are untouched either way.

No obligation to test it. You have already given us the thing that mattered, and
this turned into two fixes.

[shrimphorticulturist]

This line is giving headaches to the TMA and I don't know why (identify with your curl regex) :

        servers:
        - "10.0.10.43:32400"

[shrimphorticulturist]

Ok I get it :

        servers:
        - address: "10.0.10.43:32400"

Now, the TMA agent works fine.