Upgrades and the changes they bring

A new release can change something people notice: a setting nobody set may now behave more strictly, or data may be rewritten in a way the release before cannot read. An upgrade never makes such a change for anybody who was not asked. The new release reads the store before it takes over, says what it changes and whom each change touches, and keeps the old behaviour for every organisation until that organisation decides.

The examples use the vsx shell function from the Quick start.

Before an upgrade

See what the channel offers and what staying where you are means:

versealx-server upgrade --channel https://downloads.example.org/versealx --check

It names the release offered, the last day the release you run is supported, and the security fixes you go without by staying. Staying on a release is allowed; this is what it costs.

See what the new release changes on this server, without changing anything. Run it with the new release’s binary:

vsx upgrade review --backup "snapshot 2026-10-06"

The review lists each change, the organisations it touches, and anything that stops the upgrade. A change that cannot be undone, such as data sealed in a new way, needs a backup or a volume snapshot taken after the last write, named with --backup. Without one the upgrade does not start.

Upgrading

Each way of running the server prepares the store with the new release before that release starts:

How the server runs	What to do
A package, under systemd	`versealx-server upgrade --channel <channel> --snapshot <directory>` with the service stopped. It takes the snapshot, prepares the store with the new binary and checks it with the new binary’s `doctor`, and puts the old binary back if either fails.
A container, under Compose	Stop the `server` service, point its `image:` at the new release, run `docker compose run --rm server upgrade prepare --backup <snapshot>`, then `docker compose up -d`.
Amazon ECS	Run the new image once as a task of the service’s task definition with the command `upgrade prepare --backup <snapshot>`, then deploy the new image.
Kubernetes, with the chart	Take a database snapshot, set `upgrade.backup` to its name, and run `helm upgrade`. A hook of the new image prepares the store first; if it refuses, Helm stops with nothing changed. Then replace the pods with `versealx-server cluster upgrade`.
A cluster	`versealx-server cluster upgrade` upgrades one node at a time. The first node prepares the store, and the others find it prepared. See Running the server.
A disaster-recovery standby	Upgrade the standby first, the way its kind is upgraded, so a failover never lands on an older release.
An air-gapped bundle	Unpack the new bundle and point `--channel` at its directory.

What each organisation sees

An organisation’s change is its own administrators’ to decide. On the console, Changes coming lists each change that touches the organisation: what it changes, whether it is waiting, kept or taken on, what keeping it means, and until when the old behaviour is supported. Take it on applies the new behaviour; Keep it as it was keeps the old one until its date.

vsx admin upgrade changes
vsx admin upgrade decide default:security.second_factor adopt

The Overview lists what waits for a decision, and the pane counts it beside Changes coming.

The server’s operator cannot decide an organisation’s change for it. An operator may ask, and the request waits for one of the organisation’s administrators to approve it, whatever the organisation’s approval settings say.

Who is told, and when

While a change waits, the organisation’s administrators are told:

when it is held, and again a week and a day before the old behaviour’s support ends;
by mail, through the upgrade-change alert, which reaches every administrator unless the organisation names whom;
in its audit log, which its webhooks hear as upgrade.change;
on the console’s Overview and beside Changes coming.

An organisation that chose to keep the old behaviour is still told a week and a day before its date.

When an organisation takes on a change that asks something of its people, each of them gets a message of their own saying what to do, and nothing about anybody else. For a required second sign-in step, everybody without one is asked to add one at their next sign-in.

The support date

The old behaviour of a change is supported for a year from the release that brought it, and never less than 30 days from the day your server was prepared for it. On that date it is withdrawn: the change applies to every organisation still keeping it, its administrators are told, and its people are told what to do.

The operator’s Upgrade page, under System, shows every change, how many organisations still wait, which ones, how many kept it and how many took it on. The installation’s own changes are decided there, or with:

vsx upgrade decide sealed-calendars adopt
vsx upgrade status