Incus runs containers, VMs, and clusters from a single CLI — no Canonical, no CLA, no subscription

On August 7, 2023, Aleksa Sarai forked LXD after Canonical pulled the project out of the Linux Containers community and placed it under its own corporate governance. On June 26, 2026, Incus 7.2 shipped with stateful live migration for VMs and native OCI support for application containers. On July 10, 2026, the 7.0.1 LTS patch locked in the stable branch through June 2029. Three years after the fork, Incus has become the canonical home of LXD’s original codebase — maintained by the exact team that built LXD in the first place, hosted under Linux Containers, licensed Apache 2.0, and free of any CLA obligations.

Incus doesn’t replace one tool. It replaces three. It runs Linux system containers like LXD, OCI application containers like Docker, and QEMU virtual machines like Proxmox — all through the same CLI, the same REST API, and with the option to spread them across a cluster of physical nodes. For a homelab operator, a small business, or an SRE managing heterogeneous infrastructure, that’s a Swiss Army knife that eliminates three separate maintenance plans.

How a fork swallowed the original

The Incus origin story starts where LXD’s went off the rails. In July 2023, Canonical announced that LXD would no longer live under the Linux Containers umbrella — the community organization that had hosted it since its creation in 2014 — and would instead become a Canonical product with a mandatory CLA for external contributors. A CLA (Contributor License Agreement) gives Canonical the legal right to relicense contributed code under proprietary terms without asking the original authors. For the community that spent nearly a decade building LXD for free, that was a red line.

Aleksa Sarai — the longtime LXD package maintainer for openSUSE and a core contributor to runc and umoci — responded within days. He forked the LXD 5.16 codebase, stripped the CLA, and published it under the name Incus (the anvil cloud, from Cumulonimbus incus). Linux Containers officially adopted the fork on November 1, 2023.

Here’s the part that matters: Incus’s initial maintainer lineup included Stéphane Graber, Christian Brauner, Serge Hallyn, and Tycho Andersen — the entire team that originally created LXD. The fork didn’t lose its authors. It got them back. The result: 41,484 commits on GitHub, 5,800 stars, monthly feature releases, and an LTS 7.0 branch supported through June 2029.

Three runtimes, one tool — system containers, OCI containers, and VMs

This is Incus’s core value proposition. Most virtualization tools specialize: Docker for application containers, LXC for system containers, QEMU/libvirt or Proxmox for VMs. Incus does all three with the same daemon, the same CLI, and the same storage and network abstractions.

A system container simulates a full OS. It boots with systemd, runs services, survives reboots, and behaves like a lightweight Linux machine — minus the overhead of a guest kernel. This was LXD’s original use case: isolating services like PostgreSQL, nginx, or Redis inside near-native environments that share the host kernel.

# Spin up a Debian 13 container in 30 seconds
incus launch images:debian/13 my-server
incus exec my-server bash

An OCI application container runs a standard Docker image. Incus has shipped an OCI runtime since the 6.0 LTS release — it can execute any image from Docker Hub, GHCR, or a private registry without Docker Engine installed.

# Run a Docker image directly with Incus
incus launch docker:n8nio/n8n my-n8n

A virtual machine runs with QEMU as the backend, complete with a guest kernel. Incus handles cloud-init, UEFI, Secure Boot, virtual TPM, and GPU passthrough. You can launch a Windows 11 VM, a FreeBSD VM, or a custom kernel without ever leaving the Incus ecosystem.

# Launch an Ubuntu 24.04 LTS VM
incus launch images:ubuntu/24.04/cloud my-vm --vm

All three instance types share the same configuration profiles, the same storage pools (ZFS, Btrfs, LVM, Ceph, Dir), and the same networks (bridge, macvlan, OVN). A system container and a VM can talk to each other on the same Incus-managed bridge, with identical firewall rules. You define the network once, and every instance plugs into it.

OCI containers in detail — the Docker bridge

The OCI runtime deserves its own section because it changes the calculus for anyone running both Docker and LXD.

Incus’s OCI support isn’t a shim or a compatibility layer — it’s a direct integration with the OCI image specification. You pull from any OCI-compatible registry, Incus converts the layers into its own storage format, and the container boots with the same isolation model as a system container. The result is an application container that behaves like a lightweight VM: it gets an IP on your Incus bridge, it has persistent storage that survives incus stop, and you can snapshot it mid-flight.

# Add Docker Hub as a remote
incus remote add docker https://docker.io --protocol=oci

# Pull and run any image
incus launch docker:traefik:latest my-traefik

The tradeoff is that Incus doesn’t implement the full Docker API. There’s no docker-compose equivalent, no BuildKit, no Docker networking plugins. Incus replaces the Docker runtime, not the Docker ecosystem. For a service like Traefik that needs persistent certificates and hot reloads, Incus’s model is actually better than Docker’s. For a CI/CD pipeline that rebuilds containers 20 times an hour, Docker (or Podman) is still the right tool.

Clustering that doesn’t need a degree in distributed systems

Incus ships with native clustering that has zero external dependencies. No etcd, no Consul, no Corosync: the consensus layer is handled directly by the Incus daemon via Raft, and the distributed database runs on Dqlite — a distributed fork of SQLite originally created by Canonical, ironically, and carried forward unchanged in the community fork.

Adding a node to the cluster takes three commands:

# On the primary node
incus config set core.https_address :8443
incus cluster enable node1

# On the new node
incus admin cluster join <token>

The payoff: a single API endpoint that exposes every instance in the cluster, regardless of which physical node it lives on. Instances can be live-migrated between nodes, with or without shared storage. Containers and VMs can coexist on the same nodes or be split by role — web servers on node 1, databases on node 2, dev VMs on node 3.

