IncusOS vs Talos Linux: Two Immutable Operating Systems, Two Different Philosophies

Two operating systems currently sit at the sharp end of the immutable server trend, and they keep getting compared because their pitch sounds identical: a minimal, locked down, API-managed OS, updated atomically, with no shell to log into. The comparison misleads in one important way, though, because, until September 2026, the two systems made opposite bets about what the OS is actually for. Talos Linux turns hardware into a Kubernetes node. IncusOS turns hardware into a virtualization host, and that host then runs whatever you want, from single containers to entire Kubernetes clusters inside VMs. Those bets are starting to converge (Talos is gaining hypervisor capabilities in alpha), but they still describe what each system is in production today.

If you remember one sentence, make it this one: Talos is the OS for people whose destination is Kubernetes; IncusOS is the OS for people whose destination is a private cloud of VMs and containers.

One note on scope: this is deliberately a concept-level post. There are no command walkthroughs here, because both systems are designed so that you almost never touch them directly. Memorizing their tooling teaches you the least important part of either one. What matters for choosing is the philosophy, the workload model, and the operational trade each system makes, and that is the whole post.

The short version

• The promise is the same. Both are immutable, signed, API-only operating systems with atomic A/B updates and no shell to log into. The similarity ends right there.
• Talos makes Kubernetes the entire point. Boot it and the machine is a Kubernetes node; the API manages the machine, and Kubernetes is the only workload it hosts today, though an alpha hypervisor is broadening that.
• IncusOS makes Incus the management layer. Boot it and the machine is a virtualization host: VMs and system containers of any flavor, with Kubernetes available later as a tenant inside VMs.
• The choice is about your destination, not quality. If Kubernetes is where you are going, pick Talos. If a mixed instance fleet or a small private cloud is where you are going, pick IncusOS. If you do not know yet, IncusOS is the safer first step because it rules nothing out.
• The hardware gates differ. IncusOS wants UEFI Secure Boot and a TPM 2.0 chip and modern CPUs, with documented degraded-security workarounds for homelab use; Talos boots from a small image almost anywhere, VMs and cloud instances included (IncusOS documents cloud and hypervisor installs too, largely for evaluation).

What immutable means when there is no shell

Both systems belong to the immutable family, and the term means something specific here. The thing you install is an image built by the project: a fixed set of software, verified at boot, mounted read-only. The disk is typically split into two system slots, A and B; the running one is read-only and cryptographically signed, and an update is applied by writing the new image to the other slot and rebooting into it. If an update misbehaves, you boot back into the previous slot. There is nothing to hand-patch in place, no way for two servers running the same version to end up with different files, and no config drift to hunt down at audit time.

The second half of the deal is that there is no shell. No SSH, no console login, no package manager. Every interaction with the machine goes through an authenticated API that speaks for one specific management layer. That sounds terrifying if you grew up fixing servers over SSH, and it is genuinely disorienting for the first week. It is also the feature: a machine nobody can log into cannot be interactively misconfigured, and the intended remedy for a misbehaving node, in both systems, is to redeploy it rather than poke it.

Talos Linux: the OS that disappears into Kubernetes

Talos is built by Sidero Labs, and its own documentation calls it a Kubernetes-optimized Linux distro that does one thing and does it better than any general purpose distribution. Boot it on bare metal or in a VM and the machine becomes a Kubernetes node: on control-plane machines, the control plane components, including the etcd database, run directly on it, and there is no login prompt. Sidero reports fewer than 50 binaries and a footprint of about 100 MB, and the root filesystem is a read-only image: the OS itself never mutates at runtime. The writable part is a separate state partition mounted at /var, which holds etcd data, kubelet state, and pulled container images; it persists across reboots and upgrades, and the design rule is that everything Talos writes to disk is either replicated or reconstructable, so a rebooted node returns to its declared state.

Management is declarative. A single machine configuration file describes the whole node: networking, disks, kernel settings, and the cluster it belongs to. It used to be one monolithic document; recent releases keep splitting it into small, focused documents within that same file. All access goes through one secured API protected with mutual TLS, so there are no credentials sitting on the box to steal, and every action is auditable through the API. OS upgrades are image-based: you request a version for a node, and the node either lands on the new image or boots back into the previous one. Kubernetes itself is a separate track: since v1.0, upgrading the OS does not upgrade Kubernetes by default; you run talosctl upgrade-k8s, within a Talos-to-Kubernetes support matrix, and hands-free rolling upgrades across a fleet are what Sidero's Omni manager automates rather than something plain Talos does on its own.

