[izzipizzy]

What

The admin footer printed getenv('APP_VERSION') ?: 'v0.5.5' — and APP_VERSION is set nowhere in the repository, so the fallback always won and every deployment claimed a version invented in a template. The same fabricated string sat in the public layout, so the login page lied too.

This replaces it with a real build identity and an upstream update check.

Build identity

Baked at image build time, in two distinct kinds:

• release — stamped by CI from the tag it built. The release workflow now fails the build if the tag or revision cannot be resolved: a release image with no identity is a defect, not something to paper over at runtime.
• source — from git describe in a local build, displayed as a source build.

They are never mixed behind one variable, because the nearest reachable tag is not the newest tag in the repository. On the branch this was developed from, git describe returns v0.4.1-85-gb9d3407 while v0.6.1 is the latest release — comparing those would confidently report "behind" for a build that had diverged, not fallen behind. A source build therefore never claims to be current or behind.

There is deliberately no environment: entry for these keys in the prod compose files: a compose environment mapping overrides the image ENV even when it interpolates to an empty string, so ${APP_VERSION:-} would erase the identity of a correctly stamped release image on an ordinary up -d. Dev overrides live in the dev overlay, and cover the cron service too — it declares only env_file, inherits nothing from app, and is the container that runs the check.

The check

version:check, twice daily, reads GitHub's releases/latest into a typed single-row core.update_status.

• Redirects are disabled. PHP streams follow them by default and would forward the Authorization header to the target host.
• Every response field is validated, tag_name must parse as semver, and html_url is ignored — all URLs are built locally from a validated owner/repo slug against constant hosts. The operator picks the repository, never the host that receives the token.
• last_attempt_at and last_success_at are separate. One timestamp cannot mean both "when did we last try" and "how old is this answer", and conflating them is how a checker broken for months keeps asserting a fresh verdict.
• A failed attempt keeps the last good answer but exits non-zero, so core.cron_runs records the failure. Freshness ages out into a stale state instead of being hidden.
• Changing UPDATE_CHECK_REPO clears the etag, release data and last_success_at before the next request. Leaving that timestamp behind is a false-current bug: a repo change plus one failed request would otherwise let the footer assert a verdict for data it no longer has.

UI

Five states with a strict precedence order, so overlapping conditions cannot produce two answers. Only behind is linked — to the release page, plus a "how to update" link pinned to that same release so the steps are the ones that shipped with it. The version renders whenever the build is known; state only decides the chip.

Resolution never throws: the footer is decorative and must not be able to 500 an admin page.

Also

• README gains an "Updating an existing install" section for a human and for an AI agent, built around the traps this repo actually has (up -d without --build reuses the old image; make migrate on prod auto-merges the dev overlay).
• Author links (telegram, izzyypizzy.com) in both footers, in .public-left because .public-right is display:none under 760px and hidden links in a mobile-first index are worse than none.

Verification

Against the live API: v0.6.1 found, a second run took a 304, an invalid slug was rejected before any request was made. Full suite green, PHPStan level 6 clean on all new code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UwX8Ejy7NLT5Cjug2VTYXb