Incus: LXD's Community Fork, Two Years In

When the Maintainer Gets Locked Out of Their Own Project

Stéphane Graber created LXD. He maintained it for years as part of the Linux Containers project. Then in 2023, Canonical — who had been employing him — required all LXD contributors to sign a Contributor License Agreement (CLA) that handed Canonical full rights over the codebase. The Linux Containers project had been hosting LXD. Canonical said thanks, took it back, and moved it under their own umbrella.

The result: Graber forked LXD the same day as Incus, kept everything that made LXD worth using, and the community followed.

Two years later, Incus is in Debian stable, Fedora, OpenSUSE, and NixOS. LXD ships exclusively through Snap and requires Ubuntu or an Ubuntu derivative for first-class support. The fork worked.

Here’s where things stand if you’re evaluating containers and VMs for your homelab or production infrastructure in 2026.

What Incus Actually Is (Quick Refresher)

If you’re familiar with LXD, you already know Incus. It’s a manager for two things:

• System containers — LXC containers with a full Linux userspace. Not Docker. Not microcontainers. A whole Ubuntu/Debian/Alpine install with init, systemd, the works. Think of it as a very lightweight VM.
• Virtual machines — Full QEMU+OVMF VMs managed with the same CLI as containers. One tool, two technologies, consistent interface.

That’s the pitch. You get the isolation of VMs and the density of containers from a single daemon, with a REST API and CLI that don’t make you want to flip tables.

Compare this to what we’ve covered before: LXC vs LXD covers the lower-level LXC primitives vs the management layer. LXC vs Docker covers the system container vs application container split. This article is specifically about the LXD → Incus transition and whether Incus is worth your time in 2026.

Getting Incus Running

Incus packages are in the main repos now — no PPA, no Snap drama:

# Debian 13+ / Ubuntu 24.10+
sudo apt install incus

# Fedora 40+
sudo dnf install incus

# OpenSUSE Tumbleweed
sudo zypper install incus

# Arch (AUR)
yay -S incus

After install, add yourself to the incus-admin group and initialize:

sudo adduser $USER incus-admin
newgrp incus-admin

# Interactive setup — ZFS pool, bridge network, etc.
incus admin init

The incus admin init wizard is nearly identical to lxd init. If you’ve done this before, nothing surprises you. Pick a ZFS pool if you have the disk space — it makes snapshot-based workflows significantly faster.

Launching Your First Container and VM

System container from the Ubuntu 24.04 image:

incus launch ubuntu:24.04 mybox
incus exec mybox -- bash

That’s it. You’re in a full Ubuntu 24.04 environment. Systemd running. You can install packages, run services, configure networking. It behaves like a server, not a container runtime.

Full VM (same command, one flag):

incus launch ubuntu:24.04 myvm --vm
incus exec myvm -- bash

Incus spins up a QEMU VM with OVMF (UEFI), virtio drivers, and the same management interface. The --vm flag is the only difference from your perspective. Underneath, it’s a full virtual machine with its own kernel.

Check what you’ve got running:

incus list

+---------+---------+----------------------+-----------------------------------------------+-----------+-----------+
|  NAME   |  STATE  |         IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
+---------+---------+----------------------+-----------------------------------------------+-----------+-----------+
| mybox   | RUNNING | 10.130.26.14 (eth0)  | fd42:c1f:a8b2::14 (eth0)                      | CONTAINER | 0         |
| myvm    | RUNNING | 10.130.26.15 (eth0)  | fd42:c1f:a8b2::15 (eth0)                      | VIRTUAL-MACHINE | 0    |
+---------+---------+----------------------+-----------------------------------------------+-----------+-----------+

Profiles: Reusable Config Blocks

Profiles are where Incus gets genuinely useful. Instead of configuring every instance by hand, you define reusable blocks of config and apply them.

name: web-server
description: Standard web server profile
config:
  limits.cpu: "2"
  limits.memory: 2GB
  boot.autostart: "true"
devices:
  eth0:
    name: eth0
    network: incusbr0
    type: nic
  root:
    path: /
    pool: default
    size: 20GB
    type: disk

Create and apply:

incus profile create web-server
incus profile edit web-server  # paste the YAML
incus launch ubuntu:24.04 nginx01 --profile web-server

Multiple profiles stack. You could have a base profile with networking, a gpu profile that passes through your GPU, and apply both:

incus launch ubuntu:24.04 ml-workload --profile base --profile gpu

This is the kind of thing that makes Incus genuinely better than “just run Docker” for stateful, persistent workloads. Your infrastructure is described in reusable config, not a wall of docker run flags.

Projects: Multi-Tenant Isolation

Projects in Incus let you carve up a single host into isolated namespaces. Each project has its own instances, profiles, images, and networks. It’s not full security isolation (you’d want VMs for that), but it’s excellent for organizing workloads or giving multiple users their own space:

incus project create dev-env --config features.images=true
incus project switch dev-env
incus launch ubuntu:24.04 test-instance

Listing across projects:

incus list --all-projects

For a homelab with multiple services, projects let you keep “media stack” separate from “networking tools” separate from “experiments that might eat the disk.” Organizationally, it’s worth using from day one.

Storage and Clustering

