Testing v1.4.0 — rc.12 and beyond

[scttbnsn]

Following up from Testing v1.4.0 (#120) — that thread got pretty long, so starting fresh here for rc.12 and beyond.

---

What's New in rc.12

rc.12 is a big one — 60+ commits since rc.11, covering bug fixes reported by community testers, new features, UI polish, and security hardening.

Bug Fixes (from your reports!)

• Compose directory resolution — DD_TRIGGER_DOCKERCOMPOSE_*_FILE now accepts a directory path and auto-discovers compose.yaml/docker-compose.yml inside it. Thanks @rj10rd! (#84)
• docker.io prefix preserved — Compose mutations no longer strip the explicit docker.io/ registry prefix from image refs. Thanks @larueli!
• Lowercase env var keys — Compose trigger config like composefileonce, digestpinning, reconciliationmode now accepted in any case. Thanks @larueli!
• Legacy hash login on upgrade — SHA-1, APR1, DES crypt, and plaintext htpasswd hashes from v1.3.x are now accepted during upgrade so you can log in and migrate to argon2id. Thanks @Waler!
• TLS healthcheck — Container healthcheck now uses HTTPS when DD_SERVER_TLS_ENABLED=true. Thanks @flederohr!
• Log level propagation — DD_LOG_LEVEL=debug now properly propagates to all log destinations. Thanks @Waler! (#134)
• Feature flags after login — Container action buttons no longer appear disabled after first login. Thanks @RK62!
• HASS entity_picture URL — Fixed broken entity picture in Home Assistant after logo rename. (#138)

New Features

• MQTT HASS entity_picture from icons — entity_picture is now auto-resolved from dd.display.icon labels. Icons with sh:, hl:, or si: prefixes map to CDN image URLs.
• dd.display.picture label — New container label to override the HASS entity picture URL directly.
• PHC argon2id hashes — Basic auth now accepts standard PHC-format argon2id hashes ($argon2id$v=19$...) in addition to the Drydock format.
• Config tab URL deep-linking — Config view tab selection syncs to URL query params for shareable links.
• mTLS client certificate support — Registries now support mutual TLS via CLIENTCERT/CLIENTKEY options.
• Container-update audit events — External container lifecycle changes (restarts, recreates) are now recorded in the audit log.

UI Polish

• Borderless redesign across all views, config tabs, and detail panels
• Dashboard version column left-aligned
• Detail panel expand button redesigned with frame-corners icon
• Sidebar active indicator removed for cleaner look
• Font sizes converted from px to rem

Security

• Unsupported hash formats now fail closed (no plaintext fallback)
• PostMessage origin validation in service worker and demo
• HASS_ATTRIBUTES default preset changed to short (less data exposed)

---

How to Test

docker pull codeswhat/drydock:1.4.0-rc.12

Or pin a specific digest from the packages page.

Full configuration docs: https://drydock.codeswhat.com/docs/configuration

---

Known Issues

• Issue #138 — entity_picture fix + new dd.display.picture label shipping in this RC
• Issue #59 — Local build registry support tracked for v1.7.0

If you hit anything, drop a comment here or open an issue. Thanks to everyone testing — @rj10rd @RK62 @Waler @larueli @flederohr @nchieffo!

[rj10rd]

Sir push image on docker hub

[scttbnsn]

Drydock images are published to GitHub Container Registry (GHCR):

docker pull ghcr.io/codeswhat/drydock:latest

Docker Hub publishing is not currently planned. GHCR is free for public packages with no pull rate limits, which makes it a better fit for open-source distribution.

[flederohr]

Testing version 1.4.0-rc.12:
The manual update of a docker compose managed container fails, as it activates the wrong docker compose trigger.

1. 

---

2. 

---

3. 

---

4. 

---

5. 

[flederohr]

This might be related to the fact that all compose triggers are marked as associated triggers, even when the container is not defined in them.

In my setup i only use the DD_TRIGGER_DOCKERCOMPOSE_{trigger_name}_FILE environment variables,
not the dd.compose.file definition in the labels.

[flederohr]

Updated to version 1.4.0
After Commit 8afbde1 🐛 fix(compose): enforce compose-file affinity for trigger association was added to 1.4.0
I now have no docker compose triggers assigned to my containers.

[flederohr]

Ok i tested around further, regarding the trigger problem.
It looks like the problem is a combination of stored information in the /store/dd.json that prevents new information regarding the trigger to be propagated and the lack of any dd.compose.file labels.

When i unmount the persisted store volume (so it gets reset on restart of the container) and define one dd.compose.file label on any random container the trigger detection works for all containers (also those from other docker-compose files and triggers.

When i remount the store volume again the error reappears.

[scttbnsn]

Thanks for the detailed reports and screenshots — they were instrumental in tracking this down.

Root cause

The 8afbde1 fix introduced compose-file affinity filtering to prevent triggers from being over-associated (the "all 9 triggers" problem you saw in rc.12). However, the path comparison was too strict: it compared the trigger's configured FILE path (resolved inside the Drydock container, e.g. /drydock/monitoring/compose.yaml) against the container's compose file path from Docker Compose project labels (com.docker.compose.project.config_files), which contains the host-side path (e.g. /mnt/volume1/docker/stacks/monitoring/compose.yaml).

These two paths refer to the same file but are resolved from different perspectives (container-internal vs. host), so strict equality always fails → zero compose triggers match → the system falls back to a plain Docker trigger.

Why the compose file was not updated (your last two screenshots)

Because no compose trigger matched, the fallback plain Docker trigger performed the update via Docker Engine API — it pulled the new image and recreated the container, but never touched the compose.yaml. This is why the container appeared updated in the UI (running the new image) while compose.yaml still had the old tag.

The fix

Commit a6ed4c95 on release/v1.4.1 adds suffix-based path matching for the affinity check. Instead of requiring exact path equality, it compares path suffixes (e.g. monitoring/compose.yaml) with safeguards against ambiguous matches (like generic docker/compose.yaml segments). This correctly bridges the host-path vs. container-path mismatch without re-introducing the over-association problem.

Your persisted store observation

Your finding about /store/dd.json is interesting — the persisted store caches container metadata including compose file paths from previous scans. When the affinity logic changed in 8afbde1, stale cached paths could have contributed to the mismatch. The suffix matching in a6ed4c95 handles this more gracefully, and a fresh scan cycle will update the cached paths.

Next steps

This fix is included in the upcoming v1.4.1 release. If you'd like to test beforehand, you can use the pre-release image:

docker pull ghcr.io/codeswhat/drydock:main

We'd appreciate confirmation that the fix resolves both the trigger association and compose file mutation for your setup.

[flederohr]

In version 1.4.0:
Container image is reported to be up-to-date when it hasn't updated the compose.yaml file and has not restarted the container

in the compose.yaml:

[scttbnsn]

This is a direct consequence of the trigger affinity issue explained above.

On v1.4.0, the too-strict path matching meant no compose trigger was associated with your containers. When you triggered an update, the system fell back to a plain Docker trigger (visible as apprise.local in your trigger list). The Docker trigger updates containers through the Docker Engine API (pull → stop → recreate → start), which successfully runs the new image — but it has no knowledge of compose files and never modifies them.

With the fix in v1.4.1 (a6ed4c95), the correct compose trigger will match, and the update flow will:

1. Parse your compose.yaml
2. Update the image tag in the compose file
3. Run the equivalent of docker compose up -d for the affected service

So the compose.yaml will be properly mutated to reflect the new version.

[flederohr]

Only thing is the apprise.local trigger is an Apprise trigger not a Docker trigger

But i will try out in v1.4.1 if the error is fixed

[scttbnsn]

Good catch — you're right, apprise.local is an Apprise notification trigger, not a Docker update trigger. My previous reply was inaccurate on that point.

Looking at the logs from your rc.12 screenshots more carefully, what actually happened is:

1. The manual update selected the dockercompose.mysql trigger (the first compose trigger it found)
2. That trigger tried to match your apprise container against its compose file (/drydock/mysql/compose.yaml)
3. The container's compose file (/drydock/monitoring/compose.yaml) didn't match → the trigger skipped the container
4. The update failed with: "No compose updates were applied for container apprise"

No fallback to a Docker trigger or any other trigger occurred — the update simply errored out. The apprise.local trigger you saw in the associated triggers list was displayed because the UI's trigger association endpoint (before the affinity fix) showed all triggers as associated, regardless of type or compose file membership.

The v1.4.1 suffix-based path matching (a6ed4c95) ensures the correct compose trigger is selected for each container, so the update flow now works as expected. Looking forward to hearing whether it resolves things on your end.

[scttbnsn]

v1.4.1 is now released — all issues reported here (compose trigger affinity, CSRF behind reverse proxies, auth hash detection) have been fixed.

See the v1.4.1 release notes for the full changelog.

Closing this testing thread. Thanks to everyone who tested and reported issues!

[scttbnsn]

Closing this thread — all reported issues were fixed in v1.4.1.

For v1.4.2 testing and feedback, head over to #158.