I believe that the maturity days are not applied as they should be

[ciltocruz]

Drydock version

1.6.0-rc.1

What happened?

I have a container configured with a 5-day maturity period.

I expect the system to allow an update if the new image is older than that.

But no, it seems to still be based on the date Drydock discovers the new image.

What did you expect?

I expect the system to allow an update if the new image is older than that.

Steps to reproduce

1. I have a Docker container with an update from weeks ago in GHCR, for example.
2. I set the maturity to 5 days (only mature).
3. Should I start DryDock from scratch? -> (It seems that with each DryDock image recreation, the image discovery time is reset.)
4. The image cannot be updated, even though the latest tag, version, or version number is older than the required maturity.

Relevant configuration

Logs

Installation method

Docker Compose

Docker version

No response

OS / Architecture

No response

[scttbnsn]

First off, thank you for all the testing you've been doing on these RCs. Between this one, #496, #535, #490 and the discussions, you've personally flushed out more real bugs in the maturity/update pipeline than anyone else, and every report has been detailed enough to actually act on. Genuinely appreciated, this kind of feedback is what release candidates are for.

Dug into this fully and found the actual mechanism. It's not what either of us guessed at first, and it's two separate problems that compound.

1. GHCR publish dates never load without a token. Pulling public images from GHCR needs no credentials, which is the setup our docs describe. But the publish date lookup uses a different API (GitHub's Packages REST API), and that one returns 401 without a read:packages token even for fully public packages. Right now that failure is swallowed silently (it only shows at debug log level), so the maturity clock quietly falls back to "when drydock first saw the update" instead of the image's real publish date. That's exactly your symptom, and with a tokenless GHCR image it happens every time. Docker Hub isn't affected, its metadata API works anonymously. This is GHCR-specific (and lscr.io, which shares the same code path).

2. The clock doesn't survive drydock's own recreation unless /store is persisted. The bridge that carries the detection timestamp across restarts is in-memory, and if /store isn't mounted as a volume the whole store comes back empty when drydock's container is recreated, so every timestamp gets re-stamped to "now". Our Quick Start compose doesn't mount /store, so it's easy to hit without knowing. That's your "each recreation resets the discovery time" observation.

Two questions to confirm which of these you're hitting:

1. Is /store mounted as a persistent volume in your compose file?
2. Do you have a DD_REGISTRY_GHCR_..._TOKEN configured for this registry?

My money's on "no" to both, which would mean you're at minimum hitting the GHCR gap, probably both.

What we're doing about it: we can't make GitHub's API accept anonymous requests, so the fix is making the failure loud (a real warning instead of a hidden debug line), showing in the blocker message and API which clock the gate actually used so you don't have to guess, fixing the docs (the /store mount in Quick Start, and being upfront that trusted GHCR publish dates need a read:packages token even for public images), and warning at startup when the store comes up empty. That lands right after the current RC's soak finishes rather than being squeezed into the cut that's already in flight.

One more thing you'll care about: the NEW/MATURE badge in the container list uses its own hardcoded 7-day window based on detection time. It doesn't look at your configured maturity days at all, so it can happily disagree with the gate that's actually blocking you. That's a separate bug from all of the above and probably explains a chunk of the confusion back in #451 too. It's tracked and getting fixed on its own track, along with consolidating the several different "update age" calculations into one shared implementation.

Workaround in the meantime: set a read:packages token for the GHCR registry (works fine for public images) and mount /store as a volume. With those two in place the gate measures from the real publish date and keeps its clock across restarts.

[ciltocruz]

Yes, I have a GHCR token configured. I did it because I noticed many of the images were generating errors, and after reading the documentation, I saw I needed a read:packages token. So yes, I have it.
And yes, i mount store in my docker compose.

I apologize for harping on this, but I came to Drydock looking for software that allows Docker updates after a certain amount of time has passed since the image was released, mainly to avoid supply chain attacks or using secure but broken images that require subsequent repairs.

That's why I'm so fixated on getting this functionality working perfectly.

In fact, I'd add a rather complex possibility (I'm sure) which is to check for versions instead of days. This happens a lot with Home Assistant, for example. For instance, version 2026.7.0 is released. We know that's a major version change. I'd like to be able to update at least when two versions have passed between my current version and the one that's available when a major version is released. But this definitely deserves a separate discussion. hahaha

