Daily Post July 23 2026

Migrating from LXD to Incus

For years, containerization on Linux was dominated by two primary paradigms. On one side stood application container engines like Docker and Podman, designed to package isolated, single-process microservices. On the other side stood system container technologies, which provide lightweight virtual environments that behave, look, and feel like full-blown Linux operating systems without the performance overhead of full hardware virtualization. At the center of this system container realm was LXD. However, significant governance shifts, licensing changes, and strategic corporate decisions have changed that cuased the fork to Incus as the new standard bearer for open-source system containers and lightweight virtual machines. Understanding this evolution, why the ecosystem split, and how to execute a migration is important for sysadmins, DevOps engineers, and infrastructure architects.

Understanding LXD

To understand the current state of system container management, you must first look at LXD. Originally launched under the umbrella of the Linux Containers project with primary sponsorship from Canonical, LXD was built as a REST API-driven daemon built on top of LXC (Linux Containers). Bare LXC provided low-level primitives for interacting with kernel namespaces, cgroups, and capabilities, LXD brought a polished, user-friendly interface to manage container lifecycles, storage pools, networks, and cluster deployments.

LXD filled a niche between traditional hypervisors like KVM or VMware and application containers like Docker. It allowed users to run entire Linux distributions complete with init systems like systemd, SSH daemons, package managers, and cron jobs inside isolated kernel containers that booted in seconds and consumed minimal memory. Later versions of LXD even expanded to manage full QEMU-based virtual machines through the exact same unified REST API and command-line interface, giving operators a single tool to manage both light containers and heavy virtual machines.

Enter Incus

Incus is a fully open-source, community-driven daemon designed to manage system containers and virtual machines. Created in mid-2023 under the Linux Containers project umbrella, Incus is a direct fork of LXD. It retains the underlying architectural strengths that made LXD popular while steering the project back toward community-led development, open governance, and traditional open-source software licensing.

The project was spearheaded by Aleksa Sarai and longtime LXD lead developer Stéphane Graber, along with other core contributors from the original project. Incus aims to provide a reliable, flexible platform for running containers and virtual machines across diverse deployment environments, ranging from single-node homelabs to multi-node enterprise production clusters. Maintaining familiar operational paradigms, Incus has diverged from LXD by removing legacy tech debt, improving security defaults, introducing native support for OCI container images, and expanding integration with identity providers like OpenFGA and OpenID Connect.

The Rift

The split between LXD and Incus was not caused by technical disagreements over software architecture, but rather by fundamental shifts in corporate strategy and project governance. In July 2023, Canonical made the sudden corporate decision to take direct control of the LXD project. Prior to this decision, LXD had operated as a community project under the Linux Containers umbrella, even though Canonical was its primary funder and employed most of its core maintainers. Canonical moved the LXD codebase out of the Linux Containers repository, relocated discussion forums to Canonical platforms, and required contributors to sign a Canonical Contributor License Agreement.

Canonical's strategic rationale stemmed from a desire to integrate LXD into its commercial product portfolio, particularly Ubuntu Server, MicroCloud, and enterprise support offerings. Canonical sought to unify its container story under corporate governance to streamline enterprise packaging, commercial SLA delivery, and product roadmaps.

However, the friction intensified a few months later when Canonical relicensed the entire LXD codebase from the permissive Apache 2.0 license to the Copyleft AGPLv3 (Affero General Public License). This licensing shift created substantial hurdles for third-party integrators, cloud providers, and open-source projects that embedded LXD into their platforms without wishing to adopt AGPL restrictions. Furthermore, Canonical restricted access to the public images.linuxcontainers.org image server for LXD clients, effectively cutting non-Incus users off from community-maintained distribution images. In response, the core maintainers, led by Stéphane Graber, created Incus as a permanent fork, retaining the original Apache 2.0 license and preserving independent governance within the Linux Containers project.

The Future of the Incus Project

The future of Incus is defined by community-centric innovation and neutral open-source governance. Unlike LXD, which is now tied to Canonical's commercial ecosystem and Ubuntu-centric deployment models, Incus is distribution-agnostic. It receives first-class packaging across major Linux distributions, including Debian, Fedora, Arch Linux, Alpine, and Ubuntu via independent repositories.

