# Frontend / backend version mismatch

> The About panel highlights a version mismatch between the frontend and backend in amber.

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

## Confirm

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

```bash
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.

## Fix

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:

   ```bash
   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:

   ```bash
   curl -s http://localhost:5000/api/system/health | jq .version
   ```

Do not ship a build whose version reads `0.0.0-dev...` or ends in `-dirty`. The first
means no release was tagged for that build; the second means it carries uncommitted
local edits. Neither is reproducible — deploy a properly versioned release instead.

## 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

- [Release Notes](/release-notes/) — what shipped in each version.
- [Observability & Alerts](/operate/monitoring/) — runtime health alongside version.