[scttbnsn]

Please don't apologize for following up, this is exactly the kind of testing we can't do ourselves at scale, and every round of it has made the release better. Your two answers plus the screenshots actually cracked this open completely, so thank you again.

Your transmission screenshot is the entire bug family in one image. The top says the image is 2 weeks old (30/6), and the maturity gate says 3 days remaining on a 5 day window, meaning its clock started 14/7. Two different clocks disagreeing on the same screen. Here's the full trace of why:

The date at the top and the date the gate uses come from different places, on purpose but badly. The "image age" shown in the UI comes from the image's own metadata (its build date). The maturity gate deliberately refuses that date, because whoever builds an image controls its build timestamp, and your whole use case is supply chain caution. The gate only trusts a push date fetched from the registry itself, and when it can't get one it falls back to "when drydock first saw the update". That conservative fallback is defensible; doing it silently while the UI happily shows the build date next to it is not. Consolidating all of these onto one clear clock (and showing you which clock the gate used) is on the roadmap from the audit we did after your report.

Why your GHCR token didn't help for this container: transmission is a linuxserver image, which means lscr.io, and lscr.io is a separate registry in drydock. Registry credentials are configured per provider, so a DD_REGISTRY_GHCR_* token applies only to ghcr.io/... images. Your lscr.io images route to the LSCR provider, which was still anonymous, and its publish date lookup goes to GitHub's package API for the linuxserver org, gets a 401, and that failure is currently swallowed at debug level. Detection clock fallback, exactly your symptom. The fix for you is one env pair, same GitHub username and token you already have:

- DD_REGISTRY_LSCR_PRIVATE_USERNAME=<your github username>
- DD_REGISTRY_LSCR_PRIVATE_TOKEN=<the same read:packages token>

After a restart, the next scan should anchor transmission's gate on the real 30/6 push date, and since that's already older than 5 days the blocker should clear immediately. That's a good end-to-end test of the whole chain.

One check on the token itself. I reproduced today that GitHub's package API rejects tokens without the read:packages scope with a 403, and their newer "fine-grained" tokens can fail here too even when image pulls work fine. It needs to be a classic personal access token with read:packages. And right now a 403 gets swallowed exactly like the 401, so you'd never see it. If you want to see what the API is actually saying, set DD_LOG_LEVEL=debug and grep the logs for Remote publish date lookup failed.

The reset on recreation, with your store mounted. I traced the restart path in the code: a plain restart with a working store file preserves the clock, so with your mount this should not be resetting. Two ways it still can: the store only saves to disk every 5 minutes and there's no flush on shutdown yet, and worse, if the save itself is failing (say a permissions problem on the bind directory) it fails silently forever, so the file on disk stays empty and every recreation looks like a fresh install. Could you check /share/DockerVolumes/drydock for a dd.json, whether it's non-empty, and whether its modified time advances while drydock runs? That one look tells us which case you're in. Also, does 14/7 around 13:54 match when you last recreated or upgraded drydock? A version upgrade can also legitimately restart the clock when the stored update candidate changes shape.

