Updates and maintenance windows
Velrix updates are signed releases. Each one carries new versions of the platform’s modules, and sometimes a new operating system image. You decide where they come from, whether they install by hand or on their own, in which windows, and how much warning everyone gets.
Everything here is in the Updates app in the Manager. You need operator rights for the platform.
Releases and their names
A release is named by year, month and patch: 2026.10.1.
- A patch release keeps the year and month (
2026.10.1→2026.10.2). It fixes things. - A feature release starts a new month (
2026.10.2→2026.11.0). It brings new things. - Either can be marked Security: it fixes a security problem.
Every release is checked against our signature before anything installs. A release that does not verify is refused.
Where updates come from
Your installation is either online or offline, and updates follow it. You see which at the top of every Updates tab, with Change in Manager, which opens Manager › Connectivity.
- Online: updates come from Velrix over the installation’s link. Velrix checks for new releases every day, and whenever you ask.
- Offline: updates come only on a USB stick, and installing one needs your installation’s update key. Offline, Velrix makes no outbound call for updates at all.
The update policy
Open Updates › Settings. Every change is recorded in the audit trail, with who made it.
How updates install
| Mode | What happens |
|---|---|
| Manual (the default) | You are told about a new release. Nothing installs until a person chooses Install now. |
| Download | Each release is fetched and staged on every server once its waiting time is over, and you are told. A person still starts it. |
| Automatic | Each release installs on its own, in the next maintenance window after its waiting time. |
Automatic and download apply to online releases only. A release on a USB stick always needs a person, because someone has to touch the update key. If an online installation goes offline with automatic chosen, the policy stays stored and acts as manual until it is online again.
Waiting times
| Setting | Default | Meaning |
|---|---|---|
| Patch releases wait | 0 days | Days after we signed a patch release before it may install |
| Security patches skip the wait | Yes | A security patch may install at once |
| Feature releases wait | 14 days | Days before a feature release may install |
| Security feature releases skip the wait | No | |
| Deadline | Off | When set, a release still waiting this many days after it may install goes in at the next window, even in manual or download mode |
Maintenance windows
A window is a set of days and a time range, in the policy’s time zone:
sun 02:00-05:00
sat,sun 02:00-05:00
mon-fri 22:00-01:00
daily 03:00-04:00
Add as many lines as you need. A window may run over midnight. With no window, updates may start at any time.
The time zone defaults to Europe/Stockholm. On the night the clocks go forward, a window that starts in the skipped hour starts when the clocks have jumped; on the night they go back, it starts at the first of the two.
Warnings
| Setting | Default | Meaning |
|---|---|---|
| Least warning | 15 minutes | An update never starts sooner than this after it was planned |
| Reminders | 24 h, 1 h, 15 min, 5 min | Notices before the start |
| Who is warned | Operators | Or Everyone: every signed-in person also sees a maintenance banner |
| Postpone choices | 1 h, 4 h, 24 h | What Postpone offers |
| Postpones allowed | 3, at most 72 hours in all |
Reminders and postpone choices are lists of durations, up to 12 each: a number and a unit, s, m, h or d (90s, 15m, 1h, 2d). Type one and press Enter, or paste several at once.
Operators get a notice when an update is planned, with a countdown to the start, and the reminders as it comes closer. With Everyone, each signed-in person sees a banner such as Maintenance planned at 02:00: your windows may reconnect for a moment, with the same countdown, and Under way while it runs.
Pausing
Pause stops all updates, deadlines included, for 1 to 35 days. The pause ends on its own, or when you choose Resume.
When an update is planned
Updates › Available shows the release, its badges (patch or feature, Security), and when it will install, such as Installs 2026-10-04 02:00 (Europe/Stockholm), with a meter counting down. From there:
- Install now starts it at once, after you confirm.
- Postpone moves it by one of the choices left. It then starts in the first window after the new time.
What happens during an update
- Velrix asks again whether the release is still offered. A release we have withdrawn is refused.
- It stages the release on every server.
- It installs it server by server. Every service restarts once: storage one copy at a time, so your data stays reachable, and the edge, which your people connect through, last.
- After each step it checks the platform’s health. If the new release fails, the previous release is put back on its own, and you are told that it was rolled back.
You get a notice when it is done, rolled back, or failed. Updates › History keeps every attempt, with its result and who started or approved it.
Restarting servers for a new operating system
Some releases include a new operating system image. Each server takes it at its next restart, and keeps its previous image to go back to. On Settings, choose how servers restart for it:
| Choice | What happens |
|---|---|
| Manual (the default) | You restart each server yourself, from the update’s page. |
| Rolling | Velrix restarts one server at a time, inside the restart windows (by default sun 03:00-05:00), and waits for each to come back before the next. |
| Rolling when safe | The same, but only servers with no workloads running are restarted. The others wait. |
A server that does not go down within 10 minutes, or does not come back within 30, stops the rolling restart, and you are told.
Installing from a USB stick
An offline installation, or any installation whose link is down, installs releases from a stick.
Enrol the update key, once
The update key is a hardware security key, such as a YubiKey 5 or a Nitrokey 3, plugged into one of your servers. Each installation has exactly one.
- Open Updates › Update key and choose Enroll.
- Enter the key’s PIN. A key still on its factory PIN is refused: choose a new one.
- Velrix makes a key pair on the device itself. The private half can never leave it. Velrix checks that the device is genuine from its maker’s attestation, and records its model, serial and firmware.
- Velrix also replaces the device’s management key with a random one kept behind the PIN, so nobody holding the factory management key can replace your key, and blocks a PUK still on its factory value.
- Touch the key when it blinks. You have 30 seconds.
Rotate the key if it is ever lost or exposed: the old one is refused at once. Revoke stops offline updates until a new key is enrolled; online updates carry on.
Install
- Get the release from us, on a stick labelled
VELRIX-UPDATEor as files to put on one. - Plug it into one of your servers. Velrix finds it, and operators get a notice and a banner with Review. The stick’s name only helps you recognise it: Velrix trusts our signature and the digests in it, never the name.
- Review opens the release: what changes, module by module, and where it came from.
- Choose Start update, enter the update key’s PIN, and touch the key when asked. The page counts down the time left to touch it.
- Velrix copies the release from the stick to every other server, checks each copy, then installs server by server as above.
When an update needs the realm key
A release can add a module to your installation, or change what a module may do. Those modules need new identities, and only your realm key signs identities. The update then stops before it changes anything, and Manager › Realm key says Update … waits for the realm key, with the modules it needs.
- Take a realm key stick from the safe and plug it into the first server. No USB port, as on a VPS? Use the encrypted file the installer let you download.
- In Manager › Realm key, choose Sign what an update needs. Add the realm key file if there is no stick, type the passphrase, and choose Sign with the realm key.
- The server opens the key in memory only, signs just the modules the update named, and forgets it. The update goes on by itself from where it stopped.
At a server’s console
Releases can also come as a folder of files, signed by us, that you copy to a server and apply there. This is also the way in when the web client can’t be reached: velrix console on the server shows the releases staged there.
velrix release os <folder> # as root, when the release has a new operating system; then restart
velrix release verify <folder> # as velrix: checks our signature and lists what changes
velrix release apply <folder> # installs it on this server
velrix release rollback # puts the previous release back by hand
apply checks the platform’s health as it goes and rolls back on its own when the new release fails. If the release needs the realm key, apply stops and says so; sign as above, or at the console as root with the stick in:
/usr/libexec/velrix/issuer release a # with the realm key stick
/usr/libexec/velrix/issuer release a --key /run/realmkey.age # with the file, copied to /run
Delete the copied file afterwards. See also Running the realm.