Updating

The native launcher checks for updates overnight by default. You can disable that check or request an update on demand. Docker updates follow the deployment’s container-update process instead.

Native updates require a published archive and checksum matching the installed platform. Bundled installer production is currently disabled; routine releases do not promise a new native archive. When enabled, the configured bundle target is Linux x64. Check the download centre and the release notes; no update can be downloaded when no matching asset exists.

Overnight, by default

Every night at 01:00 in the machine’s own local time, Plugboard checks whether a newer version exists, downloads it, verifies it against its published checksum, and stages it.

The swap happens on the next restart. Replacing files a running process holds open is how updaters corrupt themselves, particularly on Windows.

Nothing is applied during the day. An update restarts the service, and doing that while the desk is in use is the surprise the schedule exists to avoid.

An archive whose checksum does not match is never unpacked. This runs unattended with privileges, so “probably the right file” is not good enough.

On demand

The status panel at localhost:9090 has Check for update and Install update.

From a terminal, in the install directory:

plugboard update --check     # is there one? change nothing
plugboard update             # get it now

Changing the schedule

In the configuration file in the install directory:

AUTO_UPDATE=off           # never update on its own
AUTO_UPDATE_HOUR=3        # a different local hour, 0-23
AUTO_UPDATE_RESTART=off   # stage it, but apply at your next restart

Before a version that changes the database

Versions that change the database are marked as such, and you are told about them in the release email.

Two things to do first:

Take a backup and check it completed. See backups and restore.
Confirm SECRETS_MASTER_KEY is backed up somewhere other than the server.

The native updater attempts a SQL dump into backups/ in the install directory. This is best effort: a failure is logged and does not necessarily stop the update. Confirm a separate backup completed and can be restored before proceeding. SQL dumps need protection as sensitive data.

The 0.12.0-rc.3 candidate also preserves native application archives under server/backups. Docker candidate updates use a dedicated archive volume and migrate the default path before recreating the API container. Custom locations must be persistent and writable. See archive storage and the candidate status.

Rolling back

The native updater keeps the preceding program version in .previous-version. Recovery is an operator procedure; the status panel does not provide automatic rollback.

Database migrations are forward-only. Replacing program files alone may be incompatible with the migrated schema. Recover the matching application version, database backup and encryption keys together in a maintenance window, and verify the restored deployment before reopening access.

If you are unsure, ask before rolling back rather than after.

What version am I on

Admin, Licence shows it, along with the build date, the channel, and whether an update is available.

The status panel shows the same, and works when the service does not.

Release channels

RELEASE_CHANNEL is stable or beta. Beta gets new versions earlier, before they are recommended to everyone.

The channel only changes which version you are offered. It never changes whether an update is applied, which is governed by the settings above.

Verifying a release yourself

Every release publishes a checksum beside each file, and the updater checks it for you. If your policy requires you to verify by hand, compare the file against the SHA256SUMS published with it:

sha256sum -c SHA256SUMS --ignore-missing

If you are on managed hosting

We update your deployment for you. You are told before anything that changes the database, and you can ask to be held back. See updates.