What's queued from all of this: loud warnings when the publish date lookup fails (with the actual status code), the gate reporting which clock it used, a startup warning when a mounted store comes up empty, logging store save errors, and flushing the store on shutdown. Those land in the release right after the RC that's in final validation now, since none of this started in the RCs (it's all pre-existing behavior your testing surfaced).

On the version-based maturity idea (wait N releases instead of N days, like Home Assistant majors): I really like it as a supply chain control, and it's a genuinely different axis from the day-based gate, so please do open it as its own feature discussion so it doesn't get buried in this bug thread. It deserves a proper design conversation.

[ciltocruz]

Why your GHCR token didn't help for this container: transmission is a linuxserver image, which means lscr.io, and lscr.io is a separate registry in drydock. Registry credentials are configured per provider, so a DD_REGISTRY_GHCR_* token applies only to ghcr.io/... images. Your lscr.io images route to the LSCR provider, which was still anonymous, and its publish date lookup goes to GitHub's package API for the linuxserver org, gets a 401, and that failure is currently swallowed at debug level. Detection clock fallback, exactly your symptom. The fix for you is one env pair, same GitHub username and token you already have:

• DD_REGISTRY_LSCR_PRIVATE_USERNAME=
• DD_REGISTRY_LSCR_PRIVATE_TOKEN=
  After a restart, the next scan should anchor transmission's gate on the real 30/6 push date, and since that's already older than 5 days the blocker should clear immediately. That's a good end-to-end test of the whole chain.

Let's work on this specific case.

If we go to https://hub.docker.com/r/linuxserver/transmission?tag=latest, the latest image is from 3 days ago.

If we go to https://github.com/linuxserver/docker-transmission/releases, the latest image is also from 3 days ago, typed with 4.1.3-r0-ls354.
If we go here: https://github.com/linuxserver/docker-transmission/pkgs/container/transmission, the latest image, as before, is from 3 days ago.

What's happening in drydock?

It offers a version from 2 weeks ago, typed with 4.1.3-r0-ls352. I've restarted the container. I've created the LSCR token. I've updated the images to check for updates. Nothing changes.

Here the logs:

82
[19:13:48.280]
debug
registry.hub.public
Get linuxserver/transmission tags
83
[19:13:49.200]
debug
registry.hub.public
hub.public - Get linuxserver/transmission:latest manifest
84
[19:13:49.355]
debug
registry.hub.public
linuxserver/transmission - Found manifests [{"schemaVersion":2,"mediaType":"application/vnd.oci.image.index.v1+json","manifests":[{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:4c06d264b4a0ebb7ea2a2f9a6c70560898f32f76e6bbc7f0c00ebc949eb511d0","size":2189,"platform":{"architecture":"amd64","os":"linux"}},{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:d655629b3f331f3857773e36eec73f75b1c9800eb50debefe283515ea306c6a9","size":841,"annotations":{"vnd.docker.reference.digest":"sha256:4c06d264b4a0ebb7ea2a2f9a6c70560898f32f76e6bbc7f0c00ebc949eb511d0","vnd.docker.reference.type":"attestation-manifest"},"platform":{"architecture":"unknown","os":"unknown"}},{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:f691c784799cd55ab0d07a65754d6499b6b8eba282dcfab25cd944b30a3352a2","size":2189,"platform":{"architecture":"arm64","os":"linux"}},{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:dcc9c773c675bab889d3d4d927afb8adac04a2d014b2f2b5817ccd9da323c89e","size":839,"annotations":{"vnd.docker.reference.digest":"sha256:f691c784799cd55ab0d07a65754d6499b6b8eba282dcfab25cd944b30a3352a2","vnd.docker.reference.type":"attestation-manifest"},"platform":{"architecture":"unknown","os":"unknown"}}]}]
85
[19:13:49.355]
debug
registry.hub.public
linuxserver/transmission - Manifests found with schemaVersion = 2
86
[19:13:49.355]
debug
registry.hub.public
linuxserver/transmission - Manifests media type detected [application/vnd.oci.image.index.v1+json]
87
[19:13:49.355]
debug
registry.hub.public
linuxserver/transmission - Filter manifest for [arch=amd64, os=linux, variant=undefined]
88
[19:13:49.356]
debug
registry.hub.public
linuxserver/transmission - Manifest found with [digest=sha256:4c06d264b4a0ebb7ea2a2f9a6c70560898f32f76e6bbc7f0c00ebc949eb511d0, mediaType=application/vnd.oci.image.manifest.v1+json]
89
[19:13:49.356]
debug
registry.hub.public
linuxserver/transmission - Calling registry to get docker-content-digest header
90
[19:13:49.825]
debug
registry.hub.public
linuxserver/transmission - Manifest found with [digest=sha256:4c06d264b4a0ebb7ea2a2f9a6c70560898f32f76e6bbc7f0c00ebc949eb511d0, version=2]
91
[19:13:49.826]
debug
registry.hub.public
hub.public - Get linuxserver/transmission:sha256:30d59b253993df8c7634fe03cbb33e22324d00d200ff3d3cc30e6184fa55f96b manifest
92
[19:13:50.226]
debug
registry.hub.public
linuxserver/transmission - Found manifests [{"schemaVersion":2,"mediaType":"application/vnd.oci.image.index.v1+json","manifests":[{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:a31e77c27fdeee17e4301bcacf9bbbe2dab1b7b1e6645620a2daf238a179dc49","size":2189,"platform":{"architecture":"amd64","os":"linux"}},{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:cd29ba6046872a45da25a193094d2a2598cfbb2658aa190e4f29f530ac1f427f","size":841,"annotations":{"vnd.docker.reference.digest":"sha256:a31e77c27fdeee17e4301bcacf9bbbe2dab1b7b1e6645620a2daf238a179dc49","vnd.docker.reference.type":"attestation-manifest"},"platform":{"architecture":"unknown","os":"unknown"}},{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:c36c6acb71dc3dca3fa318bf53bfc8feae3d842456ba7c8eaa8f60288b4fb71b","size":2189,"platform":{"architecture":"arm64","os":"linux"}},{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:33ce5d542196e58b7fb463455870dd0c660245ea356eb129a56abdf4bcdb1b40","size":839,"annotations":{"vnd.docker.reference.digest":"sha256:c36c6acb71dc3dca3fa318bf53bfc8feae3d842456ba7c8eaa8f60288b4fb71b","vnd.docker.reference.type":"attestation-manifest"},"platform":{"architecture":"unknown","os":"unknown"}}]}]
93
[19:13:50.227]
debug
registry.hub.public
linuxserver/transmission - Manifests found with schemaVersion = 2
94
[19:13:50.227]
debug
registry.hub.public
linuxserver/transmission - Manifests media type detected [application/vnd.oci.image.index.v1+json]
95
[19:13:50.227]
debug
registry.hub.public
linuxserver/transmission - Filter manifest for [arch=amd64, os=linux, variant=undefined]
96
[19:13:50.227]
debug
registry.hub.public
linuxserver/transmission - Manifest found with [digest=sha256:a31e77c27fdeee17e4301bcacf9bbbe2dab1b7b1e6645620a2daf238a179dc49, mediaType=application/vnd.oci.image.manifest.v1+json]
97
[19:13:50.227]
debug
registry.hub.public
linuxserver/transmission - Calling registry to get docker-content-digest header
98
[19:13:50.706]
debug
registry.hub.public
linuxserver/transmission - Manifest found with [digest=sha256:a31e77c27fdeee17e4301bcacf9bbbe2dab1b7b1e6645620a2daf238a179dc49, version=2]
99
[19:13:50.887]
debug
trigger.docker.espejo
Skipping update-available notification for local_transmission (excluded-from-allow-list)
100
[19:13:50.887]
debug
trigger.docker.plesk
Skipping update-available notification for local_transmission (excluded-from-allow-list)

I am sure that together we will resolve these inconsistencies.
💪💪💪

Could you check /share/DockerVolumes/drydock for a dd.json, whether it's non-empty, and whether its modified time advances while drydock runs? That one look tells us which case you're in. Also, does 14/7 around 13:54 match when you last recreated or upgraded drydock? A version upgrade can also legitimately restart the clock when the stored update candidate changes shape.

The last time I recreated the container was when version 1.6.0 rc1 was released, so it seems the date doesn't reset to the same point in time.
I have dd.json, and the last change was made just minutes ago.

[ciltocruz]

I'm starting to think the two-week date refers to when my current image was installed, not the new one.

Is that possible?

Digest: sha256:a31e77c27fde ---> sha256:4c06d264b4a0

If so, it's correct, but perhaps the information should be changed:

- Age of the installed image: 2w 6/30/2026, 5:33:35 PM
- Installation date (if possible, using logs with the Docker creation date; it's not reliable if it's an installation date via DryDock because it can be installed manually with Portainer, Compose, or similar).
- Update status
Update available — auto-dispatch is filtered (manual works).
Date of the new image found: 3d 7/14/2026 XX:YY:ZZ
Maturity policy waiting
Maturity policy requires updates to be at least 5 days old (from override) (2 days remaining).
1d 18h 24m · Lifts at 19/7/2026, 13:54:13

[ciltocruz]

Yes, that's it.

My 6 containers have recent images between 1 and 4 days old. The maturity policy is working. It's just that the information being displayed is strange.
This comment #556 (comment) is no more important. It's a presentation error, there's no malfunction.

Changes I would make.

• If the image is maturing, we've lost the little clock icon that used to appear in the list. Now it's always blue, and you think you can update.

• I don't know what this button does; it takes me here: But it's empty. I would include the link to the hub where the information is extracted from (dockerhub, ghrc...)

http://192.168.1.153:3005/registries?q=hub.public

[scttbnsn]

You just did the best QA pass this feature has ever had. Seriously, thank you. And you got to the answer before I did: the gate was right the whole time, and the UI talked you (and me) out of believing it.

Two corrections on my side first, because you earned them:

1. Your logs settled it: transmission is coming from registry.hub.public, so it's Docker Hub, not lscr.io. My LSCR advice was wrong for this container (it still applies to images actually pulled as lscr.io/..., but yours aren't). Hub publish dates work anonymously, which is why the gate's clock landed on 14/7, the real push date of ls354. Sorry for sending you off to create a token you didn't need for this one.
2. Your read of the "2w" date is exactly right: that's the build date of the image you're currently running, not the candidate. The candidate is 3 days old, the gate says 3 days old, everything agrees except the label.

