Can't set up auto updates to work

[lrnd1]

I would like to set up auto-update for all of my docker containers on a schedule at 4:00 AM with their tags being respected (ex. :latest pulls the latest version, and postgres:16-alpine pulls latest :16-alpine version without using labels in other compose files.
I've red through the docs/issues, been trying out different settings, asked 3 different Ais (they all started hallucinating), but nothing seems to work. Auto update never happens and I can't figure out what I'm doing wrong.

Logs with security completely disabled, - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW=* * * * * and - DD_WATCHER_LOCAL_CRON=22 * * * *:

4/25/2026, 2:21:02 PM
WARN
drydock
DD_SESSION_SECRET is not set; using an ephemeral session secret. Set DD_SESSION_SECRET to a strong persistent value.
4/25/2026, 2:21:02 PM
WARN
api
Unversioned /api/* path is deprecated and will be removed in v1.6.0. Use /api/v1/* instead.
4/25/2026, 2:21:02 PM
INFO
security.scheduler
Scheduled security scanning not configured (DD_SECURITY_SCAN_CRON not set)
4/25/2026, 2:21:02 PM
INFO
api
Server listening on port 3000 (HTTP)
4/25/2026, 2:21:02 PM
INFO
watcher.docker.local
Cron started (22 * * * *)
4/25/2026, 2:21:03 PM
INFO
watcher.docker.local
Listening to docker events
4/25/2026, 2:21:03 PM
WARN
watcher.docker.local
Cannot get a reliable tag for this image [sha256:d64e33b6936acfd55fdbec9e4ba496b4322865d8b33977cec1725f4f2f81df16]
4/25/2026, 2:21:03 PM
WARN
drydock
Watching digest for image codeswhat/drydock with domain undefined may result in throttled requests
4/25/2026, 2:21:14 PM
INFO
watcher.docker.local
Cron finished (94 containers watched, 0 errors, 27 available updates)

Manually triggering updates from GUI work fine.
I'm using portainer, so I'd stick to only triggering simple Docker updates only, without setting up DD_TRIGGER_DOCKERCOMPOSE.

Below my docker-compose file:

services:
  drydock:
    image: codeswhat/drydock:latest
    container_name: drydock
    depends_on:
      socket-proxy-drydock:
        condition: service_healthy
    volumes:
      - /Applications/docker/drydock/store:/store
      #- /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TZ=${TZ}
      ## Socket proxy
      - DD_WATCHER_LOCAL_HOST=socket-proxy-drydock
      - DD_WATCHER_LOCAL_PORT=2375
      #- DD_RUN_AS_ROOT=true
      #- DD_ALLOW_INSECURE_ROOT=true
      - DD_SERVER_TRUSTPROXY=1
      ## Auth
      #- DD_AUTH_BASIC_ADMIN_USER=${DD_ADMIN_U}
      #- DD_AUTH_BASIC_ADMIN_HASH=${DD_ADMIN_Pw}
      - DD_PUBLIC_URL=${DD_URL}
      - DD_AUTH_OIDC_AUTHENTIK_CLIENTID=${DD_CID}
      - DD_AUTH_OIDC_AUTHENTIK_CLIENTSECRET=${DD_CSec}
      - DD_AUTH_OIDC_AUTHENTIK_DISCOVERY=${DD_DISC}
      - DD_AUTH_OIDC_AUTHENTIK_REDIRECT=true # optional (to skip internal login page)
      ## Security
      - DD_SECURITY_SCANNER=trivy
      - DD_SECURITY_BLOCK_SEVERITY=none #CRITICAL
      - DD_SECURITY_SCAN_CRON=0 3 * * *
      - DD_SECURITY_SCAN_BATCH_TIMEOUT=2700000
      #- DD_SECURITY_VERIFY_SIGNATURES=true
      - DD_SECURITY_COSIGN_IDENTITY=https://github.com/CodesWhat/drydock/.github/workflows/release.yml@refs/tags/*
      - DD_SECURITY_COSIGN_ISSUER=https://token.actions.githubusercontent.com
      - DD_SECURITY_SBOM_ENABLED=true
      - DD_SECURITY_SBOM_FORMATS=spdx-json,cyclonedx-json
      ## Notification
      - DD_TRIGGER_TELEGRAM_TG_BOTTOKEN=${DD_Telegram_Tok}
      - DD_TRIGGER_TELEGRAM_TG_CHATID=${DD_Telegram_ChatID}
      - DD_TRIGGER_NTFY_NTFY_URL=${DD_ntfy_URL}
      - DD_TRIGGER_NTFY_NTFY_TOPIC=${DD_ntfy_Topic}
      - DD_TRIGGER_NTFY_NTFY_AUTH_TOKEN=${DD_ntfy_TOK}
      ## Updates
      #- DD_TRIGGER_DOCKER_LOCAL_DRYRUN=true     # preview only — remove when ready
      - DD_TRIGGER_DOCKER_LOCAL_AUTO=true
      - DD_TRIGGER_DOCKER_LOCAL_PRUNE=true      # clean up old images
      - DD_TRIGGER_DOCKER_LOCAL_BACKUPCOUNT=1
      - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW=0-10 4 * * *
      #- DD_WATCHER_LOCAL_CRON=2 * * * *
      - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW_TZ=${TZ}
      - DD_WATCHER_LOCAL_WATCHALL=true
      ## Registries
      - DD_REGISTRY_HUB_PUBLIC_LOGIN=${DD_REG_Docker_U}
      - DD_REGISTRY_HUB_PUBLIC_TOKEN=${DD_REG_Docker_Tok}
    labels:
      - dd.update.mode=infrastructure
      - dd.watch.digest=true
    #ports:
    #  - 3000:3000
    networks:
      - drydock-backend 
      - drydock-tunnel

  socket-proxy-drydock:
    image: tecnativa/docker-socket-proxy:latest
    container_name: socket-proxy-drydock
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - CONTAINERS=1
      - IMAGES=1
      - EVENTS=1
      - SERVICES=1
      - POST=1 # Add POST=1 for container actions (start/stop/restart) or auto-updates
      - NETWORKS=1 # Add NETWORKS=1 if using the Docker trigger for auto-updates
    labels:
      - dd.update.mode=infrastructure
      - dd.watch.digest=true
    networks:
      - drydock-backend
    healthcheck:
      test: wget --spider http://localhost:2375/version || exit 1
      interval: 5s
      timeout: 3s
      retries: 3
      start_period: 5s
    restart: unless-stopped

networks:
  drydock-tunnel:
    name: drydock-tunnel
  drydock-backend:
    name: drydock-backend 
    internal: true

[scttbnsn]

Your env config is structurally fine — DD_TRIGGER_DOCKER_LOCAL_AUTO=true (legacy alias, accepted through v1.7.0) registers the docker action trigger with auto=all, and unlabeled containers pass the trigger gate. I reproduced your exact env on rc.12 and rc.13 and the auto path engages correctly.

The reason 27 updates were detected but none fired is almost certainly a trigger-level gate, not a per-container one. To narrow it down I need two things:

1. Full startup log from container start through the first cron tick (not just one cycle) — I'm specifically looking for whether these lines appear:

   • Legacy trigger environment variable "DD_TRIGGER_DOCKER_LOCAL_AUTO" is deprecated...
   • trigger.docker.local: Register with configuration {...}
   • trigger.docker.local: Registering for auto execution (all watched containers)

2. One cron tick with DD_LOG_LEVEL=debug so we can see the per-container skip reason. The debug log will name the exact gate, e.g.:

   • Skipping update-available notification for <name> (excluded-from-allow-list) — UI notification rule for update-available doesn't include docker.local
   • Skipping update-available notification for <name> (rule-disabled) — notification rule turned off
   • Threshold not reached => ignore (...)
   • Skipped auto update (Update blocked by security scan...)

If you've configured notification rules in the UI (Settings → Notification rules), check the update-available rule first — if its trigger allow-list is non-empty and doesn't include docker.local, every container is silently filtered out.

[lrnd1]

Thank you for the quick answer!

Full startup log:

4/26/2026, 9:10:02 AM
INFO
drydock
drydock is starting in Controller mode (version = 1.4.5)
4/26/2026, 9:10:02 AM
INFO
store
Load store from (/store/dd.json)
4/26/2026, 9:10:02 AM
INFO
prometheus
Init Prometheus module
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind trigger for provider docker
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind trigger for provider telegram
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind trigger for provider ntfy
4/26/2026, 9:10:02 AM
INFO
trigger.docker.local
Register with configuration {"backupcount":"1","auto":"true","prune":"true","dryrun":"true"}
4/26/2026, 9:10:02 AM
INFO
trigger.docker.local
Registering for auto execution
4/26/2026, 9:10:02 AM
INFO
trigger.telegram.tg
Register with configuration {"chatid":"[REDACTED]","bottoken":"[REDACTED]","disabletitle":false,"messageformat":"Markdown","auto":true,"order":100,"threshold":"all","mode":"simple","once":true,"simpletitle":"New ${container.updateKind.kind} found for container ${container.name}","simplebody":"Container ${container.name} running with ${container.updateKind.kind} ${container.updateKind.localValue} can be updated to ${container.updateKind.kind} ${container.updateKind.remoteValue}${container.result && container.result.link ? \"\\n\" + container.result.link : \"\"}","batchtitle":"${containers.length} updates available","resolvenotifications":false}
4/26/2026, 9:10:02 AM
INFO
trigger.ntfy.ntfy
Register with configuration {"topic":"monitoring","url":"[REDACTED]","auth":{"token":"[REDACTED]"},"auto":true,"order":100,"threshold":"all","mode":"simple","once":true,"simpletitle":"New ${container.updateKind.kind} found for container ${container.name}","simplebody":"Container ${container.name} running with ${container.updateKind.kind} ${container.updateKind.localValue} can be updated to ${container.updateKind.kind} ${container.updateKind.remoteValue}${container.result && container.result.link ? \"\\n\" + container.result.link : \"\"}","batchtitle":"${containers.length} updates available","resolvenotifications":false}
4/26/2026, 9:10:02 AM
INFO
trigger.telegram.tg
Registering for auto execution
4/26/2026, 9:10:02 AM
INFO
trigger.ntfy.ntfy
Registering for auto execution
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider alicr
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider codeberg
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider dhi
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider docr
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider ecr
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider gar
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider gcr
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider ghcr
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider hub
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider ibmcr
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider lscr
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider mau
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider ocir
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider quay
4/26/2026, 9:10:02 AM
INFO
registry
Register all components of kind registry for provider trueforge
4/26/2026, 9:10:02 AM
INFO
registry.dhi.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.ecr.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.gar.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.gcr.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.hub.public
Register with configuration {"token":"[REDACTED]","login":"<myuser>"}
4/26/2026, 9:10:02 AM
INFO
registry.mau.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.alicr.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.ghcr.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.ibmcr.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.ocir.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.quay.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.docr.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.lscr.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.trueforge.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
registry.codeberg.public
Register with configuration {}
4/26/2026, 9:10:02 AM
INFO
watcher.docker.local
Register with configuration {"host":"socket-proxy-drydock","watchall":true,"port":2375,"cron":"11 * * * *","maintenancewindow":"* * * * *","maintenancewindowtz":"Europe/Bucharest","socket":"/var/run/docker.sock","jitter":60000,"watchbydefault":true,"watchevents":true,"watchatstart":true,"imgset":{},"maintenancewindowopen":true,"maintenancewindowqueued":false,"maintenancenextwindow":"2026-04-26T06:11:00.000Z","authblocked":false}
4/26/2026, 9:10:02 AM
INFO
watcher.docker.local
Cron scheduled (11 * * * *)
4/26/2026, 9:10:02 AM
INFO
authentication.oidc.authentik
Register with configuration {"discovery":"https://authentik.<mydomain>/application/o/drydock/.well-known/openid-configuration","redirect":true,"clientid":"[REDACTED]","clientsecret":"[REDACTED]","insecure":false,"timeout":5000}
4/26/2026, 9:10:03 AM
WARN
drydock
DD_SESSION_SECRET is not set; using an ephemeral session secret. Set DD_SESSION_SECRET to a strong persistent value.
4/26/2026, 9:10:03 AM
WARN
api
Unversioned /api/* path is deprecated and will be removed in v1.6.0. Use /api/v1/* instead.
4/26/2026, 9:10:03 AM
INFO
security.scheduler
Scheduled security scanning not configured (DD_SECURITY_SCAN_CRON not set)
4/26/2026, 9:10:03 AM
INFO
api
Server listening on port 3000 (HTTP)
4/26/2026, 9:10:03 AM
INFO
watcher.docker.local
Cron started (11 * * * *)
4/26/2026, 9:10:04 AM
INFO
watcher.docker.local
Listening to docker events
4/26/2026, 9:10:04 AM
WARN
drydock
Watching digest for image codeswhat/drydock with domain undefined may result in throttled requests
4/26/2026, 9:10:04 AM
WARN
drydock
Watching digest for image tecnativa/docker-socket-proxy with domain undefined may result in throttled requests
4/26/2026, 9:10:04 AM
WARN
watcher.docker.local
Cannot get a reliable tag for this image [sha256:d64e33b6936acfd55fdbec9e4ba496b4322865d8b33977cec1725f4f2f81df16]
4/26/2026, 9:10:14 AM
INFO
watcher.docker.local
Cron finished (94 containers watched, 0 errors, 28 available updates)
4/26/2026, 9:11:07 AM
INFO
watcher.docker.local
Cron started (11 * * * *)
4/26/2026, 9:11:08 AM
WARN
watcher.docker.local
Cannot get a reliable tag for this image [sha256:d64e33b6936acfd55fdbec9e4ba496b4322865d8b33977cec1725f4f2f81df16]
4/26/2026, 9:11:18 AM
INFO
watcher.docker.local
Cron finished (94 containers watched, 0 errors, 28 available updates)

One cron tick with debug attached:
4:26:2026.log

If you've configured notification rules in the UI (Settings → Notification rules), check the update-available rule first — if its trigger allow-list is non-empty and doesn't include docker.local, every container is silently filtered out.

I had the update-available rule turned off, but turned it on now and assigned to ntfy, before collecting the logs.
docker.local doesn't appear under triggers

Not sure if this matters, but I'm running drydock on a mac mini, using orbstack.

[lrnd1]

Update: I've been doing some more testing. Renamed store to start fresh, noticed dd.json already grew to ~44 MB.

tried env vars:

      - DD_NOTIFICATION_TELEGRAM_TG_BOTTOKEN=${DD_Telegram_Tok}
      - DD_NOTIFICATION_TELEGRAM_TG_CHATID=${DD_Telegram_ChatID}
      - DD_NOTIFICATION_NTFY_NTFY_URL=${DD_ntfy_URL}
      - DD_NOTIFICATION_NTFY_NTFY_TOPIC=${DD_ntfy_Topic}
      - DD_NOTIFICATION_NTFY_NTFY_AUTH_TOKEN=${DD_ntfy_TOK}
      - DD_ACTION_DOCKER_LOCAL_AUTO=true 
      - DD_ACTION_DOCKER_LOCAL_PRUNE=true

It still didn't work. Triggers section empty, and Notifications had no selectable triggers.
Selecting a container and pressing Preview Update also gave an error that it failed.

Then I reverted back to TRIGGER and set image: codeswhat/drydock:1.4
After downgrading, it seems now it's working correctly:

4/26/2026, 12:39:11 PM
INFO
trigger.docker.local
Image lscr.io/linuxserver/prowlarr:latest pulled with success
4/26/2026, 12:39:11 PM
INFO
trigger.docker.local
Do not replace the existing container because dry-run mode is enabled
4/26/2026, 12:39:42 PM
INFO
trigger.docker.local
Image ghcr.io/n8n-io/n8n:latest pulled with success
4/26/2026, 12:39:42 PM
INFO
trigger.docker.local
Do not replace the existing container because dry-run mode is enabled 

[scttbnsn]

Good news — your auto-update is firing. The second log set you posted is the proof:

trigger.docker.local  Image lscr.io/linuxserver/prowlarr:latest pulled with success
trigger.docker.local  Do not replace the existing container because dry-run mode is enabled

Drydock pulled the new image and then refused to replace the container because dry-run mode is on. That second line is the entire reason nothing seems to happen — it's working exactly as designed for DRYRUN=true.

Three things to fix / clarify:

1. You have a stale DRYRUN=true somewhere outside your compose file. Your startup log says the trigger registered with {"backupcount":"1","auto":"true","prune":"true","dryrun":"true"}, even though DD_TRIGGER_DOCKER_LOCAL_DRYRUN=true is commented out in the compose you pasted. Likely sources: a Portainer stack-level env var, an .env file picked up by the compose, or a stale OrbStack/Portainer environment from an earlier deploy that didn't get cleared. Find and remove that env var, then recreate the drydock container — once dryrun is false/absent, replacement will happen and your containers will actually update.

2. DD_NOTIFICATION_* / DD_ACTION_* are v1.5.0+ prefixes — not recognized in 1.4.5. That's why the Triggers and Notifications sections went empty when you tried them. On 1.4.5 you must use the legacy DD_TRIGGER_* form (which is what you're already doing). The new prefixes ship in v1.5.0; once that's out you can switch, or stay on DD_TRIGGER_* (kept as an alias through v1.7.0).

3. docker.local not appearing under notification-rule triggers is by design, not a bug. In the v1.5 taxonomy docker.local is an action trigger (it executes the update), not a notification trigger (it sends a message). The notification-rule UI's trigger picker only lists notification triggers — so you'll see telegram.tg and ntfy.ntfy there, but not docker.local. The docker action's auto-firing is controlled by DD_TRIGGER_DOCKER_LOCAL_AUTO=true on the trigger itself, which you already have set correctly.

Side note on the 44 MB dd.json — that's the audit/history log accumulating; it's not blocking anything but worth its own discussion if it keeps growing. Separate concern from the auto-update path.

TL;DR: turn off the stray dry-run env var and your existing config will start replacing containers on the next maintenance window.

[lrnd1]

1. You have a stale DRYRUN=true somewhere outside your compose file.

I tried multiple times without DRYRUN before, but containers still didn't update. Not sure what changed when it suddenly started updating when I have set a fixed tag for drydock.

2. & 3.

Thanks for the other useful tips, I've also red the docs of v1.5 and got a bit confused there.

I really like the idea of drydock, and how customizable it is, but I'm still having a really hard time comprehending how to set it up correctly.

Not even sure how to explain all of my issues.
For ex. in one of my arr stacks I have 7 containers, and according to portainer, 3 of them has update available.

Drydock shows me only 4, none of those with an update.

In my second arr stack, I can see 7/8 containers, while portainer reports, that 2 of them has update

sonarr missing, redis is showing but no update detected.

There are other containers with similar anomalies.

Good news is that some updates started triggering now, bad news is that tags aren't respected, and not sure how to stop it from breaking my databases with fixed versions set, without setting custom labels to each of them.

[scttbnsn]

Thanks, this helped separate the setup issue from the comparison issue.

There are two separate things here:

1. The auto-update trigger did start firing in the later logs, but that run was still in dry-run mode. If containers are detected and pulled but not replaced, check the running Drydock container for DD_TRIGGER_DOCKER_LOCAL_DRYRUN=true from Portainer stack env, .env, or an older deploy, then recreate the container after removing it.

2. The tag behavior you described is a real Drydock bug. Drydock was not treating mutable tags like latest, stable, and 16-alpine like Portainer does. That could miss same-tag digest updates, and semver-shaped floating tags such as postgres:16-alpine could be handled as tag-jump candidates instead of staying on 16-alpine.

I have a fix queued for the next RC. It is not in the currently published RC yet.

With that fix:

• floating tags compare by digest by default, including Docker Hub
• postgres:16-alpine stays on 16-alpine and updates by digest
• labels like dd.watch.digest=true should not be needed everywhere for this common case
• dd.tag.family=loose remains available if you explicitly want cross-tag semver moves such as 16-alpine -> 17-alpine

Once the next RC is cut, I would test with an exact image tag rather than latest, for example:

image: codeswhat/drydock:<next-rc-tag>

environment:
  - DD_WATCHER_LOCAL_HOST=socket-proxy-drydock
  - DD_WATCHER_LOCAL_PORT=2375
  - DD_WATCHER_LOCAL_WATCHALL=true
  - DD_WATCHER_LOCAL_CRON=0 4 * * *
  - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW=0-10 4 * * *
  - DD_WATCHER_LOCAL_MAINTENANCE_WINDOW_TZ=Europe/Bucharest

  - DD_TRIGGER_DOCKER_LOCAL_AUTO=true
  - DD_TRIGGER_DOCKER_LOCAL_PRUNE=true
  - DD_TRIGGER_DOCKER_LOCAL_BACKUPCOUNT=1

  - DD_REGISTRY_HUB_PUBLIC_LOGIN=...
  - DD_REGISTRY_HUB_PUBLIC_TOKEN=...

Do not set DD_TRIGGER_DOCKER_LOCAL_DRYRUN=true unless you only want a preview. For the v1.5 line, the existing DD_TRIGGER_* env vars remain accepted, so there is no need to rename everything while testing this fix.

[lrnd1]

Thank you. This explains most of my issues. I'll wait for the next release and leave a feedback after testing.

[scttbnsn]

Following up: the floating-tag update fix I mentioned in my April 29 reply has shipped in v1.5.0-rc.19.

With rc.19, floating tags (latest, stable, 16-alpine, etc.) compare by digest automatically — no dd.watch.digest=true label needed everywhere. postgres:16-alpine stays on 16-alpine and updates when a new digest is pushed; it won't jump to 17-alpine unless you set dd.tag.family=loose.

To try it: update your drydock image to codeswhat/drydock:1.5.0-rc.19, remove the stray DRYRUN env var if you haven't already, and let the next maintenance window run. The 27 pending updates should start applying.

Note: the DD_TRIGGER_DOCKER_LOCAL_* prefix you're using is still accepted — it's a supported alias through v1.7.0. If you want to switch to the current canonical form it's DD_ACTION_DOCKER_LOCAL_*, but there's no urgency.

Release: https://github.com/CodesWhat/drydock/releases/tag/v1.5.0-rc.19

[lrnd1]

Sorry for the late feedback, I've been busy with some other projects.
I have tested v1.5 and it works sooo much better.
Would you be open to add a floating tag for 1.5.x?

Additionally, I'd really like to use trivy for security scans and blocking updates with vulnerabilities, however from what I understood it's currently a bit limited to overly loose or overly strict.
If possible, an option would be great to still allow updates when the new version has <= vulnerabilities compared to the current version.
Basically if I'm already running something with 3 critical issues, and the next version has 1/2/3, why block the update?

Update:
After some more testing with v1.5.0-rc.35 it seems to still not follow tags correctly, but also maintenance window wasn't respected either.
In my docker-compose I have getmeili/meilisearch:v1.13.3

44
[21:50:14.986]
INFO
watcher.docker.local
Register with configuration {"host":"socket-proxy-drydock","watchall":true,"port":2375,"cron":"2 * * * *","maintenancewindow":"0-10 4 * * *","maintenancewindowtz":"Europe/Bucharest","socket":"/var/run/docker.sock","jitter":60000,"watchbydefault":true,"watchevents":true,"watchatstart":true,"imgset":{},"maintenancewindowopen":false,"maintenancewindowqueued":false,"maintenancenextwindow":"2026-06-15T01:00:00.000Z","authblocked":false}
45
[21:50:15.000]
INFO
watcher.docker.local
Cron scheduled (2 * * * *)
46
[21:50:15.067]
INFO
authentication.oidc.authentik
Register with configuration {"discovery":"https://authentik.<mydomain>/application/o/drydock/.well-known/openid-configuration","redirect":true,"clientid":"[REDACTED]","clientsecret":"[REDACTED]","insecure":false,"timeout":5000}
47
[21:50:15.236]
WARN
drydock
DD_SESSION_SECRET is not set. Using an auto-generated secret persisted in the store (/store/dd.json). For production deployments, set DD_SESSION_SECRET explicitly and ensure the store directory is not world-readable.
48
[21:50:15.236]
INFO
drydock
Using persisted session secret from store
49
[21:50:15.243]
WARN
api
Unversioned /api/* path is deprecated and will be removed in v1.6.0. Use /api/v1/* instead.
50
[21:50:15.248]
INFO
security.scheduler
Scheduled security scanning not configured (DD_SECURITY_SCAN_CRON not set)
51
[21:50:15.248]
INFO
api
Server listening on port 3000 (HTTP)
52
[21:50:16.005]
INFO
watcher.docker.local
Skipping update check - outside maintenance window
53
[21:50:16.011]
INFO
watcher.docker.local
Listening to docker events
54
[21:51:53.300]
WARN
drydock
Watching digest for image tecnativa/docker-socket-proxy with domain undefined may result in throttled requests
55
[21:51:59.046]
INFO
trigger.docker.local
Pruning previous tags
56
[21:51:59.072]
INFO
trigger.docker.local
Pull image getmeili/meilisearch:v1.46.1
57
[21:52:00.177]
INFO
trigger.docker.local
Image getmeili/meilisearch:v1.46.1 pulled with success
58
[21:52:00.186]
INFO
trigger.docker.local
Rename container karakeep-meilisearch to karakeep-meilisearch-old-1781463119071
59
[21:52:00.202]
INFO
trigger.docker.local
Create container karakeep-meilisearch
60
[21:52:00.265]
INFO
trigger.docker.local
Container karakeep-meilisearch recreated on new image with success
61
[21:52:00.267]
INFO
watcher.docker.local
Name changed from karakeep-meilisearch to karakeep-meilisearch-old-1781463119071
62
[21:52:00.268]
INFO
trigger.docker.local
Stop container karakeep-meilisearch-old-1781463119071 with id 71bf1c00e7eb73fcf883111999e96656bcd8aacc0de6be87613818618a24ea0a
63
[21:52:00.407]
INFO
trigger.docker.local
Container karakeep-meilisearch-old-1781463119071 with id 71bf1c00e7eb73fcf883111999e96656bcd8aacc0de6be87613818618a24ea0a stopped with success
64
[21:52:00.407]
INFO
trigger.docker.local
Start container karakeep-meilisearch
65
[21:52:00.408]
INFO
watcher.docker.local
Status changed from running to exited
66
[21:52:00.502]
INFO
trigger.docker.local
Container karakeep-meilisearch started with success
67
[21:52:02.540]
INFO
trigger.docker.local
Remove container karakeep-meilisearch-old-1781463119071 with id 71bf1c00e7eb73fcf883111999e96656bcd8aacc0de6be87613818618a24ea0a
68
[21:52:02.560]
INFO
trigger.docker.local
Container karakeep-meilisearch-old-1781463119071 with id 71bf1c00e7eb73fcf883111999e96656bcd8aacc0de6be87613818618a24ea0a removed with success
69
[21:52:02.568]
WARN
trigger.docker.local
Unable to sync compose file /data/compose/145/v8/docker-compose.yml for service 'meilisearch' (ENOENT: no such file or directory, open '/data/compose/145/v8/docker-compose.yml')
70
[21:52:02.568]
INFO
trigger.docker.local
Skipping prune of v1.13.3 — retained for rollback
71
[21:52:05.342]
INFO
trigger.docker.local
Pruning previous tags
72
[21:52:05.361]
INFO
trigger.docker.local
Pull image ghcr.io/alexta69/metube:latest
73
[21:52:13.324]
INFO
watcher.docker.local
Skipping update check - outside maintenance window
74
[21:52:19.342]
INFO
watcher.docker.local
Skipping update check - outside maintenance window
75
[21:52:20.159]
INFO
trigger.docker.local
Image ghcr.io/alexta69/metube:latest pulled with success
76
[21:52:20.164]
INFO
trigger.docker.local
Rename container metube to metube-old-1781463125361
77
[21:52:20.179]
INFO
trigger.docker.local
Create container metube
78
[21:52:20.386]
INFO
watcher.docker.local
Name changed from metube to metube-old-1781463125361
79
[21:52:22.304]
INFO
trigger.docker.local
Container metube recreated on new image with success
80
[21:52:22.307]
INFO
trigger.docker.local
Stop container metube-old-1781463125361 with id b736a3514b7128929af201167d53a0a12d4f9942ec247b7027db4610fe97402e
81
[21:52:22.548]
INFO
trigger.docker.local
Container metube-old-1781463125361 with id b736a3514b7128929af201167d53a0a12d4f9942ec247b7027db4610fe97402e stopped with success
82
[21:52:22.548]
INFO
trigger.docker.local
Start container metube
83
[21:52:22.551]
INFO
watcher.docker.local
Status changed from running to exited
84
[21:52:22.699]
INFO
trigger.docker.local
Container metube started with success
85
[21:52:28.717]
INFO
trigger.docker.local
Container metube passed health gate
86
[21:52:28.719]
INFO
trigger.docker.local
Remove container metube-old-1781463125361 with id b736a3514b7128929af201167d53a0a12d4f9942ec247b7027db4610fe97402e
87
[21:52:28.752]
INFO
trigger.docker.local
Container metube-old-1781463125361 with id b736a3514b7128929af201167d53a0a12d4f9942ec247b7027db4610fe97402e removed with success
88
[21:52:28.765]
INFO
trigger.docker.local
Remove image ghcr.io/alexta69/metube@sha256:891ccbb5f025e622c8d9d516b2ec56b8ec79b988be38e5c9958c4b7a83fa1883
89
[21:52:28.989]
INFO
trigger.docker.local
Image ghcr.io/alexta69/metube@sha256:891ccbb5f025e622c8d9d516b2ec56b8ec79b988be38e5c9958c4b7a83fa1883 removed with success
90
[21:52:33.966]
INFO
watcher.docker.local
Skipping update check - outside maintenance window
91
[21:52:58.156]
INFO
watcher.docker.local
Skipping update check - outside maintenance window
92
[21:53:49.124]
INFO
watcher.docker.local
Skipping update check - outside maintenance window
93
[21:54:49.259]
INFO
watcher.docker.local
Skipping update check - outside maintenance window
94
[21:55:40.658]
WARN
release-notes.provider.github
GitHub release notes lookup is rate-limited (unauthenticated) — cooldown active for 2478s

[scttbnsn]

Thanks for the detailed rc.35 logs — that pinned both issues down. Two separate bugs, plus answers to your other asks:

1. v1.13.3 → v1.46.1 (pinned tag climbing). You're right to flag this. Today drydock treats a fully-specified semver tag as a baseline and offers the newest tag of the same shape — that's the current (inherited) behavior, but it's the wrong default for a pinned tag and exactly the footgun you hit. A tag you pinned to an exact version shouldn't jump 33 minor releases on its own.

We're changing the default: a fully-pinned tag like v1.13.3 will update by digest only (same tag, rebuilt) and won't climb versions unless you opt in with dd.tag.include or dd.tag.family=loose. Floating tags (latest, 16-alpine) have worked this way since rc.19; this extends the same logic to exact tags. Landing in the next RC.

Workaround that works today on rc.35 — add an include filter so it can't leave the 1.13 line:

• pin exactly: dd.tag.include=^v1\.13\.3$
• allow 1.13.x patches only: dd.tag.include=^v1\.13\.

2. Maintenance window not respected. Also a real bug — confirmed. The window currently gates the scheduled scan but not every path that can apply an update, so a post-update rescan re-triggered your containers at 21:52 outside your 0-10 4 * * * window. Fix in the same RC: auto-updates will only apply inside the maintenance window regardless of how the update was detected (manual UI/API updates stay immediate by design).

3. Relative-severity Trivy gating (≤ current). Good idea, and on the roadmap — an option to allow an update when the new image's vulnerability counts are no worse than the image you're already running, alongside the existing absolute DD_SECURITY_BLOCK_SEVERITY threshold.

4. "Floating tag for 1.5.x." The rolling 1.5 and 1 image tags publish automatically once v1.5.0 reaches GA (they're disabled for prereleases), so you'll be able to pin codeswhat/drydock:1.5. While we're still on RCs, pin a specific RC tag.

Two minor things from your log, both harmless:

• Unable to sync compose file /data/compose/145/v8/… (ENOENT) — Portainer uses versioned, ephemeral compose paths that change on every stack redeploy; drydock logs it and proceeds, the update still applies. Nothing to fix on your side.
• GitHub release-notes rate-limit — unauthenticated lookups are capped at 60/h. Set DD_AUTH_GITHUB_TOKEN and it goes away.

I'll follow up here when the next RC with the tag + maintenance-window fixes is cut.

[scttbnsn]

v1.5.0-rc.36 is cut — it includes both fixes from this thread.

1. Pinned specific tags no longer climb across versions. A tag with 3+ numeric segments (e.g. v1.13.3, 1.25.5-alpine) is now treated as digest-only by default: Drydock will still re-pull a rebuilt image published under the same tag, but it will no longer jump you from v1.13.3 to v1.46.1. The container view now shows why ("compared by digest only…") instead of silently climbing.

If you do want updates on a pinned tag, opt in per container with an include filter scoped to the range you want:

• dd.tag.include=^v1\.13\.\d+$ → only v1.13.x patch releases (no minor/major jumps), or
• dd.tag.include=^v1\.\d+\.\d+$ → any v1.x.x release, or
• dd.tag.family=loose → full semver climbing (the previous default).

2. Maintenance window now gates automatic updates. Auto-updates are deferred until the window is open (enforced when Drydock scans); a manual Update now from the UI/API still runs immediately.

Pull it:

docker pull codeswhat/drydock:1.5.0-rc.36
# also on ghcr.io/codeswhat/drydock:1.5.0-rc.36 and quay.io/codeswhat/drydock:1.5.0-rc.36

Release notes: https://github.com/CodesWhat/drydock/releases/tag/v1.5.0-rc.36

This is a release candidate — I'll promote it to GA after a short soak with no new reports. A quick confirmation that the pinned-tag behavior now matches what you expected would be hugely helpful. Thanks again for the precise logs that pinned this down. 🙏

[lrnd1]

Thank you for the quick fix!
I have tried rc.37 (using dryrun), and this time I didn't see any of the pinned tags getting updated.

On the other hand, pressing the check for updates button, triggered image downloads despite outside of maintenance window.

[scttbnsn]

Thanks for the rc.37 results, both of these are useful.

The "Check for updates" button applying updates outside the maintenance window is a real bug, and you found a gap in my rc.36 fix. I traced it. rc.36 added the window gate to the scheduled scan path (the cron tick checks the window before it runs). But the manual "Check for updates" button doesn't go through that path. It calls the watcher's watch() directly, which skips the scan-level gate entirely, and your auto-apply action trigger is subscribed to every container report (cron or manual), so it picks up the result and applies the update regardless of the window. So rc.36 closed the scheduled path but left the manual one open. That's on me, the gate was in the wrong layer.

The fix moves the window check onto the apply itself, so an automatic update only applies inside the window no matter how the update was detected (scheduled scan, manual recheck, or a post-update rescan). A manual Update now on a specific container stays immediate by design, that's you explicitly asking for it. This lands in the next 1.5.x release.

On the pinned tags not updating under dry-run, that's actually the fix working. Since rc.36 a fully pinned tag like getmeili/meilisearch:v1.13.3 is compared by digest only. It won't climb to a newer version on its own, which is what was happening before when it tried to jump you to v1.46.1. With dry-run on you'd only see a "pulled with success" line if the registry had republished that exact tag with a new digest. If nothing pulled, there was no new digest for the tag you pinned, which is the correct, quiet result. If what you actually want is patch updates within a line, opt in per container:

• dd.tag.include=^v1\.13\.\d+$ → only v1.13.x patches
• dd.tag.include=^v1\.\d+\.\d+$ → any v1.x.x release
• dd.tag.family=loose → full semver climbing (the old default)

So nothing's broken there, it's just doing the conservative thing now. If you expected a specific container to move and it didn't, tell me the image and tag and I'll check whether the registry actually has a newer digest.

The relative-severity Trivy gating (allow an update when the new image's vuln counts are no worse than what you're already running) is still on the roadmap, not in this release. I'll circle back here when it's scoped.

[scttbnsn]

v1.5.1-rc.2 is cut and it includes the maintenance-window fix from this thread.

I moved the window check onto the apply itself, so the "Check for updates" button can't auto-apply outside the window anymore no matter which path detects the update. Manual "Update now" still goes through immediately by design.

If you can, pull ghcr.io/codeswhat/drydock:1.5.1-rc.2 (or codeswhat/drydock:1.5.1-rc.2 on Docker Hub) and give it a run with your maintenance window set. It should hold the auto-apply until the window opens now. Let me know if it still slips through, I'd rather catch it in the RC than after GA.

If it holds on your end I think that's the last of the bugs from this thread and we can call it done.