teampass/teampass:3.2.2.0 on Docker Hub serves 3.2.1.6 content

[btviana]

Summary

The Docker Hub tag teampass/teampass:3.2.2.0 does not contain the 3.2.2.0 codebase. The container boots and self-reports as version 3.2.1.6, and no database migration runs, despite the image being tagged and dated to match the 3.2.2.0 release.

Environment

Image: docker.io/teampass/teampass:3.2.2.0
Digest: sha256:fde80481453c5c2aa5ee142aa35b62ebaff27f54572ad822da6ef6be20d9493c
Image Created: 2026-08-23T15:06:49Z (matches the 3.2.2.0 GitHub release, published 2026-08-23 ~15:08 UTC)
Previously running: 3.2.1.6 via ghcr.io/nilsteampassnet/teampass

Steps to reproduce

bash
docker pull teampass/teampass:3.2.2.0

Status: Image is up to date for teampass/teampass:3.2.2.0 (confirmed not a local cache artifact)

docker compose up -d
docker compose logs --tail 50

Observed

Container entrypoint banner on boot:

🔐 TeamPass Docker Container
Version: 3.2.1.6
...
✅ Database is up to date (3.2.1)

The web admin interface confirms the same: "Versão atual carregada 3.2.1.6", alongside its own separate GitHub-release checker correctly noting "New TeamPass version available: 3.2.2.0" — i.e., the app itself agrees it is running 3.2.1.6, not 3.2.2.0.

Expected

An image tagged 3.2.2.0 should contain the 3.2.2.0 codebase and trigger the corresponding DB schema migration on first boot, per the release notes (LAPR module, item revisions, Pace plugin removal, etc.).

Additional context

The 3.2.2.0 release notes state: "Release tags are now published verbatim, so teampass/teampass:3.2.2.0 can be pinned" — suggesting this was meant to be the first release with a working versioned tag. In practice, the tag exists but its content is stale.

We separately checked ghcr.io/nilsteampassnet/teampass: no 3.2.2.0 (or 3.2.1.7) semver tag is published there either — only sha-* commit tags and latest/master/develop, with latest still pointing at the 3.2.1.6 digest (sha256:eb93119dbbc38c8b01a0dda853fb47206454d593107d9ac449d0744295c0c564).

Happy to provide further logs/output if useful.

[nilsteampassnet]

Hi @btviana, thanks for the very detailed report — it made this quick to verify.

I inspected the exact image you pulled, straight from the registry (sha256:fde80481453c5c2aa5ee142aa35b62ebaff27f54572ad822da6ef6be20d9493c), and extracted the application layer. It does contain 3.2.2.0:

• app/config/include.php → TP_VERSION = '3.2.2', TP_VERSION_MINOR = '0'
• public/install/upgrade_run_3.2.2.php is present
• the LAPR module files are present
• labels: org.opencontainers.image.revision = 311e93e2… (the 3.2.2.0 tag commit),
  org.opencontainers.image.version = 3.2.2.0

GHCR is fine too: ghcr.io/nilsteampassnet/teampass:3.2.2.0 does exist, and its latest is sha256:f7c725d7…, which also carries 3.2.2 code, not the eb93119d… digest you saw.

What most likely happened: docker pull teampass/teampass:3.2.2.0 fetched an image your compose file does not reference (you were coming from ghcr.io/…), so docker compose up -d had nothing to recreate and docker compose logs replayed the previous boot banner. Could you check image: in your compose file and force a recreate?

docker compose config | grep image
docker compose up -d --force-recreate
docker compose exec teampass grep TP_VERSION app/config/include.php

That said, your report did surface two genuine bugs in the Docker upgrade path, which I'm tracking separately:

1. The container auto-upgrade applies the schema changes but never writes teampass_version back to teampass_misc (only the web wizard does). The migration is therefore replayed on every boot and the install/ directory is never removed.
2. Only the single upgrade script matching the image version is run, so intermediate migrations are skipped on a multi-version jump.

Thanks again, this was a useful report even though the headline turned out differently.