Install on Debian / Ubuntu

sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo tee /etc/apt/sources.list.d/zabbly-incus-stable.sources <<'EOF'
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: bookworm
Components: main
Architectures: amd64 arm64
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF

sudo apt update
sudo apt install incus

# Add yourself to the incus-admin group
sudo usermod -aG incus-admin $USER
newgrp incus-admin

# Or via the official Incus repos on newer distros that ship it
sudo apt install incus               # bookworm-backports / trixie

Initialize

sudo incus admin init

Interactive prompts:

  • Local storage pool — ZFS recommended; pick a dedicated disk or a loopback file. The pool holds container/VM disks.
  • Network bridge — default incusbr0 with NAT, or attach to an existing bridge.
  • HTTPS API — optional; needed for remote admin / clustering.

Defaults are usually fine for a single host.

Launch a container

# Pick an image from the default remote
incus image list images:debian/12

# Launch by short name
incus launch images:debian/12 web

# Or launch and attach to it immediately
incus launch images:ubuntu/24.04 dev --type container
incus shell dev

# Inside dev: it's a real Debian/Ubuntu environment, sharing the host kernel
apt update
apt install ...
exit

System containers boot in <1 second and consume ~100 MB RAM at idle. They're not application containers (no Docker semantics); they run full OS userspace with their own systemd, SSH, multiple users.

Launch a VM

# Same syntax, --vm flag
incus launch images:debian/12 db --vm
incus launch images:ubuntu/24.04/cloud build-vm --vm \
    -c limits.cpu=4 \
    -c limits.memory=8GiB

# Console / SSH into it
incus console db --type vga       # graphical console
incus console db                  # serial console
incus shell db                    # exec a shell (requires guest agent)

VMs use QEMU/KVM under the hood; full kernel isolation; slightly heavier than containers but compatible with any OS that runs on KVM.

Storage

# List storage pools
incus storage list

# Add a new pool (e.g. on a separate disk with ZFS)
incus storage create fast zfs source=/dev/nvme1n1

# Create a volume + attach to an instance
incus storage volume create fast data --type filesystem
incus storage volume attach fast data dev /mnt/data

# Snapshots
incus snapshot create dev pre-upgrade
incus snapshot restore dev pre-upgrade
incus snapshot list dev

Per-volume snapshots if using ZFS / Btrfs (CoW filesystems with native snapshot support). For non-CoW pools (dir, lvm), snapshots are full copies — bigger and slower.

Networking

# List networks
incus network list

# Create a bridge that's bridged to the host's LAN (not NATted)
incus network create lan --type=bridge \
    parent=eth0 ipv4.address=none ipv6.address=none

# Attach a container to it
incus config device add web eth1 nic network=lan

For services that need to be reachable from the LAN at their own IP, this beats NAT-port-forwarding. For NAT-only patterns, the default incusbr0 works.

Profiles: reusable config bundles

# A profile that allocates 4 GB RAM + 2 CPUs + a specific network
incus profile create medium
incus profile set medium limits.memory=4GiB
incus profile set medium limits.cpu=2
incus profile device add medium eth0 nic network=lan

# Apply to instances at create time
incus launch images:debian/12 api -p default -p medium

Profiles compose; an instance can inherit from multiple. Useful for "all production workloads use this network + these limits" patterns.

Clustering across hosts

Run Incus on 3+ machines and join them into a cluster; instances can run anywhere in the cluster, live-migrate between nodes:

# On the first node
sudo incus admin init   # answer "yes" to "Would you like to use clustering?"

# On subsequent nodes
sudo incus admin init   # answer "yes" + "yes, joining an existing cluster" + paste the join token

Once clustered:

incus cluster list
# Shows all nodes + their status

# Launch on a specific node
incus launch images:debian/12 web --target=node-2

# Live-migrate
incus move db --target=node-3

For VMs, live migration requires shared storage (Ceph) or local-but-fast networking + memory pre-copy. For containers, it works against ZFS replication.

Cloud-init for VMs

# Per-instance user-data
incus launch images:ubuntu/24.04/cloud my-vm --vm \
    -c user.user-data="$(cat <<'EOF'
#cloud-config
users:
  - name: amir
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... amir@laptop
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
packages: [git, vim, htop]
package_update: true
EOF
)"

VM boots, cloud-init runs, ssh works immediately with the configured user. Same flow as cloud providers' cloud-init.

OCI / Docker image support

Incus 0.6+ can run OCI (Docker) images as system containers via the bundled oci-image driver. Useful for "just run this app container without Docker installed":

incus launch oci:docker.io/library/nginx:alpine web

The container behaves more like a single-process Docker container than a full system container; small subset of Incus features apply.

Incus vs alternatives

  • Proxmox VE (see that tutorial) — full hypervisor distro with web UI; bigger commitment, more polished UI.
  • LXD — Canonical's original; Incus is the fork after Canonical narrowed contributorship. Code is similar; Incus is community-controlled and more actively developed in 2026.
  • Docker / Podman — application containers; very different mental model (one process per container vs full distro userspace). Use both: Docker on top of Incus for application packaging, Incus for the underlying VM / container hosts.
  • libvirt / virt-manager — VMs only; older; great for one-off VM management; less polished for fleet operations.

Web UI

Incus ships an optional web UI (separate package): sudo apt install incus-ui-canonical on Ubuntu or build the upstream incus-ui. Browse to https://<host>:8443; same operations as the CLI, clickable.

What Incus isn't

  • Not Kubernetes. For container orchestration with scheduling, RBAC, service discovery, ingress — use Kubernetes. Incus is "VMs + system containers on hosts."
  • Not a public-cloud control plane. Single-fleet management; doesn't replace OpenStack at hyperscale.
  • Not a desktop tool. Server-oriented; for desktop VM management with GUI guests, virt-manager / GNOME Boxes is friendlier.

For "small fleet of VMs + system containers on Linux hosts I'm already running," Incus is the right size in 2026.