Skip to main content

​
Before you start

Read the release notes. update never touches the configuration directory, which is what makes it safe — and means a new configuration key introduced by a release is not added to your file.
Take a database backup. Migrations are forward-only; there are no undo scripts.

​
The order

1

Stop the gateway

SIGTERM, not SIGKILL. A clean shutdown returns unspent reserved prepaid credit; a kill -9 strands it until fireflo credit release runs.
2

Apply migrations deliberately

Rather than letting FIREFLO_DB_MIGRATE=true do it on startup, which ties a schema change to a process start and shows you nothing first.
3

Update the artefact

Replaces /opt/fireflo and nothing else.
4

Update the panel

5

Verify

version asks the gateway rather than the files. An artefact that was built but never restarted into is the whole reason to ask — the jar on disk and the process serving traffic are different questions.

​
Both components move together

The panel’s version repeats the gateway release it was built against in its first three numbers. The panel checks the pair at runtime and reports a mismatch on screen. A mismatched pair is not necessarily broken — but it means the panel is describing a gateway it was not built against, and a feature added in the newer one may be missing or mis-rendered.

​
What an update replaces

​
Rolling back

Restores the previous artefact.
Rollback restores the artefact, not the schema. If the release you are backing out of applied a migration, the older artefact runs against the newer schema. That usually works — the schema is additive — but it is not guaranteed, and it is why the backup matters.

​
Reading verify

Exit 4 after an upgrade usually means a configuration domain went empty — worth checking before concluding the upgrade broke something.