Docker APP_VERSION:-latest pulls dev version

[MarkBeaven]

I followed the instructions here to build a docker Snipe-IT: https://github.com/grokability/snipe-it/blob/master/docker-compose.yml and it worked perfectly for months. This is the image part of the docker compose:

services:
  app:
    container_name: snipeit
    image: snipe/snipe-it:${APP_VERSION:-latest}

When I went to update to the latest image earlier this week (re-applying the docker compose), instead of pulling stable version 8.7.2, it pulled dev version "v8.8.0-pre - build 25083". Is this a misconfiguration of the "{APP_VERSION:-latest}" variable, or expected behavior?

I don't have an issue with our instance of Snipe-IT malfunctioning, but being a production instance, I would rather stick to stable releases.

Thanks in advance.

[wmorin]

That is how the tags are published right now, not a problem with your compose file. The Docker workflow builds on every push to master and tags that build as latest (docker-ubuntu.yml, type=raw,value=latest on the default branch). master currently has app_version => 'v8.8.0-pre' in config/version.php, so latest is a pre-release build.

I checked Docker Hub today: latest was pushed on Sep 26 from commit d5bf95c (the current master head) and has a different digest from v8.7.2. v8.7.2 and v8-latest share the same digest (sha256:18cc45da...) and were built from the v8.7.2 release commit.

For production, set the version in your .env (the compose file already reads it):

APP_VERSION=v8.7.2

Or use APP_VERSION=v8-latest if you want to follow the newest 8.x release without editing the file each time (the workflow is set up to rebuild that tag weekly for base image updates, so its digest can change even without a new release). Then docker compose pull && docker compose up -d. Going back from the pre build to 8.7.2 may not be clean if migrations from 8.8.0-pre already ran, so a DB backup first is a good idea.

Did the update run any migrations when it started?

[MarkBeaven]

So does APP_VERSION=v8-latest not actually pull v8.8.0? And will it continue to only pull 'release' rather than 'pre-release' versions? If that's the case, I'll probably be safer to wait for a release version greater than 8.8.0 and edit the .env then rather than risk the database. I am unsure if it ran any migrations Thanks for your response

…

On Mon, 28 Sept 2026, 6:55 pm Willy Morin, ***@***.***> wrote: That is how the tags are published right now, not a problem with your compose file. The Docker workflow builds on every push to master and tags that build as latest (docker-ubuntu.yml <https://github.com/grokability/snipe-it/blob/master/.github/workflows/docker-ubuntu.yml>, type=raw,value=latest on the default branch). master currently has app_version => 'v8.8.0-pre' in config/version.php, so latest is a pre-release build. I checked Docker Hub today: latest was pushed on Sep 26 from commit d5bf95c <d5bf95c> (the current master head) and has a different digest from v8.7.2. v8.7.2 and v8-latest share the same digest (sha256:18cc45da...) and were built from the v8.7.2 release commit. For production, set the version in your .env (the compose file already reads it): APP_VERSION=v8.7.2 Or use APP_VERSION=v8-latest if you want to follow the newest 8.x release without editing the file each time (the workflow is set up to rebuild that tag weekly for base image updates, so its digest can change even without a new release). Then docker compose pull && docker compose up -d. Going back from the pre build to 8.7.2 may not be clean if migrations from 8.8.0-pre already ran, so a DB backup first is a good idea. Did the update run any migrations when it started? — Reply to this email directly, view it on GitHub <#19720?email_source=notifications&email_token=AWAC3Z46BDN6SBB5IVI7MXL5RH4MNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGM2DMMRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18634620>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWAC3Z7Y7EQCVVNXH55QZ6D5RH4MNAVCNFSNUABHKJSXA33TNF2G64TZHMYTIMZUGY4TOOJ3IRUXGY3VONZWS33OHMYTAOJQGMZDIMNBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AWAC3Z2S67NLLRDDYDN76J35RH4MNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGM2DMMRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AWAC3Z5LUZ4ERNM3NF3P5GL5RH4MNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWGM2DMMRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[wmorin]

Right, there is no 8.8.0 release yet. The newest release is v8.7.2 (Aug 19), and 8.8.0-pre is just what master currently calls itself, which is what latest gets built from. So v8-latest pulls 8.7.2 today; on Docker Hub v8-latest and v8.7.2 have the same digest.

v8-latest only moves when a version tag is pushed. It comes from type=semver,pattern=v{{major}}-latest in docker-ubuntu.yml, and for pre-release tags like v8.8.0-rc1, docker/metadata-action skips the {{major}} pattern and only tags the full version, so v8-latest isn't touched. So it should stay on stable releases and move to 8.8.0 once that is actually released. One correction to my earlier reply: the weekly rebuild of v8-latest is currently failing (no tag gets generated on scheduled runs), so that tag hasn't changed since Aug 19.

Waiting is fine, but there's no need to wait for something newer than 8.8.0. With APP_VERSION=v8-latest, the next docker compose pull after 8.8.0 ships gets it.

To see whether the pre build ran migrations, check the app logs from that first start (docker compose logs app | grep -i migrat). If it did, going back to 8.7.2 on that database could cause problems. A backup from before the update is your safest fallback, and either way take one now before switching.

[MarkBeaven]

In case you are able ... can I request that the suggested docker-compose settings on https://github.com/grokability/snipe-it/blob/master/docker-compose.yml are updated to have APP_VERSION=v8-latest to prevent others making the same mistake as me? I had assumed (in error) that the dev settings would be on https://github.com/grokability/snipe-it/blob/master/dev.docker-compose.yml, and that the other was for prod.