Safe updates and configuration

bipanel never installs a release whose signature and SHA-256 digest it cannot verify, backs up the panel database before updating and rolls back automatically if the new version does not start. Web server, DNS, FTP, mail filter and SSH configuration is tested with the service’s own checker, and a change that fails is not applied or is reverted.

#How release packages are verified

Every bipanel release is published on the update server with a signed release manifest. The manifest contains the version number, channel, release notes, package URL, and the package's SHA-256 digest and size. The panel verifies an update in this order:

The manifest's Ed25519 signature is checked against the public key embedded in the panel. If it does not match, the manifest is ignored and an error is shown on the Updates screen.
While the package downloads, its SHA-256 digest is computed; size and digest are compared with the manifest.
The package also carries its own Ed25519 signature, which covers the version number together with the package's SHA-256 digest. Installation does not start until this signature is verified too.

If any step fails, the update stops and the installed version is left untouched. The trusted keys ship inside the panel package; on a production installation they cannot be replaced through an environment variable.

#Verification on first install

The one-line install command on the download page fetches the latest release info for the chosen channel, downloads the package and checks its SHA-256 digest with sha256sum -c. On a mismatch the install stops with a "corrupt or tampered with" error.

#Third-party components

Components the install scripts download from outside the distribution's repositories (for example webmail, backup and remote desktop tools, GeoIP data) are pinned to specific versions, and for most of them the SHA-256 digest of the downloaded file is checked as well.

#Software bill of materials (SBOM)

A software bill of materials in CycloneDX format is generated with every release and uploaded to the update server. It lists the runtime npm dependencies of the server and the interface with their exact versions, plus the pinned third-party components. The components of published releases are tracked against known vulnerabilities using this list; see vulnerability monitoring.

#While an update is applied

On a server installation the verified package is installed by a systemd unit that runs independently of the panel service:

Step	What happens
Backup	If Back up the panel database before updating is on (the default), a consistent copy of the database is taken; the last 5 backups are kept
Unpack and check	The package is unpacked; required files and the version number inside it are checked
Dependencies	Production dependencies are installed; if this fails, the installed version is unchanged
Switch	The old installation is kept as `/opt/bipanel.prev` and the new one takes its place
Health check	The service restarts; the new version must answer with its own version number within 90 seconds
Rollback	If it does not, the previous installation and the database backup are restored and the old version is started

Sites, email and databases keep running during the update; only the panel restarts. The locations of rollback and log files are listed on the panel updates page.

Further safeguards:

No downgrades. Changing the channel or pinning a version series never offers an older release.
If a release requires a minimum starting version, the panel does not let you skip ahead; you are asked to install the intermediate release first.
Only one update can run at a time. A release whose automatic install failed is not retried automatically; you can still install it by hand.

#Container installations

On Docker and Railway the file system comes from the image. The panel still verifies the signed manifest; then on Railway, if RAILWAY_API_TOKEN is set, it triggers a redeploy with the new image, while on Docker you pull the new image and recreate the container yourself. The database backup option is only available on a server installation.

#Channels for a cautious rollout

The channel decides how early you receive changes: lts and stable are for production servers, release gets new versions on release day, and current and edge are for test servers. A server receives releases published to its own channel and to every more conservative channel. You can limit automatic installs per channel (for example patch releases only) and to an hour window, and pin a version series.

If you run several servers, keeping one test server on current and production servers on stable lets you see new releases before they reach production. All channels and their support periods are on the panel updates page; release notes are published on the changelog page.

#Package integrity (Pro)

In the Pro edition the panel regularly compares the digest of the running server package with the digest approved by the update server. If the package has been modified by hand, administrators get a "Panel package changed" notification, the state is reported at the next license check and Pro updates are paused. The flag clears once the package is reinstalled and the digest matches again.

#Configuration changes: test first, then apply

The panel tests server configuration with the service's own checker. If the check fails, the new configuration is not applied or the written files are restored, so the service is never reloaded with a broken configuration.

Area	Check	On failure
Apache	`apachectl configtest`	Written files are restored
Nginx front end	`nginx -t`	The change is rolled back
DNS server	`named-checkconf`	The last known-good copy is restored
FTP server (ProFTPD)	`proftpd -t`	The previous configuration is kept
Mail filter (Rspamd)	Lua compile check and `rspamadm configtest`	The change is rolled back
SSH (Security Advisor)	`sshd -t`	All files are restored
Fail2Ban	`fail2ban-client -t`	The change is rolled back

#Switching the web server mode

When the operating mode is changed on the Web Server page, sites are probed before and after the switch and the results compared. If the new engine does not start or the health check fails, the switch rolls back to the previous mode automatically. Details are on the web server and caching page.

#Security Advisor fixes

Security Advisor shows a preview before applying a one-click fix and records a rollback plan for every fix. Files and settings that someone else changed after the fix are left alone during a revert. If an SSH fix locks you out of the panel, you can revert the last fix from the server console:

$ bipanel advisor fixes
$ bipanel advisor revert --last

See security tools.

#Backups before risky operations

Disk Manager: every operation is first shown as a step-by-step plan and does not start until you type the confirmation text the plan asks for. /etc/fstab is backed up before it is changed; if the mount step fails, the added line is removed again. Other steps are not rolled back automatically because of the risk of data loss; completed and remaining steps are listed in the log. Taking a snapshot in your hypervisor before partition table changes is recommended. See Disk Manager.
Terminating an account (Pro): a full backup of the deleted account goes to the trash and is kept for 30 days by default. See deleted accounts.
Panel updates: the panel database is backed up as described above.

#Operating system security updates

On a server installation the panel uses the distribution's own tools to install only security updates in the hour window you choose, then checks critical services. The feature is on by default and available in both editions; its settings are covered on the automatic security updates page.