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 with Incus?
The shortest path takes three steps. Install Incus from the Zabbly repository or your distribution's native package, in a few minutes. Then follow the first steps to launch your first system container and your first virtual machine, and learn to manage your instances day to day. The training path lists every lesson in reading order, with progress tracking.
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.
Why I recommend Incus
I like Incus because it reconciles two worlds: the lightness of containers and the flexibility of virtual machines, without the weight of a full hypervisor. For a homelab or a Linux infrastructure server, it is often the best compromise: you deploy a working Debian machine in two seconds, back it up with a snapshot, automate it through the API, and the day you need a different kernel or Windows, you switch to a virtual machine with the same command. Community governance and the absence of any dependency on a single vendor finish convincing me.
Key points
- Incus is the community fork of LXD: a single CLI,
incus, for system containers and QEMU virtual machines. - The reference version is the Incus 7.0 LTS; feature releases are supported only until the next one.
- Moving from a container to a virtual machine, for another kernel or for Windows, takes the same command.
- The path aims at a sovereign private cloud, then at migrating a VMware estate onto it.
- The seven stages of the course follow the order of the navigation: from installation to a private cloud.
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.
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 |
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).
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.
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
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
This first stage draws the founding distinction with Docker. Incus vs Docker explains that Docker packages an ephemeral application, whereas Incus provides a complete Linux machine that persists over time. Installing Incus then 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, the first steps launch your first system container or your first virtual machine with a single command, followed by exec and snapshot. 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. Managing instances covers the instance lifecycle (start, clone, snapshot, export), then OCI containers show how to run a Docker Hub image inside Incus. Networking connects containers through the incusbr0 bridge (NAT, proxy device, DNS), storage provisions ZFS or LVM pools with volumes and snapshots, and profiles and projects industrialise and compartmentalise configuration.
Field needs follow: GPU passthrough to attach an NVIDIA card to a container or a virtual machine, remote access and the web UI to drive remote servers, and automating image builds with Packer and Ansible. The stage ends with securing Incus, which covers unprivileged instances, limits and restricted projects, and debugging a VM at boot to recover a machine stuck in emergency mode.
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 it is the base you choose when reproducibility and a reduced attack surface outrank the flexibility of a classic server. Incus OS without a shell presents this host you no longer tinker with by hand, and its seed installation. A/B updates and rollback apply atomically, with automatic rollback on failure. Tailscale on the nodes then links the machines through a private mesh network, and backup and monitoring protect and watch a base with no shell.
4. Clustering and high availability
An Incus cluster gathers several servers under a distributed database, with automatic instance placement and high availability. Building a cluster shows that three nodes are enough to reach a quorum that survives losing one machine, with placement and evacuate. Roles, quorum and HA explains how to spread the roles (database, OVN, workers) and hold the quorum, then workers and remote nodes extends the cluster to distant machines. The stage ends with 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 first build OVN virtual networks with their load balancers (OVN networking), the equivalent of distributed VPCs. Network ACLs then segment traffic like Security Groups. The multi-tenant private cloud isolates several tenants with their own projects, quotas, scoped credentials and peering between VPCs. Operations Center drives the fleet of clusters, and a three-tier stack with 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, migrating from LXD switches an existing install in place with lxd-to-incus, 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 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.