If you manage servers or build test environments, you already know that spinning up isolated systems fast matters a lot. Incus gives you that speed without the bloat of a full hypervisor stack. This guide walks you through how to install Incus on Ubuntu 26.04, step by step, so you can run both containers and virtual machines from one clean toolset.

Ubuntu 26.04 LTS ships with long-term support, which makes it a solid base for a container platform you plan to keep running for years. Incus itself recently reached its 7.0 LTS milestone, giving admins a stable branch built for production use. Whether you are a beginner testing your first container or a sysadmin rolling this out on a fleet of servers, this Linux server tutorial covers everything from prerequisites to troubleshooting.

By the end, you will have Incus running, initialized, and ready to launch your first container. You will also understand why each step matters, not just the commands to type. That distinction matters because containers and VMs touch storage, networking, and permissions all at once, and skipping the reasoning behind a step is how small mistakes turn into hard-to-diagnose problems later.

What Is Incus and Why It Matters

Incus is a system container and virtual machine manager built by the Linux Containers project. It grew out of LXD after Canonical stepped back from community-driven development, and it now runs both lightweight containers and full QEMU-based virtual machines from the same command-line tool.

Think of a container as a slim, isolated copy of an operating system that shares the host kernel. A virtual machine, by contrast, boots its own kernel and behaves like a completely separate computer. Incus lets you manage both types side by side, using the same storage pools, the same network bridge, and the same set of commands.

This matters for a few practical reasons:

• Speed. Containers start in seconds, not minutes.
• Resource efficiency. A container might use 20 MB of RAM, while a full VM needs hundreds.
• Flexibility. You get containers for fast, lightweight isolation and VMs when you need a separate kernel or stronger isolation.
• One tool, one workflow. No juggling separate platforms for containers and virtualization.

For homelabs, small hosting setups, and internal dev environments, this combination hits a sweet spot between Docker’s simplicity and a full hypervisor’s overhead.

Prerequisites Before You Start

Before diving into the install, make sure your system checks these boxes. Skipping any of these often leads to confusing errors halfway through setup.

• Operating system: Ubuntu 26.04 LTS (Resolute), fresh or close to fresh.
• Access level: Root or sudo privileges on the host.
• Memory: At least 2 GB of RAM for the host system itself.
• Disk space: A minimum of 10 GB free space, since the default storage backend writes to /var/lib/incus.
• Network access: Outbound HTTPS access to reach the package repository and the public image server.
• CPU virtualization support: Required only if you plan to run virtual machines, not just containers.

You can check whether your CPU supports hardware virtualization with this command:

grep -oE '(vmx|svm)' /proc/cpuinfo | sort -u

If this returns vmx (Intel) or svm (AMD), your CPU can run VMs through Incus. If it returns nothing, containers will still work fine, but launching a VM will fail unless you enable virtualization support in your BIOS or, if you are on a virtual host, in the hypervisor settings.

Step 1: Update Your System

Before installing any new software, refresh your package index. This makes sure Ubuntu knows about the latest available packages and avoids version conflicts during install.

sudo apt update
sudo apt upgrade -y

Why this step matters

Skipping updates before adding a new repository is a common mistake. An outdated package cache can cause dependency errors or pull in mismatched library versions when you install Incus later. A clean, updated base system also reduces the chance of hitting unrelated bugs that were already fixed upstream.

Step 2: Choose Your Installation Method

Ubuntu 26.04 gives you two solid paths to install Incus on Ubuntu 26.04 setup: the native Ubuntu package, or the Zabbly repository. Both work, but they behave differently.

The native package is already sitting in Ubuntu’s archive for 26.04, so apt install incus works out of the box. Zabbly, maintained by the Incus project lead, tracks the newest stable release more closely and adds extra tooling like the web dashboard.

Why the choice matters

If your organization has strict policies about using only Ubuntu-signed packages, the native path keeps you compliant. If you want the newest features, better backup performance, and the built-in web interface, Zabbly is worth the extra setup steps. This guide covers the Zabbly method in detail since it gives you the most complete experience, then shows the native alternative as a shortcut.

Step 3: Install Incus Using the Zabbly Repository

This is the recommended path for most readers who want the full Incus on Ubuntu 26.04 setup experience, including the web UI and the latest LTS branch.

Add the signing key

First, install a few tools you need for downloading and verifying the repository key, then create a dedicated folder for trusted keys.

sudo apt install -y curl gpg ca-certificates
sudo mkdir -p /etc/apt/keyrings

Download the Zabbly signing key into that folder:

sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc

Why key verification matters

Anyone can create a fake repository and try to trick your system into installing malicious packages. A signed key confirms the packages actually come from Zabbly and have not been tampered with in transit. Storing it in /etc/apt/keyrings also follows the modern Debian and Ubuntu convention, which scopes trust to a specific repository instead of your entire system.

Register the repository

Create a source file that tells apt where to find Incus packages, using your system’s exact codename automatically:

sudo sh -c 'cat > /etc/apt/sources.list.d/zabbly-incus-stable.sources <<EOF
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'

Why this format matters