Incus supports ZFS, BTRFS, LVM, and Ceph for storage pools. ZFS is the goto for single-node setups — instant snapshots, copy-on-write clones, compression. BTRFS is fine if ZFS isn’t available. Ceph is there for multi-node shared storage if you’re running a cluster.

Adding a remote (clustering / multi-host access):

# On the remote machine, first expose the API
incus config set core.https_address :8443

# On your local machine
incus remote add homelab 192.168.1.100:8443
incus launch ubuntu:24.04 mybox --target homelab

Incus clustering for HA is more involved (3-node minimum recommended), but for most homelabs “remote add” to access a second machine is enough. You get a unified CLI across multiple hosts without standing up a full cluster.

Auth in 2026: OIDC + OpenFGA RBAC

This is where Incus has diverged meaningfully from LXD. The upstream added proper OIDC authentication and OpenFGA-based RBAC. In practice:

• You can front Incus with your existing SSO (Authentik, Keycloak, etc.)
• Fine-grained access control: user A can launch containers but not delete them, user B has admin on project X only
• Works with the REST API, which means infrastructure-as-code tools can use proper scoped tokens

For a solo homelab this is overkill. For a shared server where you want to give teammates access without handing out root: this is exactly what you need, and it’s built-in rather than bolted on.

Incus vs Docker: When to Use Which

Honest answer: they solve different problems.

Pick Incus when:

• You need a persistent, stateful environment — a dev box you SSH into, a mail server, a database server. System containers boot fast, run for weeks, and behave like a real Linux box.
• Multiple users share one host and need isolated environments. Incus projects + RBAC handles this cleanly.
• You want full VMs without standing up a full hypervisor stack. incus launch --vm is significantly less ceremony than installing Proxmox or bare QEMU.
• Your workload isn’t containerized and you’re not going to dockerize it. Legacy app that expects systemd? System container.

Pick Docker when:

• You’re running stateless application workloads and want the ecosystem. The image registry, Compose files, the tooling — Docker’s ecosystem is enormous.
• Your team already has Docker-based CI/CD. Don’t fight the tide.
• You want orchestration via Swarm or Kubernetes. Incus doesn’t play in that space.

There’s also no law against using both. Run your Docker daemon inside an Incus container. People do this. It’s fine. Your future self might have some questions at 2 AM, but it works.

Incus vs Proxmox: Two Different Philosophies

Proxmox is GUI-first. Click through a web UI, configure VMs visually, manage storage through a panel. It’s great for someone who wants visibility without memorizing CLI flags. It also bundles Ceph, HA clustering, backup tools — a whole platform.

Incus is CLI/API-first. You write profiles, automate with the REST API, integrate into your existing tooling. There’s no built-in GUI (though third-party options exist). The daemon is small — incusd is not running a web app, a Ceph stack, and a cluster manager by default.

Pick Incus when:

• You want a minimal footprint. Incus on a 2GB RAM node is fine. Proxmox wants more room.
• You’re automating. Incus has a clean REST API and a Python/Go SDK. Terraform provider exists.
• You’re already comfortable in the terminal and don’t need the visual layer.
• You’re on Debian/Fedora and don’t want to boot into Proxmox’s custom kernel.

Pick Proxmox when:

• You want the full platform — HA, backup manager, Ceph, the GUI — without assembling it yourself.
• You manage hardware for non-technical users who need a UI.
• You’re running a homelab specifically to learn enterprise virtualization patterns.

Proxmox is a product. Incus is a tool. Neither is wrong; it depends on what you’re building around it.

The Fork, Two Years Later

The Incus project has been healthy. Debian ships it in stable. Fedora ships it. OpenSUSE supports both Incus and LXD. NixOS has a module. The Linux Containers project owns the codebase and the infrastructure.

LXD hasn’t stood still either — Canonical has continued development. But it’s a Canonical product now, shipped through Snap, best supported on Ubuntu. If you’re on Ubuntu and happy there, LXD works. If you’re on anything else, or you want to avoid Snap, or you have opinions about how open source should work: Incus is the fork that kept the original promise.

Graber’s bet was that the community would follow the maintainers, not the corporate trademark. Two years in, that bet looks right. The distro packaging is proof enough.

If you’re starting fresh today and you’re not specifically on Ubuntu-as-a-platform: install Incus, don’t look back.

Quick Reference

# Launch container / VM
incus launch ubuntu:24.04 mybox
incus launch ubuntu:24.04 myvm --vm

# Shell access
incus exec mybox -- bash

# List instances
incus list

# Snapshot and restore
incus snapshot mybox snap0
incus restore mybox snap0

# Copy instance
incus copy mybox mybox-clone

# Profile management
incus profile list
incus profile show default

# Remote access
incus remote add remote-host 192.168.1.100:8443
incus list remote-host:

# Stop / delete
incus stop mybox
incus delete mybox

The CLI is clean, the concepts are consistent between containers and VMs, and the fork is mature. If LXD was on your radar before the 2023 drama, Incus is where that project actually went.

Related Reading

• crun vs runc vs youki: OCI Runtimes Compared
• Understanding Docker vs. Full Virtual Machines (VMs)
• A Guide to LXC/LXD
• Access Docker socket via TCP
• cgroups v2 in Practice: Limits, Pressure, Containers