So, functionally: nothing wrong. What's left is the three presentation problems you found, and I traced all three in the code so they're real, tracked, and specific:

1. The age label. Your proposed layout is basically what we're building: "age of the installed image" labeled as such, the new image's date shown next to the maturity blocker, and the gate stating which clock it used. That work was already queued from the earlier audit, and your mockup text is going into the design notes.

2. The missing maturity clock in the list is a real v1.6 regression. I diffed the list component against v1.5.1: the little inline clock that used to render next to the tag chip was dropped in the v1.6 list rework. A clock indicator still exists in the update-state column and on the new cards, but not next to the tag, so with your column layout there's no maturing signal anywhere and the blue tag reads as "ready to update". The gate isn't affected (it still blocks), which is why this ships in the next release after the RC that's in final validation now rather than invalidating that one's 24-hour acceptance run.

3. The empty registries page is a filter bug. The button links to /registries?q=hub.public, but the registries page search only matches the name and type fields separately, never the combined hub.public form, so it's guaranteed to find nothing. Easy fix. Linking out to the actual registry page for the image (Docker Hub, GHCR) like you suggested is a good idea and is noted with it.

I've folded all three into the same display-honesty batch as the clock-source work, so they land together and the panel finally tells one consistent story.

And thanks for opening #558 for the version-based idea, I'll pick up the design conversation over there.

[ciltocruz]

Haha, well, I'll leave the token for LSCR since it works the same as for GitHub.

I will be keeping an eye on this progress in future RCs.

Thanks, Scott

[scttbnsn]

Sounds good, and the LSCR token genuinely does no harm, it'll start earning its keep the moment any of your images actually pull from lscr.io.

I'll post here when the display fixes (age labels, list clock, registries link) land in an RC so you can beat them up too. Thanks again for riding this one all the way to the bottom.