Frontend / backend version mismatch
Symptom
Section titled “Symptom”In Settings → About, the frontend version and the backend version are shown side by side and the row is highlighted in amber because they differ, for example:
- Frontend
v1.5.0vs backendv1.5.0-1-gabc1234, or - Frontend
v1.5.0vs backendv1.4.0.
The panel highlights the mismatch on purpose — it is the built-in drift detector. The two versions are expected to match on a correctly deployed box.
Confirm
Section titled “Confirm”Read the backend’s reported version directly and compare it to what the About panel shows for the frontend:
curl -s http://localhost:5000/api/system/health | jq '{version, commit, buildTime}'There are two common causes:
- A stale browser tab. The frontend bundle is baked at build time, so an old tab keeps showing the version it was loaded with even after a redeploy.
- One container redeployed without the other. A new backend image was deployed but the frontend image (or vice-versa) was not rebuilt — so they genuinely run different versions.
A version string containing extra commits after the tag (...-1-gabc1234) means that container was built from a commit past the release tag — it is ahead of the clean tagged build.
-
First, rule out a stale tab — it is the cheapest cause. Hard-refresh the browser (reload ignoring cache). If frontend and backend now match, you are done; nothing was actually wrong with the deployment.
-
If they still differ, redeploy so both images are the same version. Rebuild and bring the stack up together so frontend and backend are built from the same release:
Terminal window docker compose -f docker-compose.release.yml up -d -
Verify they match. Reload Settings → About — the amber highlight should clear. Confirm the backend version too:
Terminal window curl -s http://localhost:5000/api/system/health | jq .version
Prevent
Section titled “Prevent”- Deploy frontend and backend together. Both images carry a version baked in at build time; deploying them as a matched set from one release keeps the About panel green.
- Hard-refresh after every deploy. Browser tabs hold the old bundle until reloaded. A quick hard refresh after each deployment avoids false drift reports.
- Use the About panel as a post-deploy check. Treat it as the final acceptance step — if it is amber, the deployment is not finished.
Related
Section titled “Related”- Release Notes — what shipped in each version.
- Observability & Alerts — runtime health alongside version.