Incus is moving forward with several roadmap priorities. First, it is enhancing support for running OCI container images directly alongside system containers, bridging the gap between application container runtimes and system container managers. Second, Incus is pushing forward with enterprise identity and access management features, integrating fine-grained role-based access controls via OpenFGA. Third, the project is introducing live hot-plugging features for shared storage paths and devices in virtual machines, along with deeper integration for advanced networking stacks like OVN and BGP. Because Incus remains licensed under Apache 2.0, downstream developers and software vendors can freely build commercial and open-source infrastructure services on top of Incus without licensing friction.

Why You Should Migrate from LXD to Incus

For administrators currently running LXD, staying on Canonical's stack presents growing long-term operational risks and limitations. The primary reason to switch is long-term sustainability and access to the broader open-source ecosystem. Canonical's decision to block LXD clients from accessing the official Linux Containers image repository means LXD users must rely solely on Canonical's image infrastructure or build custom image delivery pipelines. In contrast, Incus natively retains access to the complete library of community-built Linux distribution images.

Another reason is developer momentum. The original core maintainers and primary community contributors moved their focus entirely to Incus. As a result, new feature development, performance optimization, and bug fixes are happening primarily within the Incus codebase. Additionally, Incus avoids forcing users into Canonical's Snap package ecosystem, allowing operators to run natively packaged binaries from distribution repositories or custom build pipelines, which improves system stability, startup performance, and backup flexibility.

Preparation and Prerequisites

Before performing a migration, proper preparation is necessary to ensure zero data loss. The migration process is designed as an in-place conversion using an official tool named lxd-to-incus, which inspects existing LXD storage, networks, profiles, and instances, and converts them directly into Incus resources.

To prepare your system, you should first audit your current LXD setup. Take complete inventory of running containers, virtual machines, storage pools (such as ZFS, Btrfs, or LVM), custom network bridges, and configuration profiles. Ensure that your host operating system is fully updated and that your LXD daemon is running a compatible version. It is important to create off-site backups or storage-level snapshots of all essential container data prior to starting the automated migration script.

You must also install the Incus daemon packages on your host system before running the migration. When installing Incus, it is important that you do not run the initial setup command (incus admin init), because the automated migration utility expects a fresh, uninitialized Incus installation so that it can populate the database with your existing LXD configurations.

Migration Process with lxd-to-incus

The migration process is streamlined thanks to the lxd-to-incus utility provided by the Incus team. The first step in the execution phase is to install the migration package on your system, which is typically distributed alongside Incus tools. Once installed, you execute the lxd-to-incus command with root privileges.

When launched, the migration tool performs a thorough dry-run validation check. It connects to both the running LXD daemon and the installed Incus service to compare API versions, inspect database schemas, verify storage drivers, and check network configurations. If any incompatibilities are detected—such as unsupported custom profile keys or version mismatches the tool halts before making any destructive changes and provides feedback on what must be resolved.

Once validation succeeds, the script asks for confirmation to proceed. Upon confirmation, the migration tool systematically stops all active LXD containers and virtual machines to prevent data corruption. It then migrates database records, updates mount paths for storage pools, transfers network bridge definitions, and updates configuration profiles. After data structures are moved, the tool rewrites paths from the old LXD directory structures to the new Incus locations under /var/lib/incus. Finally, the tool shuts down the LXD daemon service, starts the Incus service, and offers to automatically uninstall or purge the old LXD package from your host system.

Post-Migration Verification and Adapting to the Incus Ecosystem

Once the migration tool completes its work, you must verify the operational status of your migrated environment. The fundamental shift for command-line interaction is transitioning from the lxc CLI command to the incus CLI tool. System administrators should test instance management by querying instance listings, checking storage pool statuses, and verifying network interfaces.

You should start your migrated instances and execute internal health checks to verify that services, IP address assignments, DNS resolution, and mounted storage volumes are functioning properly. If your host user accounts need administration privileges, make sure to add them to the incus-admin system group instead of the legacy lxdgroup.

It is also important to update any existing automation scripts, CI/CD pipelines, Ansible playbooks, or Terraform providers that previously referenced LXD REST API endpoints or socket locations. Incus listens on its own dedicated UNIX socket at /var/lib/incus/unix.socket and uses updated environment variables. Ipdating these automation hooks to point to Incus, your infrastructure management pipeline will be aligned with the active, community-driven future of system containerization.