Updates and upgrades#

An OSM server is Debian 13 with OSM on top. One button, Install all in Settings > Updates and Recovery, updates all of it: the system, OSM, and the Debian packages of the apps (File Protocols, Containers, Virtual Machines and the other system apps).

Where updates come from#

OSM's update service, and nothing else. Every OSM server takes every update from OSM's update service (updates.osm-os.com): Debian's packages and OSM's, tested together as a release and signed by OSM. Never from Debian's archive directly, and never from anywhere else. The server checks everything before it uses it: the lists must carry OSM's signatures, Debian's indexes must carry Debian's own, and every package must be exactly the one the release names. A file that fails a check is refused, and the server keeps installing from the last release that passed. Settings > Updates and Recovery > OSM's update service shows the release in use, when it was checked and any problem; the administrators are told when the service cannot be reached for three days, or when its newest list has run out. The next Debian release comes the same way, once OSM has been tested on it. The App Catalog comes from the service too: each app at a version OSM tested, its images pinned to exactly one build, downloaded from the app's publisher (Apps).

• Channels. Stable (the default) gets a release once it has been tried; Beta gets new releases first, for testing. Choose in OSM's update service > Channel. Going back from Beta to Stable keeps what the server has: it waits until Stable has a newer release, and says so.
• Gradual rollout. A new release reaches servers in steps (some at once, more after a few days). The section shows how far it has come and where this server is in line.
• Withdrawn releases. If OSM stops a release because of a problem, servers that have not taken it never do; a server that took it keeps what it installed, installs nothing more from it, and gets the fix with the next release.
• Release notes, advisories, support. The section shows what is new in the release (with a link to its page on osm-os.com), the security advisories that concern this server, and until when this version of OSM gets fixes; the administrators are told about advisories and, from 90 days before, about the end of support.

New versions of OSM come the same way, in a release: every server with an older OSM gets the new one, by itself or when you install it, as its settings say. Any older OSM goes straight to the newest; nothing has to be installed in between.