Using shell expansion for the codename and architecture keeps this file accurate no matter which machine you run it on. Hardcoding a codename like “resolute” directly would break if you ever copy this script to a different Ubuntu release. This small detail saves you from a repository mismatch that could silently install the wrong package version.

Now refresh apt so it picks up the new repository:

sudo apt update

You should see a line confirming a fetch from pkgs.zabbly.com. If that line is missing, double check the source file syntax before moving forward.

Step 4: Install the Incus Packages

With the repository in place, install Incus along with the extras that give you the web UI and virtual machine support.

sudo apt install -y incus incus-ui-canonical incus-extra qemu-system

Here is what each package actually does:

• incus: The core daemon and command-line client.
• incus-ui-canonical: The official web dashboard for managing instances visually.
• incus-extra: Extra tooling, including the migration tool for moving data from LXD.
• qemu-system: The virtualization backend needed to launch full VMs, not just containers.

Why installing the extras matters

You could install just incus and skip the rest, but then VM launches will fail with a missing dependency error, and you will have no visual way to manage instances beyond the terminal. Installing everything up front avoids a second round of troubleshooting later when you decide you actually do want a VM or a dashboard view.

Confirm the install worked and check the version:

incus version
systemctl status incus.service --no-pager

Expected output should show the service as active (running) with incusd listed as the main process. If the version reports 7.x, you are running the current LTS branch through Zabbly rather than the older archive package.

Step 5: Configure User Access

By default, only the root user can talk to the Incus daemon. Add your regular user account to the admin group so you do not need sudo for every command.

sudo usermod -aG incus-admin $USER
newgrp incus-admin

Why group-based access matters

Incus treats local socket access as full control over the daemon, meaning anyone in this group can attach any file path or device to any instance. That is powerful, so only add accounts you actually trust with near-root access. The newgrp command refreshes your current shell session so the new group applies immediately, instead of forcing you to log out and back in.

Step 6: Initialize Incus

Installing the packages only gets the software on disk. You still need to set up storage and networking before you can launch anything.

sudo incus admin init --minimal

The --minimal flag picks sensible defaults automatically: a directory-based storage pool, a managed network bridge named incusbr0, and a default profile that connects every new instance to both.

Why initialization matters

Skipping this step, or getting it wrong, is one of the most common reasons new Incus installs fail to launch containers. Storage choice affects performance and how snapshots behave later. Networking choice determines whether your containers can reach the internet and whether other devices on your LAN can reach them. Getting these basics right the first time saves you from painful reconfiguration once you already have running workloads.

If you want more control over storage backend, clustering, or remote API access, drop the flag and run the interactive wizard instead:

sudo incus admin init

This walks you through storage driver choice (dir, btrfs, zfs, or lvm), bridge naming, and whether to expose the HTTPS API on your network.

Verify that the default resources came up correctly:

incus storage list
incus network list

You should see one storage pool named default and one network bridge named incusbr0 listed with an active status.

Step 7: Launch Your First Container

Time to prove the whole setup actually works. Launch a small Ubuntu container using the public image server:

incus launch images:ubuntu/24.04 web1

The first launch takes a little longer because it downloads and caches the image. Every launch after that from the same image is nearly instant.

Check that it is running:

incus list

Expected output shows a table with the container name, state, and an assigned IPv4 address from the bridge network. Drop into a shell inside the container to confirm everything is fully functional:

incus exec web1 -- bash

Why testing with a real container matters

A test launch validates four things at once: image downloads work, storage is writable, networking assigns an address correctly, and your user permissions are set up properly. If any one of those pieces is broken, this is where you will see it, rather than discovering it later during a real deployment.

Alternative: Install From the Native Ubuntu Package

If you cannot reach outside repositories, or your organization requires sticking to Ubuntu-signed packages only, the native path is simpler but ships an older LTS branch.

sudo apt update
sudo apt install -y incus incus-tools qemu-system
incus version
sudo incus admin init --minimal

This installs the 6.0 LTS branch rather than 7.0, and it does not include the web UI package. Everything else, including initialization and container launches, works the same way. Pick this route only when policy or network restrictions rule out the Zabbly repository.

Troubleshooting Common Issues

Even a clean install occasionally hits a snag. Here are the most common problems and how to fix them.

• “incus: command not found” right after installing. Your current shell session may still have the old PATH cached. Open a new terminal window, or run hash -r, then try incus version again.
• “Permission denied” when running Incus commands. This almost always means your user account is not yet in the incus-admin group, or the group change has not taken effect in your current session. Run id to confirm group membership, and start a fresh shell if incus-admin is missing from the list.
• Repository key or signature errors during apt update. Double check that the key file downloaded correctly to /etc/apt/keyrings/zabbly.asc and that the source file references the exact same path under Signed-By. A typo in the file path is the most common cause of this error.
• “incus launch –vm” fails with a KVM-related error. Your CPU either lacks hardware virtualization support, or it is disabled in BIOS. If you are running inside a virtual machine yourself, nested virtualization needs to be turned on at the hypervisor level.
• The bridge network has no IPv4 address assigned. Another service on the host may already be using the address range Incus tried to claim. Check current addresses with ip -br a, then reassign the bridge manually if there is a conflict.