Incus in 2026: an adoption / migration note on LXD cutover, system containers, and where VM convenience turns back into platform work

A NOIRLab data-center photograph fits this article because Incus is strongest when it is treated as real host infrastructure for full Linux systems, not as a decorative container brand.[8]

Incus is easiest to judge when you stop treating it as a generic container alternative and start treating it as a cutover decision for a very specific class of infrastructure. The official docs are direct: Incus is a system container and virtual machine manager for running full Linux systems, with one control surface that spans containers, VMs, images, clustering, and a REST API.[1] That is already a narrower category than most teams mean when they say "containers." It is also what makes the project useful.

That narrower category is the key to the migration question. If your current LXD estate really is a Linux host fleet for full-system workloads, Incus offers an unusually clean path: install the current stable release, avoid initializing it, make sure both incus info and lxc info work, then use lxd-to-incus to transfer the full database and storage into an identical setup.[4] If, however, you were using LXD as a catch-all for broader platform assumptions such as package provenance, remote-client habits, or VM extras that no one had written down, the migration gets harder for reasons that have little to do with the tool name itself.[3][4]

Image context: the cover uses a real NOIRLab data-center photograph rather than a logo or terminal screenshot. That is the right visual here because Incus is not really about container aesthetics. It is about turning one Linux host or a small cluster into an operational home for full systems.[8]

1. First, read the product boundary correctly

Incus sits in a different place from Docker-style application containers, and the docs say so without much ambiguity. Application containers package a single process or application, while system containers simulate a full operating system with libraries, services, databases, and user space intact.[2] Incus also supports virtual machines, and the distinction there is equally concrete: system containers share the host kernel and gain speed and smaller footprint from that fact, while virtual machines use hardware isolation and can run a different operating system from the host.[2]

That matters because a lot of bad migration analysis begins with category error. Teams compare Incus to app-container tooling or to higher-level cluster systems and then wonder why the decision feels fuzzy. The useful comparison is narrower. Incus is attractive when you want a Linux host to run many isolated full-system environments with one consistent surface for lifecycle, images, networking, and storage.[1][2]

This is also the first honest boundary condition. If your operational goal is primarily single-process application packaging, Kubernetes-style deployment orchestration, or abstracting the host until it mostly disappears, you are already outside Incus's strongest lane. The docs point in the opposite direction: host-visible infrastructure, full Linux systems, and a choice between containers and VMs according to kernel compatibility and isolation needs.[1][2]

2. Where the cutover is genuinely smooth

The strongest Incus adoption argument is not philosophical. It is procedural. The migration guide says the lxd-to-incus tool converts an existing LXD installation into an Incus one, transfers the entire database and all storage, and leaves you with an identical setup after migration.[4] That is a much stronger promise than "there is a migration path." It means the project is explicitly designed to inherit an existing LXD estate instead of forcing a rebuild from first principles.[4]

That promise is especially valuable in the kinds of environments where LXD was already a pragmatic fit: lab hosts, internal service boxes, bare-metal development systems, edge nodes, and small virtualization estates where one team manages both containers and a few VMs on ordinary Linux machines. Incus's own product description reinforces that fit. The platform scales from a single machine to a cluster in a full data-center rack, but the control model is still one coherent manager for full Linux systems rather than a pile of separate tools.[1]

So the migration is genuinely smooth when three conditions are true:

The source estate already matches Incus's product boundary: full Linux systems, not app-container orchestration.[1][2]
The cutover can happen on the same machine with planned downtime.[4]
The team wants continuity more than reinvention: keep the instances, keep the storage, keep the host role, switch the manager.[4]

When those conditions hold, Incus is less a redesign than a control-plane substitution.

3. What the migration tool does not clean up for you

The parts the docs do not hide are exactly the parts an operator should pay attention to. After migration, users who were in the lxd group must be moved into the equivalent incus-admin group, and they may need to log out and back in before that change takes effect.[4] The migration also does not carry over command-line client configuration. If you had remote definitions, aliases, or other client-side state in ~/.config/lxc/ or the snap-specific LXD config path, you may need to move that content into ~/.config/incus/ yourself.[4]