A server needs to reach the update service (https://updates.osm-os.com) to update, or an offline update (A server without internet). While the service cannot be reached, the server keeps installing from the last release it accepted, and tells the administrators after three days.

A server without internet#

A server that is kept off the internet updates from an offline update: one file that holds a release of OSM's update service and the App Catalog, signed by OSM like everything the service sends.

1. Settings > Updates and Recovery > Update from a file says which offline update the server needs: its Debian release and its architecture (for example osm-offline-2026.10.2-amd64.tar).
2. On a computer with internet, download it from the download page on osm-os.com, and copy it to a USB drive.
3. Plug the USB drive into the server. Update from a file lists the offline updates it finds on the drive: click Check... next to one. (A file elsewhere: A file on this server... and its path. Or Upload an offline update... from this browser.)
4. OSM checks the file as it checks updates from the network: OSM's signature, Debian's, and every file in it. A file that fails a check is refused, with the reason, and nothing changes.
5. The check shows what the file brings: the release and its version of OSM, every package newer than what is installed, the App Catalog's version, the security advisories it fixes, and until when the file is valid. Install installs it like Install all: a restore point first, and the watch afterwards (What keeps an update safe).

An offline update is valid for a year after it was made. It never takes a server back: one older than the release the server has is refused, and so is one of another channel than the server follows (a Beta file on a Stable server: choose Beta first). For 90 days after an offline update, the server does not warn that the update service cannot be reached; when the offline update runs out, it says so. Apps whose images must be downloaded install or update only where their publisher can be reached. When the server reaches the internet again, it goes on from the release it took.

Automatic updates#

OSM installs every update itself, with all the steps that keep an update safe (below).

What updates, and how lists the parts of the server: OSM, the kernel, boot loader and firmware, the system apps (File Protocols, Containers, Virtual Machines...), extra packages (what OSM installs when a feature first needs it), the Debian base system, the apps and the App Catalog. Each shows its version and its updates; Install installs one part's updates now. For each part you choose how its updates install:

• By itself, in the maintenance window: installed automatically.
• Waits, and I am told (the default): listed here, and the administrators are told when new updates come (the bell, and email and push as Notifications says).
• Waits: I look myself: listed here only.

Automatic updates has the rest:

• Install security updates by themselves (on by default): security fixes install in the maintenance window whatever a part's choice; a release OSM marks critical installs its security fixes at once.
• Maintenance window: when automatic updates start, once a day (03:00 for two hours by default): the packages first, then the apps. A server that was off during its windows for two days installs the waiting security fixes as soon as it is on. The section shows when the window comes next and how its last run went.
• Restart when an update needs it, at the restart time (a new kernel needs a restart): the server restarts by itself then, once nothing is running. Otherwise you are told, and Restart now is at the top of the page.

Available updates lists what is waiting, with each package's part, the security updates marked, each package's changelog and the vulnerabilities (CVEs) it fixes.

Update history lists every update OSM installed: when, what changed (each package by part, each app, from which version to which), whether it was automatic, critical or started by hand, and how it ended: installed, undone by itself (the watch below went back), or failed. Click a run to see each package.

What keeps an update safe#

Every update goes through these steps: automatic ones and those you start, a part's or all of them, and critical ones.

1. A restore point first. It records the exact version of every installed package and a copy of the system's settings, and keeps the packages about to be replaced, so the server can go back without the internet.
2. A watch afterwards. For 15 minutes OSM watches the services that ran before the update. If one stops or keeps restarting, OSM puts the packages of the restore point back by itself and tells you why.
3. A guard outside OSM. If OSM itself does not answer 10 minutes after updating itself, a small service that does not depend on OSM puts the previous version back.
4. New kernels on trial (UEFI servers). A new kernel becomes the default only once it has started the server with its network. One that does not is set aside, and the previous one starts. A server that starts with BIOS uses a new kernel at once, as Debian does.

You can also go back by hand, in Restore points: Roll back... returns the packages (and, unless you untick it, OSM's own settings) to how they were. Volumes, shared folders, files, accounts and the apps' data are never touched. A restart afterwards makes every service use the restored versions. Make one now makes a restore point before a change of your own.

Never older#

OSM remembers the newest version of everything it installed: each package, each app, the release and the App Catalog of the update service. Nothing older comes back, even when it is signed: not an old list from the update service, not a copy of an old release. A release with a problem is fixed by a newer one. The one way back is the automatic undo above, right after an update that broke something: it returns to the versions that worked a moment before. Roll back... brings back OSM's settings and removes packages added since the restore point, but leaves packages at the newer versions OSM installed (the restore point says which).

When a release waits#

A new release reaches servers a few at a time. When too many of the first servers could not keep it (an update that OSM had to undo, or that failed), OSM's update service can make the others wait: what installs by itself from that release (in the maintenance window, a critical one too) waits for at most two days, while OSM looks at what happened. Then it installs as usual, unless OSM stopped the release meanwhile. OSM's update service says when a release waits and until when, and the administrators are told once. You can still install it yourself at any time. The same goes for an app's new version: the app's automatic update to it waits.

This is all a wait can do: it never installs, removes or chooses anything, and every server ends it by itself after two days at the most.

When OSM withdraws a release (a problem that must not reach more servers), a server that took it keeps what it installed and installs nothing more from it, by itself or by hand (Install all waits), until the release that fixes it comes; programs installed on demand (the remote desktop's, for example) wait too. OSM's update service says so.

Reporting how updates go#

Report how updates go (in OSM's update service; OSM Setup asks too) is off unless you turn it on. When it is on, the server sends OSM a short report after each update, once it is clear how the update went:

• which release it installed (or which app of the App Catalog, and its new version);
• the Debian version, the processor type (amd64 or arm64) and OSM's version;
• which parts of the server changed (OSM, the kernel, the system apps, extra packages, the Debian base system);
• how it ended: installed, undone by itself, or failed, and at which step (the download, the installation, the watch after it...).

Nothing else: no name, no address, no account, no file or package name, no error text, nothing that tells one server from another. OSM does not keep the address the report came from. These reports are what lets OSM make the other servers wait when a release goes wrong. Turned off, the server sends nothing more.

Changing packages yourself#

OSM manages the packages of the server. If you run apt or dpkg yourself (on the console, over SSH or in the web Terminal) to install, update or remove packages, OSM first shows a warning and asks whether to continue: doing so is not supported, the system may become unstable or buggy, and OSM's next update may undo your change or conflict with it. Only y goes on (j in German, o in French); anything else, or no answer within two minutes, stops before anything changes. A script without a terminal is not asked: it sees the warning and goes on.

Whatever changes this way is recorded. Settings > Updates and Recovery shows Changed outside OSM: when, who, the command and each package before and after, and a notification tells the Administrators. I understand closes the notification; the record stays, for you and for support. The same section lists apt sources that OSM did not add.

Apps#

Container apps update from their publishers' images: in the maintenance window if the apps' part (or the app's own setting) says so, or with Update on the app's page. OSM first keeps a copy of the app's own data, when it is 8 GB or less and the volume has room for it (on Btrfs the copy is instant). If the new version does not start or its page does not answer, the old version comes back, with its data as it was if the copy was made, and you are told.

Every app of the App Catalog has a version, and each of its images is pinned to exactly one build: the App Catalog shows the version an app has, its update and what is new in it. An app updates only to the version the App Catalog names, never to one OSM withdrew, and never to an older one than it had (its data may not work with an older version). An app on a channel that is behind (going back from beta to stable) keeps its version until the channel has a newer one. Changing an app's settings never changes its version. A new version that fixes a security problem installs in the maintenance window even when the app does not update by itself, while security updates install by themselves.

Debian releases#

Debian publishes a new stable release about every two years, and supports each one with security updates for about three years, then about two more through Debian LTS. Debian 13 came out in August 2025: its security support runs to about 2028, and LTS to about 2030. OSM tells you in advance when the end of support comes near.

The next Debian release comes through OSM's update service, once OSM has been tested on it: there is nothing to do. Settings > Updates and Recovery shows the support dates of the release the server runs.

Going back from a new Debian release is a restore from a backup, not a rollback. Nobody has to upgrade on the release day: the previous release keeps its security updates for about a year.