Two things: every notification channel can now be set up in the interface, and container updates on Podman work — which, it turns out, they never have.
If you run Podman, this is the release
_build_run_args rebuilds the run command line from a container's inspect dump. It was written against Docker's output, and Podman's differs in three places. Each one is fatal on its own, and they stack, so fixing one only revealed the next.
Config.StopSignal is a number. Docker says "SIGTERM", Podman says 15. That integer went straight into the argument list and Python refused it before the CLI ran at all:
TypeError: expected str, bytes or os.PathLike object, not int
HostConfig.Runtime is oci — not the name of a runtime, but Podman's generic label for whatever is configured. runc was already skipped as Docker's default; oci was not, and handing it back gets:
Error: default OCI runtime "oci" not found: invalid argument
A container in a pod reports NetworkMode: container:<infra-id> — the same shape as a Gluetun-style sidecar, so it was rebuilt as --network container:…, and Podman refuses:
Error: container dependency <id> is part of a pod, but container is not
The first two affect every container on Podman, not just pod members.
Nothing was ever destroyed by this — measured: the recreate fails, the rollback renames the original back and starts it, and a pod member is still in its pod afterwards. But no update could succeed either.
The part I'd rather you knew: test_podman_live.py has driven a real Podman for several releases. It checked that ps worked and that the remote flag was right, and never once built a run command. What was tested was the part that had been thought about. It performs a real recreate in a real pod now.
A Connections page
The notification channels have moved off Settings onto a page of their own, and the four that were environment-only have joined them. That's the lot: Telegram topic and allowed users, both webhooks, the interactive Discord bot, e-mail, ntfy, Gotify, Matrix and Apprise — all configurable in the interface.
One card per channel. Credentials — the SMTP password, the Discord bot token, the ntfy token and password, the Gotify and Matrix tokens, and the Apprise target URLs, where the credential is the URL — are masked, never rendered back into the page, kept out of the logs, redacted in the audit trail, and each has its own checkbox to remove it. An empty field means "leave it alone"; it cannot also mean "delete".
Certificate verification for e-mail is a visible checkbox now, with the reason next to it. SMTP_TLS_VERIFY has existed since the unverified-context defect was fixed, but only as a variable you had to know about — and what it decides is whether your mail password is handed to whatever answers on that address, with any certificate at all.
And a manual check that only looked at one host
The Web UI's "Check Updates" button and Telegram's /check --dry-run each ran on the local checker with no host loop, so on a multi-host install they checked the machine Docksentry runs on and ignored the rest. Measured on a two-host setup with four containers on moving tags: the button reported "Checking 2 containers" and never mentioned the second host.
This is the bad kind of wrong. It does not fail, it answers — and the answer is "checked". A dry run especially: its whole purpose is to be trusted before an update. The scheduled check had always looped; the loop lived in one place and the manual paths never reached it. All three share it now. Discord's /check was never affected.
Nothing to do on upgrade. Every SMTP_*, NTFY_*, MATRIX_*, APPRISE_*, GOTIFY_* and DISCORD_* variable keeps working exactly as before — they seed the fields, and the page marks any value your saved settings have overruled.