Skip to content

Frontend / backend version mismatch

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.0 vs backend v1.5.0-1-gabc1234, or
  • Frontend v1.5.0 vs backend v1.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.

Read the backend’s reported version directly and compare it to what the About panel shows for the frontend:

Terminal window
curl -s http://localhost:5000/api/system/health | jq '{version, commit, buildTime}'

There are two common causes:

  1. 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.
  2. 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.

  1. 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.

  2. 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
  3. 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
  • 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.