Incus clustering is not an orchestrator in the Kubernetes sense. It doesn’t do automatic scheduling, application-level health checks, or rolling updates. But for a three-server cluster running internal services with manual high availability, it replaces Proxmox VE — without the web UI, without the subscription nag, and without the administrative overhead.

Incus vs Proxmox — the right cluster for the right scale

Proxmox VE is a full-featured hypervisor with a polished web interface, an HA orchestrator, integrated distributed storage (Ceph), and a built-in firewall. When you’re managing a rack of servers with dozens of VMs, automatic live migration, and granular backup policies, Proxmox earns its keep. But it comes with a subscription (optional but strongly recommended for enterprise repository access), a web interface that’s mandatory for many operations, and a non-trivial system footprint.

Incus has no native web UI. Everything goes through the CLI or the REST API. There’s no automatic HA with fencing and quorum — live migration is manual. There’s no built-in backup scheduler or integrated monitoring dashboard.

What Incus gives you in return is radical lightness. An Incus node with no running instances sits under 100 MB of RAM. There’s no prescribed storage model — mount whatever you want (ZFS, Btrfs, LVM, Ceph, NFS) and Incus adapts. There’s no subscription, no license key, no renewal popup.

For a homelab or small business with three servers, the decision tree usually looks like this:

• Under 5 VMs, many containers → Incus. Lightweight and simple beats the web UI.
• Over 10 VMs, automatic migration, backup policies → Proxmox. The web UI and HA orchestrator justify the subscription.
• Single server → Incus, no question. Running Proxmox on one node is like driving a Formula 1 car to the grocery store.

Storage, snapshots, and backups — the foundation

Incus inherits LXD’s excellent storage management. Instances live inside storage pools that can be backed by ZFS, Btrfs, LVM, Ceph, or plain directories. The backend you choose determines which features are available:

• ZFS and Btrfs enable near-instant snapshots, deduplication, and send/receive for incremental backups. A container snapshot under ZFS completes in under a second, regardless of how much data is stored.
• LVM gives you classic logical volumes with live resizing.
• Ceph (via RBD) provides distributed storage with multi-node replication for production clusters.

# Create a ZFS pool and launch an instance on it
incus storage create pool1 zfs source=/dev/sdb
incus launch images:debian/13 my-server --storage pool1

# Snapshot before a risky migration
incus snapshot create my-server before-migration

# Roll back if things go wrong
incus snapshot restore my-server before-migration

For backups, Incus can export a full instance (container or VM) as a compressed tarball, or use incus copy to duplicate instances between storage pools, between cluster nodes, or to a remote server via the API. No external backup scripts, no cron — everything is built into the CLI.

The relationship with IncusOS

In early 2026, the Linux Containers project introduced IncusOS — a minimal, immutable Linux distribution purpose-built to run Incus. Think of it as the Incus equivalent of VMware ESXi or Proxmox VE’s installer: you boot the ISO, it installs a stripped-down OS with nothing but Incus and its dependencies, and you manage everything — networking, storage, instances — through incus commands.

IncusOS is still young. As of July 2026, it’s seeing active forum discussion around installation quirks, EFI variable handling, and OCI console logging. It’s not yet at the “throw it on bare metal in production” stage. But it signals where the project is heading: towards a vertically integrated stack where the host OS itself is managed by Incus, closing the gap with Proxmox’s appliance model without sacrificing the lightweight CLI-first philosophy.

Migrating from LXD

If you’re already on LXD, migration is documented and reversible. The lxd-to-incus tool (shipped by the Incus project) converts your LXD database to Incus format and recreates every instance without data loss.

# Install the migration tool
sudo apt install incus-tools

# Run the migration
sudo lxd-to-incus

Compatibility is near-total: images, profiles, storage pools, and networks are preserved. Running containers aren’t restarted during migration. The only friction point is complex networking — OVN bridges and cross-host tunnels may need manual reconfiguration after the switch.

Starting from scratch is a two-command affair on Debian, Ubuntu, Fedora, or Arch Linux:

# Debian/Ubuntu
sudo apt install incus

# Interactive setup (answer the prompts)
sudo incus admin init

Verdict

Use Incus if you manage a homelab, a small business, or a heterogeneous server fleet with a mix of containers and VMs. The unified CLI, dependency-free clustering, ZFS snapshots, and Apache 2.0 license without a CLA make it the most versatile tool in the Linux Containers ecosystem. The 7.0 LTS is guaranteed through June 2029 — your infrastructure won’t be orphaned by corporate governance six months from now.

Keep Docker for application containers and Proxmox for large VM clusters. Incus doesn’t replace the Docker ecosystem (Docker Compose, Docker Hub, BuildKit) or Proxmox’s HA orchestrator. But when you’re currently running LXD, a Docker daemon for persistent services, and a small Proxmox cluster, Incus replaces all three with a single daemon, a single command line, and zero subscription fees.

The real cost of Incus is the absence of a web UI and the need to read documentation for advanced clustering. For an SRE who lives in the terminal, that’s not a cost — it’s the pitch.

References

• Incus — Official website — accessed July 8, 2026
• Incus — Fork announcement — August 7, 2023
• Incus GitHub Repository — 5,800 stars, 41,484 commits, Apache 2.0
• Incus 7.2 — Release notes — June 26, 2026
• Incus 7.0 LTS — Release notes — April 2026
• Incus Documentation — accessed July 8, 2026
• Zabbly — Incus packages and commercial support — accessed July 8, 2026
• LXD — Canonical takeover announcement — accessed July 8, 2026