The philosophical consequence is the interesting part: Talos historically had no opinion about your workload beyond Kubernetes, because Kubernetes was the only workload it hosted. That sentence stopped being entirely true in September 2026, but it remains the accurate one-line summary today. If your services live in container images and your operations happen through Kubernetes tooling, Talos hands you a cluster with a tiny attack surface, CIS-hardened defaults, SELinux, and trusted boot support, with one vendor responsible for the whole stack: Sidero Labs, which Yardi acquired in September 2026 (Yardi was already running Talos in production), so the vendor behind that stack is now a great deal larger. The project is open source under MPL-2.0, in production since 2020 per Sidero, and its docs and community are the most mature in this category. Sidero sells an Enterprise tier (FIPS builds, compliance artifacts, support, indemnity) and the Omni fleet manager on top, which tells you exactly which buyers it is aiming at.

IncusOS: the OS that disappears into Incus

IncusOS reached general availability in November 2025 after about a year of work, from the same team that maintains Incus, the systems container and virtualization manager from the LXC/LXD lineage. Under the hood it is a minimal Debian 13 base with the Zabbly builds of the Linux kernel, ZFS, and Incus, assembled with systemd's image tooling. Under the hood is the key phrase: the base distribution is a build input, not something you administer, and Debian's presence is invisible.

Its pitch mirrors Talos's, exactly one layer up. IncusOS is immutable, with signed, read-only A/B system partitions. Its full-security mode wants UEFI Secure Boot and a TPM 2.0 chip, and it uses the TPM to measure the boot chain and to seal full disk encryption (LUKS plus ZFS encryption) so the disks are locked to that specific machine. Homelab and evaluation installs can run in a degraded security state with either Secure Boot disabled or a software-backed TPM (never both), though the docs flag that mode as generally unsupported for enterprise deployments. There is no local or remote shell: the only interface is the authenticated Incus API, which manages both the instances and the OS itself, from networking and storage to updates and factory resets.

Because it exists to host virtualization, it solves the boring parts out of the box. It sets up a local ZFS pool automatically and supports complex pools on additional disks, plus iSCSI, NVMe-over-TCP, clustered LVM, and Ceph for shared storage. On the network side it automates VLAN-aware bridging, link aggregation, LLDP, and OVN for software defined networking, and it ships with solid NTP, proxy, and remote logging handling. Updates run on a stable channel that receives at least one weekly release; each machine checks every six hours, applies Incus updates live with only a brief API pause and no impact on running instances, and stages OS updates for the next reboot. Every IncusOS server is guaranteed to run bit-for-bit identical software, which is exactly the property you want when node 12 has to behave like node 4.

It also has an applications concept: instead of installing packages, you enable first-party applications on top of the base. The primary list is short today: Incus itself, Operations Center for central management of a fleet, and Migration Manager, which exists to move VMware estates to Incus, with a handful of smaller non-primary add-ons such as Ceph, Linstor, and GPU support. That list is telling: IncusOS is explicitly positioning itself as the base OS for organizations leaving VMware and for anyone building a small private cloud, and it is younger and narrower by design.

Same lockdown, opposite layer

Both systems delete the shell and replace it with an API, and this is where the philosophies genuinely diverge: they disagree on what that API should expose. Talos's API manages a Kubernetes node, and its declarative config is about the machine. IncusOS's API manages a virtualization host, and its day-to-day surface is Incus, which manages tenants: VMs, system containers, images, networks, and storage pools. In Talos the platform is the product. In IncusOS the platform is a service that the product provides.

Practically, this decides where Kubernetes lives. On Talos, Kubernetes is the host, the scheduler, the storage orchestrator, and the management plane, and anything not shaped like a container has been out of scope by design, though that boundary began moving with the September 2026 Talos Hypervisor announcement described below. On IncusOS, Kubernetes is just a tenant: a common pattern is to run cluster nodes as plain VMs inside Incus, so you keep the immutable, self-updating base and still run whatever cluster flavor you like inside (our Incus vs Docker comparison is the companion read for how those instance types differ from ordinary Docker containers). The reverse has been true until now: stable Talos will not host your random VMs or non-container workloads: the only route was KubeVirt, which runs VMs through Kubernetes rather than removing the Kubernetes requirement.

