Incus is the community fork of LXD, created by Stéphane Graber and maintained by the Linux Containers project. From a single CLI (incus) it drives both system containers (complete Linux distributions, in the manner of a lightweight VM) and QEMU virtual machines. Open source, simple and robust, it has established itself as the light alternative to Proxmox and the natural successor to LXD. The reference LTS in 2026 is Incus 7.0. This page lays the groundwork and points to the guides of the section.
Where to start
What Incus is
Incus is an instance manager: it administers containers and virtual machines through a single CLI and a single REST API. Where Docker launches application containers (one process, a layered image, ephemeral), Incus launches system containers: a complete distribution with its init (systemd, openrc), its services and its users. You connect to it like a small machine, and the instance persists over time.
It builds on proven Linux kernel technologies, namespaces and cgroups for containers, and QEMU/KVM for virtual machines. That dual nature makes it versatile: a light container for a Linux service, a full virtual machine when a different kernel or hardware isolation is needed.
Where Incus comes from: the LXD fork
Stéphane Graber, the former LXD lead at Canonical, started Incus in 2023 when LXD was brought under Canonical's sole governance. Incus takes the same technical base but under community governance (Linux Containers), fully open source, with no proprietary contribution agreement. Zabbly, the company Graber founded, handles packaging and commercial support.
In practice, for anyone coming from LXD: the CLI moves from lxc to incus, and an lxd-to-incus tool migrates an existing install in place. Two dynamics accelerated adoption: the refusal of lock-in after LXD moved under a Canonical CLA, and the VMware exodus of 2024 that pushed teams to look for open alternatives.
Incus against the other tools
Every tool has its zone of relevance. Here is how to place Incus.
| Tool | Nature | When to choose it |
|---|---|---|
| Incus | system containers plus VMs, CLI and API | lightweight Linux machines and VMs, with no heavy interface |
| Docker | application containers | package and distribute an application |
| LXD | the Canonical equivalent | if you stay in the Ubuntu and Canonical ecosystem |
| Proxmox VE | hypervisor with a web interface | a complete virtualisation server with a GUI |
Incus is not strictly a competitor to Docker: since version 6.3 it can even run OCI images (Docker), but its core remains the system container and the virtual machine. Against Proxmox, it offers a lighter, command-line first approach, with no mandatory web interface, though a UI does exist.
The key features
Incus covers the whole instance lifecycle, which makes it a complete platform rather than a mere container launcher.
- Containers and VMs: the same command handles both, with or without the
--vmoption. - Images and remotes: an official image server (
images:) provides dozens of ready distributions; you can also build your own. - Networking: a default NAT bridge (
incusbr0), through to distributed OVN networks in a cluster. - Storage: pools on
dir,btrfs,lvm,zfsorceph, with volumes, snapshots and copies. - Snapshots and backups: freeze and restore an instance, export an archive.
- Clustering: gather several nodes with a distributed database and automatic placement.
- Devices: attach disks, network cards, GPUs (passthrough), ports (
proxy). - REST API: everything the CLI does can be driven remotely and automated.
Which version to install
Incus follows an annual LTS plus monthly feature releases model. For production, target an LTS:
- Incus 7.0 LTS (May 2026): the version recommended for new installations;
- Incus 6.0 LTS: still supported until 2029, useful if your distribution pins it;
- feature releases (7.1, 7.2 and so on): to try new things, supported only until the next one.
The installation detail (signed Zabbly repository or native package) is in the installation guide.
FAQ: common questions about Incus
The community fork of LXD
Incus is the fork of LXD, created by Stéphane Graber and maintained by the Linux Containers project. It is an instance manager that administers, through a single CLI (incus) and a REST API:
- system containers: complete Linux distributions (with init and services), in the manner of a lightweight VM;
- QEMU virtual machines.
Open source and light, it suits a homelab as well as a Linux infrastructure server.
Application containers against system containers
| Docker | Incus | |
|---|---|---|
| Type | application container | system container (plus VMs) |
| Content | one process | a complete distribution |
| Lifetime | ephemeral | persistent |
| Use | package an app | lightweight Linux machine |
An Incus container behaves like a small machine (systemd, services), not like a single process. Since 6.3, Incus can nonetheless run OCI images (Docker) as a complement.
Same base, different governance
Incus is a fork of LXD sharing the same technical base, but:
- under community governance (Linux Containers), fully open source;
- without a proprietary contribution agreement (CLA).
LXD is still developed by Canonical. In practice the CLI moves from lxc to incus. The lxd-to-incus tool migrates an existing LXD install in place, but note that it was removed from the Incus development branch in June 2026: it is present up to 7.1 and in the LTS branches, and absent from 7.2 onwards.
GUI hypervisor against lightweight manager
- Proxmox VE: a complete hypervisor with a web interface, for a centralised virtualisation server (clustering, integrated backups, HA).
- Incus: lighter, oriented towards the CLI and API, with no mandatory interface (a UI does exist), ideal for managing instances as code.
Choose Proxmox for a rich GUI and a turnkey hypervisor; Incus for lightness, homelabs and automation.
Yes, fully open source
Incus is fully open source and free, under the governance of the Linux Containers project. No paid edition holds features back.
Zabbly, the company founded by Stéphane Graber, offers packaging (the official repository) and optional commercial support, but the software stays free. That is one of its strengths against enterprise-licensed alternatives.
Yes, since 6.3
Since Incus 6.3, you can run OCI images (Docker's format), so application containers from Docker Hub and other registries:
incus launch docker:nginx web
That is not the default use of Incus, which stays the system container, but it lets you run application workloads without installing Docker, alongside system containers and virtual machines.
Where this path leads: a sovereign alternative to VMware
If this course goes as far as it does, from the first container to a private cloud, it is not for the sake of exhaustiveness. The stated goal is to offer an exit path from VMware, entirely open source and sovereign. Since the Broadcom acquisition of VMware and the brutal licensing overhaul that followed, many teams have been looking to take back control of their virtualisation without depending on a single vendor.
Incus, its immutable base Incus OS, its Operations Center for driving a fleet and its Migration Manager for importing vSphere virtual machines form precisely that answer. The logic of the path is therefore clear: rebuild a private cloud equivalent to vSphere (virtual machines, containers, distributed networks, high availability), then migrate what exists onto it. The seven steps below follow that goal, from getting started through to switching a whole estate.
The Incus course
This section follows a seven-stage progression, from the first container to a private cloud. It is exactly the order of the navigation on the left: follow it in order to learn, or pick the building block you need.
1. Getting started with Incus
Installing Incus takes a few minutes on Debian, Ubuntu or an RPM distribution, through the signed Zabbly repository or the native package. Once incus admin init has run, one command launches your first system container or your first virtual machine. This stage also draws the founding distinction with Docker: where Docker packages an ephemeral application, Incus provides a complete Linux machine that persists. It is the foundation to master before networking, storage or clustering.
2. Running Incus day to day
This is the core of the job for an Incus administrator. You learn to drive the instance lifecycle (start, clone, snapshot, export), connect containers to the network through the incusbr0 bridge, provision storage on ZFS or LVM, and industrialise configuration with profiles and projects. Field needs follow: GPU passthrough, remote administration, custom images, then hardening unprivileged instances and debugging a virtual machine that refuses to start.
3. Incus OS, the immutable base
What is Incus OS? An immutable operating system dedicated to Incus: no packages to manage, no shell, everything through an authenticated API. System partitions are read only and A/B updates apply atomically, with automatic rollback on failure. It is the base you choose when reproducibility and a reduced attack surface outrank the flexibility of a classic server. This stage covers seed installation, updates, private network access and monitoring a host you no longer tinker with by hand.
4. Clustering and high availability
An Incus cluster gathers several servers under a distributed database, with automatic instance placement and high availability. Three nodes are enough to reach a quorum that survives losing one machine. This stage explains how to spread the roles (database, OVN, workers), add remote nodes, and above all set up shared CephFS storage: without it, an instance stays pinned to its node; with it, it migrates live from one server to another. It is the prerequisite of any serious private cloud.
5. Private cloud (IaaS)
This is the summit of the path: turning the cluster into a private cloud, a sovereign IaaS comparable to a scaled-down AWS. You build OVN virtual networks (the equivalent of VPCs), segment traffic with network ACLs that play the role of Security Groups, and isolate several tenants with their own quotas and scoped credentials. Operations Center drives the fleet of clusters, and Terraform describes the whole thing as Infrastructure as Code. At the end of the chain: a multi-tenant platform built on your own machines, with no external provider.
6. Migrating to Incus
Adopting Incus rarely starts from a blank page. This stage covers the three migration routes. From VMware, Migration Manager orchestrates the transfer of virtual machines, a burning subject since the exodus that followed the acquisition. From LXD, the lxd-to-incus tool switches an existing install in place, with no full reinstall. And for any physical or virtual server, incus-migrate imports the machine into an Incus container or virtual machine. Enough to bring back a whole estate, progressively.
7. Infrastructure as Code
An Incus infrastructure described as code becomes reproducible, versioned and reviewed like any other software. This stage presents the two complementary approaches. The lxc/incus Terraform provider provisions networks, profiles and instances declaratively, and lends itself to complex setups such as a complete three-tier architecture. The Ansible connection plugin then pushes configuration inside the instances, without even going through SSH. Together they close the loop: you stop clicking and apply a plan, and the infrastructure rebuilds itself identically on demand.