I have many doubts about the behavior of drydock.

[ciltocruz]

This application is fantastic. It's a watchtower, but with (a lot of) control. Now I can decide whether or not an update should run based on whether there are vulnerabilities or how long it's been out.

But there's something I'm not quite sure how to do because I don't fully understand its functionality, and I think it has to do with something I don't want to overlook: the latest version.

All my homelab containers are managed by Portainer's Compose. I do a lot of testing and restarting from the container stacks themselves, and, except for a few specific cases, my images are usually "latest."

Another important detail is that I've set my "maturity" to 1 day.

The problem with Drydock is that I don't understand how it handles it. I have containers whose "latest" version is 4 weeks old. And Drydock says the image needs to continue maturing.

I don't know if it's a cache issue, or if it's the latest version (which apparently hasn't changed), or if it's some configuration setting I'm missing, but DryDock just won't say it can be updated. And it turns out this isn't happening with all containers.

I've even considered that the maturation time starts from when Drydock detects a new image, not from when it first existed. But that doesn't seem to have worked either. Days go by and my containers still show the message saying it needs one more day to complete maturation. I don't understand anything.

Can anyone give me some light on this?

[scttbnsn]

Hey ciltocruz, thanks for the detailed writeup. We dug into this and found three separate things stacking up to cause what you're seeing. Fixes for all three are landing in v1.5.1, which is coming out soon.

The main one was a deadlock in the maturity gate. In "mature" mode the code that starts the maturity clock checked whether an update was "available" first, but while an image is still maturing it reports as not-available (the gate is suppressing it), so the clock never started, which kept it suppressed, which kept the clock from starting. That lines up with the "needs one more day" that never ends, and with it not hitting every container: it mainly affects ones first seen while already in mature mode.

Second, you were right that it was counting from when Drydock first detected the image, not when the image was actually published. For Docker Hub and GHCR we're changing it to read the real publish date from the registry, so a 4-week-old :latest with a 1-day maturity should clear on the first scan after you upgrade instead of starting a fresh count.

Third, your Portainer setup is the worst case for a separate bug: every time a stack redeploys, the container gets a new internal ID and Drydock was treating it as brand new and resetting the clock. With frequent restarts and a slow image pull that clock basically never got anywhere. That's changing too, so the maturity age carries across a recreate.

This is all in v1.5.1. Once it's out and you've upgraded, pick one of the previously-stuck containers and trigger a watch from the UI, and let me know whether it shows the update as available or a countdown based on the image's real age. If anything still looks off, tell me the registry and roughly how often that stack redeploys and I'll keep digging.

[ciltocruz]

Thanks, @scttbnsn .

I'll install version 1.5.1 as soon as it's available. If you release a release candidate, let me know and I'll gladly try it out.

[ciltocruz]

A little humor... 😂😂😂😂

[scttbnsn]

Too real! haha

[scttbnsn]

@ciltocruz the RC is up. v1.5.1-rc.1 is published now, so you can try it ahead of the final.

Pull whichever registry you use:

codeswhat/drydock:1.5.1-rc.1
ghcr.io/codeswhat/drydock:1.5.1-rc.1
quay.io/codeswhat/drydock:1.5.1-rc.1

It's multi-arch (amd64 + arm64), so it's fine on a Pi too.

All three fixes from above are in it: the maturity-clock deadlock, counting from the real registry publish date on Docker Hub and GHCR, and the clock surviving a Portainer stack recreate.

Once you're on it, grab one of the containers that was stuck on "needs one more day" and trigger a watch from the UI. With your 1-day maturity, a 4-week-old :latest on Docker Hub or GHCR should flip straight to update-available on that first scan instead of restarting the count. If anything still shows a countdown that won't clear, tell me the registry and roughly how often that stack redeploys and I'll keep digging.

One heads up since it's a release candidate: run it somewhere you're fine testing, not blind on something critical. Full notes are on the release: https://github.com/CodesWhat/drydock/releases/tag/v1.5.1-rc.1

[ciltocruz]

I will test right now.

[ciltocruz]

👀👀👀👀👀👀👀👀

👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏

[scttbnsn]

That's exactly what we wanted to see. The previously-stuck containers are showing up as real updates now instead of sitting on that endless countdown, so all three fixes are doing their job on an actual Portainer + latest setup. Nice.

Thanks for turning it around so fast. If you can leave it running for a few days and flag anything that looks off, that's a big help before I promote rc.1 to the final 1.5.1. And if any single container still refuses to clear, drop the registry plus roughly how often that stack redeploys and I'll dig into that one.

[ciltocruz]

It seems to be working. Although I've blocked my DockerHub quota 😅😅😅

I have some less important questions about the application:

1. Is there a way to check for updates for just one container? I saw a "Check all updates" button. In Actions i see "Scan now" but it seems that scan is for security vulnerabilities.

2. In the container list, there's a column that says "Updated," but... it's not always like that. My "latest" container lights up in blue, indicating an update, but the column next to it says "Updated." I don't know what this column means.

[scttbnsn]

Thanks for the follow-ups — both are addressed in v1.5.1-rc.4:

1. Checking a single container for updates — there's now a per-container Recheck for updates button on each container (side panel, full-page detail, and the row actions), so you don't have to run a global recheck. ("Scan Now" is the Trivy vulnerability scan, not an update check — different thing.)

2. The "Update" column shows the type of update available (Major / Minor / Patch / Digest), or Current/Pinned when there's nothing pending. It's not a "this was updated" state — the new version itself shows in the Tag/Version columns. rc.4 adds a tooltip on the column header that spells this out. If you ever see a row flagged Current (green) that's also showing a pending update, that'd be a real bug — grab a screenshot and I'll dig in.

Please test in rc.4 and let me know.

[ciltocruz]

1. Ok. It works.
2. I undestood. It works fine.
   Thanks!