Moving from LXD and Proxmox to Incus

Incus provides a high-performance alternative for teams that want to manage system containers and virtual machines via a single REST API. I find the transition from Proxmox to Incus to be a logical step for administrators who need to escape the heavy footprint of KVM and the monolithic web UI of Proxmox. While Proxmox turns a standard Debian installation into a heavy-duty appliance, Incus installs as a package on almost any modern Linux distribution, including Ubuntu, Debian, Fedora, and Arch Linux. I would recommend the Zabbly repository if you need the latest LTS packages for Ubuntu or Debian, as it provides up to date support for versions like Ubuntu 26.04.

The following table compares the primary virtualization and management characteristics of both platforms.

Incus achieves near bare-metal performance because it relies on native kernel features like namespaces and cgroups. You can run tens or hundreds of containers on hardware where Proxmox might only host a dozen heavy KVM instances. However, the Incus CLI is the primary way to manage the system, and you must add your user to the incus-admin group to gain full control without using sudo. If you miss a graphical interface, you can install the incus-ui-canonical package, but the tool remains CLI-first by design.

Migrating existing workloads

Migrating from LXD to Incus is a direct process because Incus is a fork of LXD. The lxd-to-incustool handles the migration for LXD installations up to version 5.21.x. You should install an LTS version of Incus on your target machine to run this tool before upgrading to a newer feature release. This tool detects features removed from Incus, such as Ubuntu Fan networking or MAAS integration, to ensure the migration succeeds. Note that the lxd-to-incustool was removed from the Incus development branch in June 2026.

The migration process for Proxmox containers involves different steps. You must back up or export the container rootfs from Proxmox as a tarball, transfer that archive to the Incus host, and then use the incus image import command to ingest the rootfs. For virtual machines, the incus-migrate tool converts raw or qcow2 disk images into compatible virtual instances. If you used a ZFS storage pool in LXD, you must install the zfsutils-linux package on your new host to avoid errors during the transition.

I would avoid using the –auto flag during incus admin init if you plan to use ZFS or Btrfs for your storage pools. The –auto option defaults to the dir backend, which does not support snapshots or fast clones. You must choose your backend at initialization time because changing the backend later requires recreating the pool and migrating all instances.

Scaling with Incus clustering

Clustering allows you to group multiple servers into a single management plane. An Incus cluster requires at least three nodes to maintain a quorum through its distributed dqlite database. I recommend using three nodes because this setup allows the cluster to survive the loss of one member. You initialize the first node as a bootstrap node and then use a join token to add additional members.

Incus clustering provides several automated roles for cluster members.

• Database: Voting member of the distributed database
• Database-leader: Current leader of the distributed database
• Database-standby: Non-voting member of the distributed database
• Event-hub: Exchange point for internal Incus events

You can achieve live migration of containers between hosts by using shared storage like Ceph or NFS. If you use local storage, you can only perform cold migration by stopping the container. Does the dqlite database replication provide enough consistency for your specific network latency? You can set the cluster.offline_threshold to define how many seconds of non-responsiveness triggers an offline status, with a minimum setting of 10 seconds.