Sidero made that last sentence historical, at least in pre-release form: on September 14, 2026 it announced Talos Hypervisor, extending Talos beyond Kubernetes. Technically it is libvirt and QEMU/KVM shipped as a system extension: virtual machines are declared in the same machine configuration as everything else and operated through the same API, without KubeVirt and without requiring VM teams to learn Kubernetes, and containers become schedulable directly, without Kubernetes, for single-node edge sites. The alpha ships in Talos 1.15.0-alpha.1 (released October 13, 2026) and was demonstrated at TalosCon 2026 in Amsterdam; general availability is planned for December 2026. That does not collapse this comparison: stable Talos in production today is still a Kubernetes appliance, the hypervisor is alpha, and Talos remains Kubernetes-first. But the honest framing is no longer opposite bets; it is opposite starting points, converging.

Which one should a new user pick?

The question is not which OS is better; it is which destination you are actually heading for. Three questions decide it, in order:

1. What will the machine run in a year? If the honest answer is a Kubernetes cluster, pick Talos. If the answer is a mix of VMs, containers, databases, a media server, a git server, and eventually a Kubernetes playground, pick IncusOS.
2. Are you choosing a workload or an OS? Talos is a workload decision: committing to it means committing to Kubernetes-native tooling for storage, networking, and operations. IncusOS is an infrastructure decision: it stays useful no matter what ends up running inside its instances.
3. What does your hardware look like? IncusOS wants UEFI Secure Boot and TPM 2.0, and the practical CPU floor is recent silicon: x86-64-v3 on Intel/AMD, or a modern ARM system. Homelab and evaluation installs can work around a missing piece (either Secure Boot disabled or a software TPM, not both) in a documented degraded security state. Talos boots from a small image almost anywhere, including VMs and cloud instances, though IncusOS documents installs on Hetzner, OpenStack, Scaleway, and every common hypervisor too.

Choose Talos Linux when

• Kubernetes is the destination, not an option. You want to learn or run Kubernetes properly, and you are happy doing things the Kubernetes way (declarative, GitOps-friendly) rather than the Linux way. Our Argo CD vs Flux comparison is the natural next read once the cluster is up.
• You want the smallest possible attack surface. No SSH, no shell, fewer than 50 binaries, CIS-hardened defaults: the security story is the selling point, and auditors like it. Sidero's Enterprise tier exists largely to formalize that story for compliance buyers.
• You are building for a fleet, not a box. One declarative machine config per node, plus Omni when one cluster becomes many sites (source-available under BSL 1.1, not open source like Talos itself), scales without changing your mental model.
• Maturity and ecosystem depth matter to you. Production use since 2020, a large community, extensive documentation, an image factory, and established upgrade tooling.

Choose IncusOS when

• You want immutable infrastructure without marrying Kubernetes. One locked down base under VMs and containers of every flavor, with the option to add clusters inside VMs later.
• You are consolidating a homelab or a small private cloud. ZFS pools, snapshots, VLAN-aware bridging, and shared-storage backends come configured, which removes most of the yak-shaving a virtualization host normally involves (our Proxmox vs IncusOS comparison covers the adjacent platform decision).
• You are leaving VMware, or your hypervisor of choice is aging. The team ships Migration Manager for exactly this scenario, and Operations Center manages the resulting fleet centrally.
• You can accept young software. General availability arrived in November 2025; the documentation is good but short, the application list is still small, and fast-moving cuts both ways.

When neither is the right answer

• You need a general-purpose, mutable Linux box. Package installs, custom kernels, a desktop, or plain Docker on Ubuntu or Debian: a classic distro is still the right tool, and an immutable appliance will fight you the whole way.
• Your hardware lacks both TPM 2.0 and working Secure Boot. IncusOS can cope with one missing piece in a degraded security state, but not both at once, and it positions that mode as homelab-and-evaluation only. Pre-v3 Intel/AMD CPUs remain out of reach for it entirely. Talos remains an option there, as does plain Linux.
• Your team's whole skill set is Kubernetes. Then Talos is the obvious pick anyway, and IncusOS would add a layer you do not need.

The learning curve, honestly

