Install it after the gateway. The gateway owns the database schema; the panel only reads and writes
rows in it.It is not on the message path — a panel that is down costs you the ability to make changes, not the
ability to send.
Install
install does Node, service user, directories, source, npm ci, build, environment, systemd unit, and
then checks that it answers. It asks for what it needs first and changes nothing until you agree.
What it derives
Given the gateway’s configuration directory, the installer reads out the operational tokens and the read-only database connection rather than asking you to copy them by hand.The operator account is two environment variables
There is no user table.The two URLs that are easy to swap
They are different ports carrying different things and sharing no paths. Both failures look like an
outage and are not.
TLS in front
The panel speaks plain HTTP onPORT (3000 by default). Put nginx or similar in front of it, and set
AUTH_URL to the public origin — unset, a sign-out redirects to localhost.
NODE_ENV=production is set for the build as well as the run, because it decides whether the
session cookie is marked secure.
Customer sign-in needs mail
A customer signs in through a magic link. WithFIREFLO_SMTP_HOST or FIREFLO_SMTP_FROM unset, no
customer can sign in at all — the portal says the link cannot be sent rather than failing silently,
but nobody gets in.
See Portal access.
Upgrading
Under a virtualhost
--tenant NAME puts the panel at /srv/fireflo/NAME/panel as unit fireflo-NAME-panel, and the same
word names the same instance to the gateway installer. With --vhost PATH the root moves to
PATH/panel, with the gateway at PATH/gateway.
Every variable is at Control panel environment.