[Help wanted] Test v1.19.0 standalone-recreate field coverage — compose stacks, resource limits, healthchecks

[amayer1983]

TL;DR

v1.19.0 closes a long-standing bug class: the standalone container-recreate path was silently dropping ~25 fields from docker inspect on every update. Compose-stack containers were the worst hit — service aliases (db, redis, broker, app) vanished on recreate and stacks like Paperless-NGX, Nextcloud, anything that resolves a sibling service by hostname went into restart-loops until a manual docker compose down && up -d rebuilt the aliases.

v1.19.0 release notes.

I'd really appreciate broad testing — this touches the recreate hot-path of every container update, and while I've smoke-tested with synthetic configs, real production stacks vary in ways my test bed can't cover.

Background — what was broken

When Docksentry runs in its own container without the host compose dirs mounted (the typical deployment), _update_compose() can't see the compose YAML and falls back to _update_standalone() — a docker run reconstruction from docker inspect output.

That reconstruction was incomplete. Most prominently for compose users:

docker run --network <project>_default <image>   # what we did before
                                                 ↑
                          --network-alias <service>  ← silently missing

→ Other services in the stack hit Error -5 connecting to broker:6379 / db:5432 - no response after Docksentry updated any single member of the stack.

Other silently-dropped fields included memory/CPU limits, ulimits, healthcheck overrides, working-dir, stop-signal, multi-network attachments, and image-default-aware Cmd/Entrypoint handling. The full list is in the v1.19.0 changelog.

What v1.19.0 changes

• Network aliases / IPs / MAC / links restored on the primary network
• Additional networks re-attached via docker network connect after docker run (multi-network compose pattern)
• Resource limits: memory, CPU, pids, oom, blkio, ulimits, group-add
• Lifecycle: stop-signal, stop-timeout, auto-remove
• Process config: working-dir, domainname, tty, stdin
• Healthcheck overrides (compose healthcheck:)
• Image-default-aware Cmd/Entrypoint — won't lock in OLD image's CMD when a new release changes it
• Audit-mode safety net: DEBUG=true logs [audit] HostConfig.<key> / Config.<key> for any non-default field we don't restore. Future Docker versions adding new keys surface here instead of silently breaking.

How to help

1. Pull v1.19.0

docker pull amayer1983/docksentry:latest
docker compose up -d

2. Pick a compose stack that gave you trouble before

Especially welcome:

• Paperless-NGX, Nextcloud, Immich, anything with db: + redis: companions
• Gluetun + VPN-sidecar stacks (sonarr/radarr/qbittorrent on network_mode: service:gluetun)
• Stacks with cpus: / mem_limit: / pids_limit: set in compose
• Stacks with ulimits: (especially nofile)
• Containers attached to more than one network (e.g. frontend + backend)
• Containers with healthcheck: overrides in compose

3. Trigger a real update through Docksentry

Tap an "Update all" notification or run /check → tap update on a specific container. Don't skip the update from the menu; we want the recreate path actually running.

4. Verify

# Check the recreated container's network aliases
docker network inspect <project>_default | jq '.[0].Containers'

# Verify resource limits stayed
docker inspect <container> | jq '.[0].HostConfig | {Memory, NanoCpus, Ulimits, PidsLimit}'

# Verify multi-network attachment
docker inspect <container> | jq '.[0].NetworkSettings.Networks | keys'

# Verify healthcheck override
docker inspect <container> | jq '.[0].Config.Healthcheck'

For sibling-service resolution: after the update, exec into a sibling container and getent hosts <service> — should still resolve.

5. Enable audit logs (optional but appreciated)

If you've got time, run Docksentry with DEBUG=true for a check-cycle and grep for [audit]:

docker logs docksentry 2>&1 | grep -i '\[audit\]'

Each line is a field that's non-default in your inspect dump but not restored on recreate. Most should be empty for typical setups. If anything shows up — please drop the lines here (or in a new issue), they're concrete hints for what to add next.

What I expect

• No-op for most users. The fields most setups rely on (env, mounts, ports, capabilities, devices, restart policy) were already covered before v1.19.0. v1.19.0 fixes setups that did break.
• Compose stacks survive updates — sibling-service resolution should keep working post-update.
• Resource limits visible in docker inspect post-update — Memory, NanoCpus, Ulimits should match what's in your compose.

What might still go wrong

• Quirky --network-alias interaction with custom network drivers (macvlan, ipvlan) — these have weird Alias semantics. Please flag if you use them.
• Edge cases in Ulimits when soft != hard. Smoke-tested with soft == hard; please verify if your setup uses different soft/hard.
• AutoRemove + RestartPolicy — we skip --rm when restart policy is set (Docker rejects both). Edge case if your inspect has both AutoRemove: true AND RestartPolicy.Name: not common; please flag.

Reporting findings

• It works for your stack → quick 👍 + brief setup description (compose? Portainer? Dockge? what stack?) really helps me know what's been covered
• Something broke → please open a new issue with:
  • Docksentry version (docker exec docksentry cat /app/app/version.py)
  • Docker version (docker --version)
  • Stack type (Paperless, Nextcloud, custom, …)
  • The specific failure mode (logs, error, post-update inspect diff)
  • Any [audit] lines from DEBUG mode

Thanks in advance — closing this bug class once instead of one-field-at-a-time really needs the long tail of real-world stacks I can't simulate here. 🙏

[NotRetarded]

This may explain why Arcane and Arch-QBittorrentVPN went into a boot loop in recent days. Also my Unifi OS container lost its static IP when it got updated. All required compose shut down, update and starts to get working properly.

I'll keep my eye out for such issues going forward and report back.

Edit: I just added a mapping to the compose stack folder, let's see if anything misbehaves.

[amayer1983]

@NotRetarded this is exactly the bug — three confirmations in one comment, each maps to a specific fix in v1.19.0:

Symptom	What we lost on recreate	v1.19.0 fix
Arcane boot loop	Service alias in compose network (api, db, whatever Arcane talks to)	--network-alias restored from NetworkSettings.Networks[<net>].Aliases
Arch-QBittorrentVPN boot loop	Either same alias issue, or the VPN-sidecar pattern (qbittorrent on network_mode: service:gluetun)	network aliases restored + v1.18.10's restart_dependents on head-rollback + 17 HostConfig fields including netns mode
Unifi OS lost static IP	IPAMConfig.IPv4Address silently dropped	--ip flag emitted from inspect's IPAMConfig

Each of those needed a manual docker compose down && up -d before — exactly the workaround signature.

Edit: I just added a mapping to the compose stack folder

That's the cleanest path for future updates — when the compose YAML is reachable from inside Docksentry, the _update_compose() path runs docker compose pull + docker compose up -d --no-deps <service> and you get the full compose semantics (depends_on chains, multiple files merged with -f, profiles). The standalone fallback path (now fixed in v1.19.0) is the safety net for when the compose dir isn't mounted.

You're now the most valuable tester for this fix. Please trigger an Arcane / Arch-QBittorrentVPN / Unifi update through Docksentry in the next few days — the v1.19.0 standalone path should now survive those without manual recovery. The compose mount you just added will likely take precedence and use the compose path, which is also good — but you can manually un-mount one of them to specifically validate the standalone fix if you want to be the empirical hero. 🙏

If anything misbehaves: ideally with DEBUG=true so the [audit] HostConfig.<key> / Config.<key> lines surface in docker logs docksentry. Those are the next set of gaps if any.

[NotRetarded]

@amayer1983 I'll comment out the volume path to the stacks for now. I'll force a test after a fallback to a prior image. But give me till next week so I don't ruin my weekend 😛.