New users usually ask which one is easier, and the honest answer is that they are difficult in different places. Talos removes Linux administration from the curriculum entirely: you will not learn systemd units or package management on it, and if your mental model of servers is 'log in and edit files', the API-first workflow is the hard part. What you learn instead is Kubernetes itself, which is the point. IncusOS keeps the familiar virtualization mental model: you create instances and install things inside them, roughly like you always did on VM hosts, but the host itself has no shell, so host-level problems route through the API, and the community's debugging habits are still forming. Neither will teach you classic sysadmin craft, which is a feature of the category rather than a bug, as long as you choose it with open eyes.

The honest limits

• This is a concept comparison, not a benchmark. I am not claiming performance numbers for either side; both OSes are thin enough that measured deltas come from the workload, not from the OS.
• IncusOS adoption evidence barely exists yet. General availability was November 2025, so the evidence base is early adopter posts and the team's own communication. Talos has years of production reports plus vendor-published adoption figures (about 1M downloads a year and 109k+ registered clusters, per Sidero's own pages).
• Vendor-reported numbers are vendor-reported. The Talos figures above come from Sidero's marketing and docs; treat them as directional until you measure them in your own fleet.
• Immutability is a trade, not a free lunch. When there is no shell, there is also no interactive late-night fix: you redeploy, you restore from backup, or you wait for a fixed image. That is the point of the category, but budget for the mindset shift, and for the backup plan.

FAQ

Can I run Kubernetes on IncusOS?

Yes, inside instances. The common pattern is Kubernetes nodes as VMs under Incus, so you keep IncusOS's immutable, self-updating base and run a stock cluster inside it, Talos-based or otherwise. What you do not get is Kubernetes as the native management layer of the host, which is precisely the thing Talos gives you.

Is IncusOS just ESXi with a REST API?

In spirit, yes: a minimal, dedicated virtualization host appliance. In practice it is more modern: immutable A/B updates, Secure Boot with a measured boot chain, TPM-sealed encryption, API-only management, and an open source base under Apache 2.0 rather than a proprietary stack.

Which is easier for a complete beginner?

If your goal is Kubernetes, Talos, because its entire purpose is to get you to a working cluster fast and its documentation walks you straight there. If your goal is 'a server that runs things', IncusOS, because the instance model matches what most beginners already understand from VMs. Both remove SSH, which is the biggest mental jump in either case.

Do I really lose the ability to fix things?

You lose the ability to fix things on the box. Debugging happens through the API, logs, and metrics, and the intended remedy for a bad node is redeployment from the same image. If you want to hand-edit configs at 2 AM, immutable appliances are simply the wrong category; that restraint is what makes them reliable.

Can I run my usual Docker containers on either?

On IncusOS, Docker runs happily inside your instances, in a VM or a system container, exactly like on any Linux box. On Talos there is no general Docker daemon to treat as a host runtime: containers run through Kubernetes today, with Kubernetes-free container scheduling arriving as part of the Talos Hypervisor alpha. If your mental model is 'a compose file on a server', neither appliance is your runtime; IncusOS can host a VM that runs it.

What do they cost?

Both core systems are free and open source: Talos under MPL-2.0, IncusOS under Apache 2.0. Commercial support exists around both: Sidero sells an Enterprise tier and the Omni fleet manager (source-available under BSL 1.1 rather than open source, though self-hosting for personal use is allowed and there is a free hobby tier), while the IncusOS ecosystem has commercial offerings through Zabbly and FuturFusion. The Talos Hypervisor, meanwhile, ships as part of open source Talos Linux itself.

Further reading

• The IncusOS announcement, with design notes from the project lead: https://stgraber.org/2025/11/07/introducing-incusos/
• IncusOS project documentation, features, and update policy: https://linuxcontainers.org/incus-os/
• What is Talos Linux, from the project docs: https://docs.siderolabs.com/talos/v1.14/overview/what-is-talos
• Sidero's Talos Linux page, including the security and enterprise pitch: https://www.siderolabs.com/talos-linux
• The full IncusOS release thread on the Linux Containers forum: https://discuss.linuxcontainers.org/t/announcing-incusos/25139

Which way did you go, and what decided it: a Kubernetes-only fleet on Talos, or a mixed instance fleet on IncusOS? If you moved from one to the other, tell me what surprised you most. Drop it in the comments.

Until next time, keep your systems thoughtful.