Incusos It is an immutable system image designed exclusively to run Incus with the highest level of security and reliability. Based on Debian 13 and leveraging modern systemd tools, it offers an API-centric management experience designed for data centers and large-scale deployments. In practice, It offers secure boot, full disk encryption, and atomic updates. so that your infrastructure is easy to maintain and extremely consistent.
If you want to simplify support and reduce variations between servers, this project is a perfect fit for you: All machines run exactly the same software, bit by bit.This eliminates configuration deviations and makes scaling or reprovisioning quick and easy. Plus, you won't have to deal with local shells: the system is governed by authenticated APIs, period.
What is IncusOS and why does it matter?
IncusOS is an immutable operating system whose sole purpose is to run Incus securely and reproducibly. It is based on Minimalist Debian 13It incorporates Zabbly builds of the Linux kernel, ZFS, and Incus itself, and makes extensive use of systemd tools to build, install applications, and apply updates. The philosophy is clear: the more predictable the foundation, better for operational reliability.
The project is built using mkosi to generate the images, sysext to install applications on the immutable base, and sysupdate as the update engine. In combination, these components allow the system to apply changes atomically, and if something goes wrong, go back without drama thanks to an A/B partitioning scheme.
IncusOS boot security, encryption, and access model
Security is the cornerstone. IncusOS actively relies on UEFI Secure Boot y TPM 2.0 (although it is useful to know the shim vulnerability) to measure and secure the boot chain, as well as enable full disk encryption. The encryption relies on TPM for both LUKS and ZFS, ensuring that the keys are tied to the hardware.
The system is completely locked: There is no local shell or remote access via SSHAdministration is done through the Incus API, with strong authentication using TLS client certificates or, if you prefer, OIDC external. This approach reduces the attack surface and decreases the risk of uncontrolled changes in production. Some similar security projects, such as Predator OSThey explore similar models.
Immutability and atomic updates (A/B)
The A/B design used by IncusOS maintains two system partitions: one active and one spare. Updates are applied to the spare partition so that, upon reboot, Enter the new version safely and reversiblyIf a problem is detected, you can revert to the previous partition without service interruption.
Furthermore, all system partitions are read-only and signedminimizing the risk of corruption and ensuring integrity. With sysupdate and sysext, new versions are delivered in a controlled manner, and applications are integrated cleanly and declaratively onto the database.
Supported architectures and deployment
IncusOS runs on modern computers amd64 (x86_64) and arm64encompassing both Intel/AMD and ARM hardware. This allows for deployment on next-generation physical servers and also on multiple virtualization platforms, where performance and consistency remain the priority.
If you're worried about the learning curve: the official documentation shows everything from installation on bare metal to how Start it on different virtual machine platformsIn other words, you can test it in a lab in minutes and, when you're convinced, take it to production as is.
IncusOS Installation and Initial Boot: No Traditional Installer Required
IncusOS doesn't have a standard installer. You can pull it straight from the middle You can either write it to yourself or let it automatically install to an internal disk on the first boot. This process is designed to simplify the operator's work and reduce potential points of failure.
Since there is no shell, customization is done with a initial configuration tool This allows, among other things, defining which client will have permission to control the system. From there, all host governance is done via API, with mandatory authentication, reinforcing the security model.
Key features of the IncusOS design
The value proposition combines secure boot, encryption, and management surface locking. Together, IncusOS prioritizes security, performance, and predictabilityAmong the design pillars are the use of UEFI Secure Boot, measurements with TPM 2.0, A/B partitioning, signed read-only system, and exclusive API management.
Storage: ZFS auto and enterprise ecosystem
A factory creates a automatically create local ZFS poolsimilar to what NAS-oriented systems like ZimaOS for NASwith support for creating more complex configurations on additional disks. If you need SAN or advanced scenarios, there is support for Fibre Channel and multipath, as well as NVMe over TCP and iSCSI.
For demanding topologies, IncusOS supports LVM in cluster It handles these transports and integrates with Ceph for software-defined storage. Linstor support is planned for the near future, further expanding deployment options.
- Automatic ZFS pooling and TPM-backed ZFS encryption.
- Fiber Channel, multipath, NVMe/TCP and iSCSI.
- Clustered LVM and Ceph support; Linstor on the way.
Network: VLAN bridging, link aggregation, and SDN
The network is also very well maintained. IncusOS generates bridges with VLAN supportThis makes it easy to connect containers or machines to any physical interface on the host. For availability and bandwidth, it supports link aggregation (both passive and negotiated).
Includes LLDP support for discovery, corporate proxy with KerberosRobust NTP and remote log transmission via syslog over UDP, TCP, or TLS. For SDN, the system integrates OVS/OVN and also features native Tailscale support; Netbird is planned for the near futureIn addition, there are network and security solutions such as IPFire for centralized network functions.
- VLAN-aware bridges and link bonding.
- LLDP, enterprise proxy with Kerberos and robust NTP.
- Remote syslog (UDP, TCP, TLS) and SDN with OVS/OVN.
- Native integration with Tailscale; Netbird is coming soon.
Management: centralized operations and flexible updates
At the operational level, IncusOS can be centrally managed through Operations CenterFurthermore, it allows you to perform backups and restores of both the main system configuration and the data of each application separately.
If you need to return to a known state, you can run a factory reset of the entire system or only certain applications. The update mechanism is also flexible: you can adjust the frequency, disable automatic updates, or define maintenance windows to apply changes smoothly.
IncusOS Release Schedule and Update Channels
There are two update channels: stable y testingBy default, the facilities are located in stablewith an approximate weekly release schedule that incorporates the latest stable kernel and relevant security patches. Those seeking more up-to-date updates can opt for testing, which is usually updated daily.
The systems check for new versions every 6hIncus updates automatically with a very brief API pause, without affecting running instances, and any base system updates are ready to be applied on the next reboot. If needed, you can change this frequency or disable automatic updates completely.
Image construction, CI/CD and publishing
The project repository contains all the source code used to build the IncusOS production images. When It pushes a new label The tag to the repository triggers a full image build, which is then downloaded and validated by the publishing server. The resulting image is then exposed on the channel. testing until a reviewer manually promotes it to stable.
You can check the logs of the most recent builds at GitHubActions: build workflowThe final images are published in images.linuxcontainers.org/os/, from where you can download them or integrate them into your pipeline.
To ensure quality, a daily test This exercises a large portion of the API endpoints and other tests that wouldn't be practical to run on every pull request. The development is publicly available on GitHub. github.com/lxc/incus-os.
Technology base and components
Under the hood, IncusOS uses a stripped-down Debian 13 with Zabbly builds of the kernel, ZFS, and Incus, giving you access to stable and recent versions Of all those components, Systemd provides the key tools: mkosi for generating images, sysext for application deployment, sysupdate for updates, and utilities for initial partitioning and TPM-backed encryption.
The project combines configuration files to run mkosi with a set of tools and a system management daemon written in Go. All code is released under a license Apache 2.0 and there are detailed contribution guidelines in the official documentation for anyone who wants to collaborate.
Guarantee of consistency and scalability
One of IncusOS's greatest strengths is that all servers run exactly the same code. the same set of bitsThere are no variations between hosts, which greatly simplifies daily operations: fewer surprises, less "it only happens on this node" and a more direct path to scale or redeploy dozens or hundreds of machines when needed.
By eliminating the local shell layer and centralizing management in an authenticated API, the risk of configuration drift over time is reduced. This operational consistency, with immutable read-only partitions and signatures, has a direct impact on reliability and in the predictability of changes.
Operations Center and Migration Manager
IncusOS not only serves as a host for Incus; it can also be used as a base system for Operations Center y Migration ManagerThis combination opens the door to orderly migrations from environments like VMware to Incus, maintaining an underlying system that is easy to upgrade, secure, and aligned with the immutable philosophy.
With granular backups (main configuration and application data), selective restores, and scheduled updates, the Incus + IncusOS + management tools triad allows for a comprehensive approach. controlled transitions without unnecessary pain.
Getting started with IncusOS: documentation and downloads
The official documentation explains how to start it up physically, how to test it as virtual machine and how to get the most out of each component (storage, networking, management, and security). The release announcement and related resources are available on the Linux Containers forum: IncusOS announcement. As well They are on GitHub.
To get straight to the point, the images are published after passing validation at: . Before that, you can track the build status in GitHub Actions and, when they're ready, download and implement them in your laboratory or production environment.
New within the Incus ecosystem
IncusOS arrives as part of the natural evolution following the fork of LXD into Incus. Project leader Stéphane Graber himself presented IncusOS after more than a year of development, describing it as a modern and unchanging environment specially designed to run Incus, with atomic A/B updates and a robust security posture based on Secure Boot and TPM.
Debian 13's minimalist approach, combined with ZFS (OpenZFS) and extensive use of systemd tools for compilation, installation, and updates, completes a platform that, by design, It operates entirely via API with TLS certificate authentication or via external OIDC.
Lessons from the unchanging world in other systems
Similar ideas have been discussed in the BSD ecosystem for years (for example, in NanoBSD). There were proposals to update the base system as zfs receivegenerating a new “boot environment” and activating it on the next boot. The biggest hurdle there is that fstab must reside in the root, which drags /etc to the root filesystem and prevents reusing the exact same base in each deployment.
Apple addressed a similar problem by separating root volume and user volumeso that the first can locate the local configuration in a well-known place. In FreeBSD, the idea was also to homogenize base system configurations with UCL and allow signed inclusionschaining that signature to the secure boot chain. The goal is the same as that pursued by IncusOS: an immutable base that only consumes mutable volume configuration if it is properly authenticated.
Lifecycle transparency and licensing
The project publishes all its work under the license Apache 2.0With contribution guidelines available in the documentation, this allows operators and developers to understand how images are assembled, review the Go management daemon code, and participate in the cross-channel tagging, compilation, and promotion workflow.
The combination of daily CI stressing the API, manual promotion of testing a stable and the signing of system partitions produces a more predictable lifecycle. In other words, the risk of regressions is reduced in production and you gain control over when and how to apply changes.
IncusOS brings a modern and pragmatic approach to Incus hosts: boot security with TPM and Secure Boot, full disk encryption, read-only system and reversible A/B updates; enterprise-ready networking and storage; 100% API-driven management; and a transparent build and testing pipeline. With two update channels, checks every 6 hours, and open release of build images and logs, The result is a solid, consistent, and very easy-to-operate platform for anyone looking to deploy and scale infrastructure on Incus.