That sounds small until you remember where hidden operational debt likes to live. It lives in shell history, in remote aliases, in local client state, and in the assumptions a senior admin forgot to document two years ago. The lxd-to-incus tool is strong on server-side continuity; it is not a complete cleanup crew for human workflow drift.[4]

The other hard boundary is downtime. The docs say plainly that once the migration process is started, it cannot easily be reversed, so you should plan adequate downtime.[4] That single sentence does a lot of work. It tells you this is a controlled cutover, not a toy trial. If your environment cannot tolerate a real maintenance window, the technical elegance of the tool does not change the rollout shape.

4. Packaging and VM support are where convenience turns back into platform work

The installation guide is broader than many people expect. Incus packages are available through distribution repositories in some places and through the Zabbly repository in others, with Ubuntu LTS and Debian users explicitly pointed to up-to-date supported packages there.[3] The same guide also makes the VM boundary explicit: running virtual machines often requires extra firmware or VM-specific packages such as EDK2 or distribution-specific VM bundles.[3]

This is the point where a simple LXD-to-Incus narrative becomes a real operations decision. If your hosts live on well-supported Linux distributions and your package policy already accepts distro or Zabbly channels, the install surface is straightforward.[3] If your estate depends on special packaging rules, locked-down internal mirrors, or VM features that nobody has tested on the target distro, then you are no longer evaluating a name change. You are evaluating whether your host contract still holds under a different package lane.[3][7]

The same principle applies to access control. Incus expects an incus-admin group for non-root interaction with the local daemon.[3] That is not exotic, but it is one more reminder that the project wants to live inside normal Linux administration. Teams that like explicit host contracts will usually see that as a strength. Teams that only want a barely-visible virtualization substrate may experience the same clarity as friction.

5. Why the project matters now

The external context still matters because Incus is not just a technical fork sitting in a quiet corner. LWN's August 7, 2023 introduction described Incus as a fork of LXD 5.16 created after Canonical removed LXD from Linux Containers, with the explicit goal of providing a fully community-led alternative and correcting mistakes that could not be fixed without breaking backward compatibility.[7] That origin story explains why the project feels so continuity-aware. It was built to inherit a known operational shape while changing the governance home.

The current maintenance signal suggests that this is not a dormant fork trading on old sentiment. As of 2026-03-29T21:05:36Z UTC, the GitHub API reports 5,100 stars, 425 forks, 77 open issues, and a most recent push at 2026-03-29T18:43:32Z for lxc/incus.[5] The latest stable release listed on GitHub is v6.23.0, published on 2026-03-27.[6] Those numbers do not settle adoption by themselves, but they do show a project that is active enough to treat as a live platform choice rather than a museum branch.[5][6]

6. A rollout shape that gives you a real answer

The right first migration is deliberately boring:

Pick one non-critical LXD host whose workloads clearly fit Incus's full-system model.[2][4]
Confirm the target packaging story first, including any VM dependencies your distro needs.[3]
Install the latest stable Incus release, do not initialize it, verify both incus info and lxc info, then run lxd-to-incus during a scheduled window.[4]
Immediately check the human layer after the cutover: incus-admin membership, remote definitions, aliases, and any automation that still points at old client config paths.[3][4]

That sequence will tell you almost everything important. If the pilot works, Incus is probably a clean fit. If the pilot stalls on package policy, undocumented client state, or VM dependencies, the blocker is not mystery. The blocker is that your LXD estate had more platform assumptions embedded in it than the team realized.

Bottom line

Incus is a good migration target when you keep the decision narrow. It manages full Linux systems as system containers or virtual machines, not app containers, and it is strongest when that is exactly what your estate already needs.[1][2] In that setting, the lxd-to-incus workflow is unusually strong because it preserves database and storage state instead of asking for a rebuild.[4]

The real migration edge lies elsewhere: downtime, package-source choices, VM prerequisites, and the hidden client-side habits that survive outside the server database.[3][4] If those edges are acceptable, Incus looks less like a risky fork and more like a practical continuity move with a different governance center.[5][6][7]

cronfeed.work