Skip to main content
PostgreSQL is optional. Leave FIREFLO_DB_URL unset and FireFlo runs on files, with call records written to data/cdr/.

​
What it buys

The panel’s read-only half works without one; it just has nothing to change.

​
Creating it

Install the server first if the host has none — setup.sh does that and deliberately stops there, because a script that mints your database password is a script that has written a credential to disk on your behalf. The role and the database are yours to create:

​
Applying the schema

FIREFLO_DB_MIGRATE=true migrates on startup, which is convenient for a first run and wrong for an upgrade — it ties a schema change to a process start and gives you no way to see what would be applied first.
info and validate do not need the write-enabling flag. Reading the schema version changes nothing, and needing a flag before you may look would be a trap mid-incident.
Migrations are forward-only. There are no undo scripts, so rolling back a schema change means restoring a backup. Take one before migrating a database you care about.

​
db migrate alone is not enough

This is the one that catches people, and the failure is loud rather than graceful. db migrate creates the tables and leaves every one of them empty. With no routing table the gateway does not start at all:
That names an internal structure rather than the missing row, so it reads like a bug. It is not — it means the database is empty. fireflo bootstrap writes the least that will start.

​
The consolidated baseline

The schema is one file, V1.19.0__baseline.sql, generated rather than hand-merged: the originals were applied to a scratch database, dumped with pg_dump --schema-only, and the dump verified by applying it to a second database and diffing the two. Later changes carry on at V1.20.0. It is numbered at the highest version it replaces, not the lowest, deliberately. A deployment that stopped part-way would treat a lower-numbered baseline as already applied and migrate to a no-op, silently missing whatever came after. At 1.19.0 it instead tries to apply and fails on the first table that already exists — recoverable, where the silent version corrupts by omission.

​
Upgrading a deployment that applied the originals

Flyway’s history still names them all, so db validate fails until the record is realigned: one changed checksum, the rest no longer resolvable. One command fixes it, and it rewrites the history rather than the schema:
Finish applying any pending migration before running repair. Repair on a part-migrated database makes it look complete when it is not.

​
Upgrading, in order

1

Stop the gateway

2

Look, then apply

3

Start the new version

db migrate runs on both packagings. A native install migrates itself — the command is inside the gateway executable, so no JDK and no second artefact are needed. Keys and tables are at Database configuration.