Incus review: community-led container and VM manager born from the LXD fork

What Incus is and where it came from

Incus manages system containers and virtual machines through a single REST API, positioning itself between lightweight application containers like Docker and full hypervisors like Proxmox. System containers run complete Linux distributions with init systems and multiple users, sharing the host kernel for efficiency while maintaining isolation. Virtual machines use QEMU and KVM to provide full hardware virtualization when a separate kernel is required.

The project originated in August 2023 as a community fork of Canonical's LXD after Canonical moved LXD development in-house and required contributor license agreements. The fork was created by Aleksa Sarai and adopted by the Linux Containers project, with most of the original LXD development team joining as maintainers. Incus is released under the Apache 2.0 license with no CLA requirement, and development occurs entirely in the open on GitHub.

Incus 6.0 LTS shipped with support through June 2029, followed by Incus 7.0 LTS in May 2026 with support extending to June 2031. Monthly feature releases provide new capabilities and bug fixes, though most production deployments stick to LTS versions for stability. The project ships in Debian, Fedora, Arch, OpenSUSE, NixOS, and other distributions without requiring proprietary packaging.

Core capabilities and technical approach

Incus supports three workload types through a unified interface. System containers provide full Linux environments with persistent identity, init systems, and package management while sharing the host kernel. Application containers run OCI images compatible with Docker registries, added in version 6.3 and expanded in 7.0. Virtual machines use QEMU with UEFI firmware and virtio drivers for full OS isolation when kernel separation is required.

Storage flexibility includes ZFS, Btrfs, LVM thin provisioning, Ceph for distributed storage, and integrations with LINSTOR and TrueNAS. ZFS and Btrfs enable copy-on-write snapshots with minimal overhead, allowing instant container cloning and rollback. Clustering support scales from single machines to data-center deployments with live migration, automated failover, and distributed networking via OVN overlays.

The security model defaults to unprivileged containers that do not require root access on the host, reducing attack surface compared to privileged container configurations. Network capabilities include Linux bridges, VLANs, OVN overlay networks with ACLs, and routed networking. Authentication uses TLS certificates by default, with OIDC and OpenFGA-based role-based access control introduced in recent versions for multi-user environments.

Management interface and day-to-day experience

Incus provides a command-line client and REST API as its primary interfaces, with no official web UI included by default. The CLI uses consistent syntax across containers and VMs, with commands like incus launch to create instances and incus shell to access them. Users report that launching instances is extremely fast, with system containers starting in seconds and images downloading quickly from the Linux Containers image server.

A web interface option exists through incus-ui-canonical, a repackaged version of Canonical's LXD UI available from the Zabbly package repository. Installation requires manual steps including certificate generation and configuration file edits, particularly on distributions like Fedora and RHEL where the package is not in default repositories. Once configured, the web UI provides graphical management of instances, storage, networks, and profiles, though authentication via TLS client certificates adds setup complexity for new users.

Documentation quality is solid but assumes familiarity with Linux system administration and container concepts. Official guides cover installation, initialization, and common tasks, though troubleshooting often requires consulting community forums. The learning curve is steeper than Proxmox or VMware for users accustomed to integrated graphical interfaces, but experienced Linux administrators find the CLI workflow efficient once the initial concepts are understood.

Comparisons and positioning

Incus competes primarily with Proxmox VE in the open-source virtualization space, though the two take different approaches. Proxmox provides an integrated web interface, broader VM guest OS support, and features like backup integration with Proxmox Backup Server. Incus focuses on Linux workloads, offers native Btrfs support that Proxmox lacks, and provides official ARM64 support where Proxmox requires custom setups. Many homelab users run both, using Proxmox as the hypervisor with Incus inside a VM for lightweight container workloads.

Against Docker and similar application container platforms, Incus targets a different use case. System containers behave like lightweight VMs with full init systems, making them suitable for persistent development environments, testing infrastructure configurations, and running services that expect a complete operating system. Docker focuses on single-process application containers with ephemeral state. Recent OCI container support in Incus allows it to run Docker-style workloads, though Docker Compose remains more mature for multi-container application stacks.

The fork from LXD means users must choose between Canonical's version and the community alternative. LXD ships exclusively via Snap on Ubuntu and requires Canonical's CLA for contributions. Incus ships in native distribution packages across multiple Linux families and operates without licensing agreements. Migration from LXD to Incus is supported through the lxd-to-incus tool for versions up to LXD 5.16, though later LXD releases have diverged too far for automated migration.

Longevity and vendor considerations

The Linux Containers project governs Incus as a community effort alongside LXC and LXCFS, with no single vendor controlling development direction. The maintainer team includes most of the original LXD developers who built the technology over eight years before the Canonical split. Development velocity has been strong since the 2023 fork, with regular monthly releases and two LTS versions shipped within three years.

Commercial support is available from Zabbly, founded by former LXD lead developer Stéphane Graber, for users running Zabbly's Debian or Ubuntu packages. This provides a support option for organizations that require vendor backing, though the community forum at discuss.linuxcontainers.org handles most user questions. The project's presence in major distribution repositories reduces dependency on any single provider for package availability.

Long-term viability appears solid given the established maintainer base and adoption by distributions including Debian stable, Fedora, and OpenSUSE. The Apache 2.0 license with no CLA requirement means the codebase cannot be relicensed or taken private. However, the smaller ecosystem compared to mature hypervisors and the relatively recent fork mean organizations should verify that community support and third-party tooling meet their operational requirements before committing to production deployments.