On 7 November 2025, Stéphane Graber, Incus's lead developer, announced Incus OS: an immutable system that runs exactly one thing, Incus. No packages to manage, no configuration drift, and above all no shell. You do not open an SSH session on these machines: everything goes through an authenticated API.
I wanted to see what that means in practice, not by reading the docs but by doing it. I set myself a deliberately uncomfortable goal: build a 3-node cluster on Proxmox virtual machines without ever opening the web interface. Nothing but configuration files and API calls. Here is what I learned, what gets in the way, and why I think this project deserves attention without any hype.
Incus OS in one sentence
Incus OS is not a distribution where you install Incus. It is a system image where the kernel, ZFS and Incus are integrated and signed, identical bit for bit across machines. The base is Debian 13, but you do not manage it: system partitions are read-only, updates are atomic A/B with automatic rollback, and boot is locked down by Secure Boot and TPM 2.0.
The word that comes up everywhere is immutable, but that is not the real differentiator. Immutable operating systems already exist: Talos Linux for Kubernetes, Fedora CoreOS or openSUSE MicroOS on the general-purpose side. What makes Incus OS singular is being single-purpose in service of Incus, therefore covering virtual machines and system containers in the same tool. Where Talos only does Kubernetes, Incus OS targets the full hypervisor role.
The bet behind the announcement
Incus OS did not come out of nowhere. It is part of a wider set presented a month earlier, the FuturFusion Cloud stack: Incus as the engine, Incus OS as the foundation, plus two tools announced on 21 December 2025, Operations Center for large-scale cluster deployment and Migration Manager for migrating away from VMware. The positioning is explicit: offer a fully open source exit path from VMware.
That framing is what intrigued me. This is not a homelab gadget, it is an attempt to cover the whole chain from bare server to production cluster. Whether the foundation holds up under real use is another matter.
My test: a cluster with no interface
Installation goes through an ISO image accompanied by small configuration
files, the seed, written to a second medium labelled SEED_DATA. Those files
drive the installation and the node's first configuration: network, storage, and
above all trust.
That was the turning point. On a machine with no shell, how do you make your
command-line client trusted without going through the graphical assistant?
The answer lies in the seed: you inject a client certificate in PEM format
directly. On first boot the certificate is already recognised. A simple request
confirms it, "auth":"trusted", and from there everything is driven remotely.
The cluster itself is then built like a classic Incus cluster, with two
subtleties specific to Incus OS that I discovered the hard way. At the end of
the chain, incus cluster list shows my three nodes ONLINE, quorum reached,
SSH port closed everywhere. A full cluster built without a single click in the
interface.
The pitfalls that cost me a cycle
I would rather be honest about what does not work first time, because each of these error messages cost me a reinstall.
The target disk must be virtio-scsi. With a virtio-blk disk the installer
refuses to start with a laconic no potential install devices found. The
configuration medium must carry exactly the label SEED_DATA, otherwise
installation stops on unable to begin install from read-only device without seed configuration.
The two real traps come at cluster join time. Without the cluster certificate
in the seed, the node fails on No target cluster member certificate provided:
the interactive client resolves that certificate on its own, but applying a seed
does not. And without specifying the storage pool source, Incus attempts a
file-backed pool that the OS flatly refuses with Loop backed pools aren't supported on IncusOS. Nothing insurmountable, but nothing obvious either when
you arrive.
Going shell-less is a choice, not a shortcoming
This is the most divisive point, and I understand why. Not being able to SSH in for a quick fix is a genuine change of habit. On the official forum, the question "Incus OS or classic Incus for a homelab" comes up often, and the maintainers' own answer is nuanced: to learn and experiment, start with classic Incus, which is more flexible; keep Incus OS for a target close to production, when reproducibility matters more than tinkering.
I share that view. The absence of a shell is not a limitation you endure, it is a design decision: it closes a classic intrusion vector and guarantees that two machines on the same version are genuinely identical. But it forces you to think everything through upfront, in the seed and the API. It is not the right ground for discovering Incus.
The prerequisites that genuinely block
This is where I cut short any false promise. Incus OS does not run "on any hardware". It requires UEFI with Secure Boot, a TPM 2.0 and a recent CPU (x86-64-v3 level, meaning a Xeon E5 v3 at minimum on the Intel side). There is no software TPM fallback: no TPM, no deployment.
The official documentation is explicit: running Incus OS without Secure Boot is discouraged and "not recommended" in enterprise settings. Check your hardware before even trying. Several independent testers also stumbled on TLS certificate trust in the browser, a rougher first contact than expected. These are real frictions, not details.
A young project, but very much alive
The Incus engine itself moves fast. In 2026 alone: 7.0 LTS in May brought OCI image support and a built-in S3 listener, 7.2 in June added per-instance SELinux confinement. That same 7.2 also fixed six critical vulnerabilities, including access to host files through malicious images. I draw two readings from that, and I give you both: the project is active and responsive, and security there is fixed as it goes, as everywhere. A living foundation, not a frozen one.
On the enterprise tooling side, Operations Center and Migration Manager exist, but the project itself acknowledges they are the bare minimum for deploying production clusters, with "a lot of work ahead". The VMware exit path is credible on paper; it is not mature yet. Incus OS was announced less than a year ago: it is promising and already usable for anyone who accepts its constraints, it is not a platform proven over ten years. I will not claim it replaces Proxmox, which keeps a more complete interface, easier GPU passthrough and a far larger community.
Where to start
If this piece made you want to get hands-on, do not start with Incus OS. Start with plain Incus, on your Debian or Ubuntu, where you keep your shell and all your freedom to experiment. Once comfortable, remote access and clustering prepare you for the model that Incus OS pushes to the extreme.
Key takeaways
- Incus OS is an immutable, Incus-only operating system announced in November 2025, with no shell, driven entirely by API.
- A 3-node cluster is buildable without ever opening the UI, provided the client certificate is injected in the seed.
- Four pitfalls cost real time: virtio-scsi disk, exact
SEED_DATAlabel, cluster certificate in the seed, and explicit storage pool source. - The hardware prerequisites are strict: UEFI Secure Boot, TPM 2.0, x86-64-v3 CPU, with no software TPM fallback.
- The maintainers themselves recommend classic Incus for learning, and Incus OS for targets close to production.
- The project is young but active: Incus 7.2 added per-instance SELinux and fixed six critical vulnerabilities.
- The VMware exit path is credible on paper, not mature yet.