Update¶

Operations Center acts as the update hub for IncusOS servers. IncusOS servers contact Operations Center to look for newer software and download updates if available. This allows deployments to easily operate in an air gaped environment by only having one place to push new update files to.

Operations Center handles the central IncusOS update management. In this role, Operations Center keeps the relevant updates available locally.

Operations Center has a single source configured in the config file. If Operations Center does have internet access, it checks the registered update source on a recurring schedule (by default hourly) for new updates and downloads them to the local cache.

It is also possible to operate Operations Center in air gapped environments, where the updates are provided manually by the administrators.

Trigger an update¶

An update can be triggered for the whole server, for the operating system only or for individual applications:

operations-center provisioning server system update <server>
operations-center provisioning server system update <server> --os
operations-center provisioning server system update <server> --application incus

Without any flag, the operating system and every installed application are updated.

--os restricts the update to the operating system and leaves the installed applications on the version they are on, while --application updates the given applications only. The two flags can not be combined.

An update of the operating system is staged and applied with the next reboot of the server, while an application is updated right away, which restarts that application.

Since the update is performed by the server itself, a successful invocation only means the update has been triggered. Operations Center reports the server as updating until the server no longer reports any component in need of an update. With --os only the operating system decides that, so the server leaves updating while its applications may still need an update.

Cluster wide update¶

The same restrictions are available for the rolling update of a cluster, which updates the servers of the cluster one by one:

operations-center provisioning cluster update <cluster> [--reboot]
operations-center provisioning cluster update <cluster> --os [--reboot]
operations-center provisioning cluster update <cluster> --application incus

With --reboot, the update is followed by a rolling reboot of the servers, which applies the staged update of the operating system. Since an application is updated right away, --reboot can not be combined with --application.

An application given with --application has to be installed on at least one server of the cluster. Servers, which do not have it installed, are skipped. A restricted update is rejected, if none of the servers needs an update of the covered components.

The update phase of a restricted update is complete, as soon as none of the servers reports the covered components in need of an update. With --reboot, the rolling reboot follows. The cluster keeps reporting the servers, whose other components still need an update.

Filtering¶

The updates, which should be downloaded and be made available for the managed IncusOS instances, can be filtered based on various criteria.

See filtering for more information on the syntax of the filtering expression.

Update level filters¶

Update level filters are configured using the filter_expression config key in the Update settings.

They allow filtering of updates based on their metadata.

Property	Description	Example
`upstream_channels`	Upstream channels, the update is part of	`stable`, `testing`, `daily`
`origin`	Source the update originates from	`linuxcontainers.org`
`published_at`	Timestamp when the update has been published	`2025-11-21T22:30:02.515408725Z`
`severity`	Severity of the update	`none`, `low`, `medium`, `high`, `critical`
`uuid`	Unique identifier of the update	`123e4567-e89b-12d3-a456-426614174000`
`version`	Version of the update	`202511201340`

The following properties are available during filtering as well, but they are not really useful as filter criteria and are only listed here for completeness.

uuid: Unique identifier of the update
format: Version of the update index file format, currently 1.0
channels: Channels the update is part of, during retrieval of the update this is always the default channel
changelog: Content of the changelog
update_status: state from Operations Center point of view, if the update is ready or pending; when the filtering is applied, the updates are never ready
url: Source URL of the update

File level filters¶

File level filters are configured using the file_filter_expression config key in the Update settings.

They allow filtering of update files based on their metadata.

Property	Description	Example
`architecture`	Architecture the update file applies to	`x86_64`, `aarch64`
`component`	Component of the update file	`os`, `incus`, `incus-ceph`, `incus-linstor`, `operations-center`, `migration-manger`, `debug`
`filename`	Name of the update file	`x86_64/IncusOS_202511201340.efi.gz`
`sha256`	SHA256 checksum of the update file	`26705d5d610a8f450d92e073ac0f691197c16c8fbcbd0a3cf71e13fea93f54b2`
`size`	Size of the update file in bytes	`12345678`
`type`	Type of the update file	`image-raw`, `image-iso`, `image-manifest`, `changelog`, `update-efi`, `update-usr`, `update-usr-verity`, `update-usr-verity-signature`, `udpate-secure-boot`, `application`

Prepare manual updates¶

Manual updates can be provided to Operations Center as tar files. Each tar file is expected to contain a single update, and the content of the tar file is expected to match the file system tree of https://images.linuxcontainers.org/os/VERSION/, so at its root it needs the update.sjson file and then have the folder structure with the architectures and the files inside those.

It’s possible to skip files that are not needed, for example, architectures not used, can be left out of the tar file.