Improve upgrade behavior for non-postgres containers

[olieidel]

First off - thanks so much for dokku, it's amazing. Bought you multiple coffees, chuckle..

This issue is about upgrading postgres containers which are not based on the default postgres image, e.g. pgvector. Either I'm missing something, or some things could be improved 🙂

1. postgres:upgrade defaults to the postgres image, even for non-postgres containers

The problem was that I was running a pgvector image created as follows (taken from the readme):

dokku postgres:create pgvector-database --image "pgvector/pgvector" --image-version "pg17"

Now, when calling postgres:upgrade pgvector-database, it defaults to the postgres:17.5 image, which is the default image and tag for the postgres plugin right now. That, of course, is unexpected.

It might be preferable that dokku throws an error here or at least makes the user confirm that they want to proceed.

More broadly: If postgres:upgrade is called on a postgres container running a specific image, and the postgres:upgrade image differs from the current image, show a warning and make the user confirm that they want to proceed.

There are multiple scenarios here:

• User is running pgvector and runs postgres:upgrade without specifying an image: In this case, show a warning because the upgrade would use the postgres image which differs from the current pgvector image.
• User is running pgvector and runs postgres:upgrade while specifying a totally different image (not pgvector, not postgres). Show a warning, too, because the images differ.
• User is running postgres (default) and runs postgres:upgrade while specifying a different image (e.g. pgvector). Show a warning.

2. Upgrading a non-postgres container doesn't work if the tag remains the same

Let's assume that pgvector pushed a newer version to Docker, e.g. under the pg17 tag. Let's also assume that we're running pgvector/pgvector:pg17 in our dokku host, but an older image than the newly-released one.

In this case, there's no trivial way to upgrade.

Running this:

dokku postgres:upgrade pgvector-database --image "pgvector/pgvector" --image-version "pg17"

Results in -----> Service pgvector-database already running pgvector/pgvector:pg17.

So dokku doesn't "know" that a newer pg17 image exist - okay, that's understandable.

But interestingly, running docker pull pgvector/pgvector:pg17 manually to pull the newer image (which works), and then running the above command again also results in -----> Service pgvector-database already running pgvector/pgvector:pg17. So dokku doesn't realize that a newer image exists, even if that newer docker image has already been pulled locally.

Not sure what the best solution for this is, but the root problem is essentially that dokku doesn't allow any postgres upgrades to a newer image with the same tag.

I solved it by creating a new postgres container, dumping the db and importing it, but it felt a bit over-engineered for a minor version upgrade 😄

That being said.. this might be intended behavior. Most docker images indeed have more descriptive tags, and it feels like a bit of an antipattern for pgvector to throw all minor postgres upgrades (17.4 --> 17.5 etc.) into one tag (pg17).

(Side note: All of this is tangentially related to #264 which is mostly about major postgres upgrades, whereas this issue is about non-postgres container upgrades)

Thanks for reading! And feel free to ignore any of these issues if I missed something and/or your intended behavior in dokku differs from what I'd expect. None of these issues are critical and dokku is still awesome!

[onestardao]

this reads like no.13 – multi-agent chaos from our 16-problem list: the dokku-postgres plugin assumes it’s managing a postgres image and overwrites the logic for non-postgres containers during upgrade. there’s also a dash of no.14 – bootstrap ordering when the command sequence assumes the wrong image/tag state and turns the upgrade into a no-op.

practical fixes we’ve seen work:

• add a type guard: inspect container labels/annotations; if image family ≠ postgres, refuse with a clear message unless the user passes --force --image=<repo:tag>.
• require explicit target image/tag for non-postgres upgrades; only default to postgres when a type=postgres label is present.
• preflight check: compare current image digest vs target; if tag is the same but digest differs, pull + retag; otherwise report “no upgrade needed”.
• split the flow: postgres-specific hooks only when type=postgres; otherwise run a generic upgrade path (pull, recreate/restart) without db-migrations.
• emit structured logs (json) for each step so regressions are traceable.

mit-licensed project here; cold start to ~600 stars in ~60 days. we’ve helped 80+ developers fix similar cross-tool drift. if you want the playbook for multi-agent chaos + bootstrap ordering, say the word and i’ll share.