Zabbly's Incus package repository: signed apt builds across four channels

What the repository is: a packaging project, not a fork

The repository is described as Incus package builds provided by Zabbly, and its top level layout says what that means. There is a debian/ directory holding the packaging metadata, a deps/ directory, a patches/ directory, a systemd/ directory, an etc/ directory, a bin/ directory, an edk2-vars-generator/ directory, and a file called zabbly-sb.oem.crt, which is a self-signed certificate for the secure boot chain.

That last file is the giveaway that this is a real packaging project rather than a script. Signing the firmware variables for secure boot means the packages are built so that the Incus virtual machine images they carry will boot on a machine with secure boot enabled, and that requires a certificate of your own, generated by the edk2-vars-generator tooling and shipped alongside the build.

The repository is Apache-2.0 licensed and the default branch is daily, which tells you something about the workflow. The README says the repository gets actively rebased as new releases come out and warns not to expect a linear git history. That is a rebase-per-release packaging repo, which is the only sensible way to keep a set of patched build recipes aligned with several upstream release branches at once.

There are no GitHub releases, because the artifacts are Debian and Ubuntu packages distributed through apt rather than binaries attached to a tag. The last push was on 2026-10-17.

The maintainers are identifiable from the support section, which lists sponsorship links under the handle stgraber, the same handle behind the Incus project itself, along with a Ko-Fi and a Patreon.

The overall shape is worth stating plainly: this is the packaging half of the Incus story, and the runtime code lives upstream.

Four channels, and the difference between LTS and daily

Four repositories are available, and the names describe the trade-offs exactly.

lts-6.0 is Incus 6.0.x LTS, lts-7.0 is Incus 7.0.x LTS, stable is the latest release of Incus, and daily is untested daily builds. That last label is the important one, because it is stated as a property of the channel rather than as a caveat at the end of a paragraph. A daily channel rebuilt on every upstream commit is where you find regressions, and the naming makes that clear to anyone who has been burned by a daily channel before.

The two LTS channels exist because Incus supports two long term release lines at once. Being able to pin a site to 6.0 while another moves to 7.0, from the same repository, is the operational reason for keeping separate channels rather than a single stable feed.

The stable channel tracks the latest release, so it is a moving target in a different sense from daily. It changes when upstream cuts a release, which is a slow, predictable cadence, whereas daily changes continuously.

The support section draws a line between community and commercial support. Community support for Incus is provided on the Linux containers discussion forum, while commercial support for these particular packages is provided by Zabbly, with details on their site. That is a reasonable division for a third party packager: the community answers questions about Incus, and the vendor answers questions about the packages it built.

There is a second support path worth noting. The README points out that you can support the work on Incus and on these packages through GitHub Sponsors, Patreon and Ko-Fi, all under the same account, so funding flows to the upstream project as well as the packaging work.

Verifying the key before you trust the packages

The key verification section is the most careful part of the README, and it is worth following exactly rather than skipping to the repository add.

Packages provided by the repository are signed, so to verify their integrity you need to import the public key. The first step is to fetch the key and check its fingerprint, and the README gives both the curl and the wget form:

curl -fsSL https://pkgs.zabbly.com/key.asc | gpg --show-keys --fingerprint

wget -q -O - https://pkgs.zabbly.com/key.asc | gpg --show-keys --fingerprint

The expected output is given so you can compare rather than assume:

pub   rsa3072 2023-08-23 [SC] [expires: 2030-08-17]
      4EFC 5906 96CB 15B8 7C73  A3AD 82CC 8797 C838 DCFD
uid                      Zabbly Kernel Builds <[email protected]>
sub   rsa3072 2023-08-23 [E] [expires: 2030-08-17]

Two things are visible in that output that are worth pausing on. The key is an rsa3072 with a signing and encryption subkey, and the expiry date is 2030-08-17. The README also names the fingerprint in the prose, the same string split into groups, so you have something to compare against even before you run the command.

Then the key is saved into the standard apt keyring location. The directory has to exist first:

mkdir -p /etc/apt/keyrings/

and the key is written there with either tool:

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

wget -O /etc/apt/keyrings/zabbly.asc https://pkgs.zabbly.com/key.asc

All commands in the section are to be run as root, which is stated once at the top of the installation section rather than repeated.

The reason for the keyring directory and the specific key file name is that the sources files reference them by path, which the next section shows. That is what keeps the trusted key out of the deprecated global keyring and lets you remove the repository cleanly later by deleting two files.

The deb822 source files, and why the suite is computed

Each repository is added as a separate deb822 source file under /etc/apt/sources.list.d, and the files are written with a here-document. The 6.0 LTS file looks like this:

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

EOF'

The 7.0 LTS, stable and daily files are identical apart from the file name and the path in the URIs line, pointing at lts-7.0, stable and daily under the same host.

Two details in the file are worth understanding rather than copying blindly. The Suites line is computed at the time you run the command by sourcing /etc/os-release and echoing the codename, so the same file works on Ubuntu jammy, noble and resolute and on Debian bookworm and trixie without editing. The Architectures line does the same with dpkg, so an amd64 machine writes amd64 into the file and an arm64 machine writes arm64. The Signed-By line points at the key file you just installed, which is the mechanism that ties the trusted key to this specific source.

The deb822 format rather than the older one-line sources.list format is a deliberate choice, since it can express the architecture restriction, the per-suite settings and the key path in a single readable file, and modern apt treats it as the normal way to configure a third party repository.

After adding the source, the repository list is refreshed and the package installed:

apt-get update

apt-get install incus

And then there is the matter of the UI, which the README covers next.

The extra packages, the web UI, and the one caveat about distributions

The repository carries two packages beyond the main one, and the README explains the reasoning for both.

incus-client contains only the CLI tool and is described as useful when only managing remote servers. That is a real deployment pattern, where a workstation or a CI runner never hosts containers itself and only ever talks to an Incus server elsewhere, and shipping the client alone keeps the server packages out of that machine.

incus-ui-canonical is a rebranded version of the LXD web interface for use with Incus. Since it is a rebrand of the LXD UI, the README points you at the LXD documentation for the useful information about it, which is the honest answer for anyone who needs to know how the interface works.

Setting the UI up needs one extra step, because the interface has to reach Incus over the network. Incus has to listen on the network, which is done either by enabling it during incus admin init or by setting a listener with incus config set. The example given is:

incus config set core.https_address :8443

After that you reach the UI at https://localhost:8443, accept the self-signed certificate and follow the login instructions. The self-signed certificate is the visible reminder that Incus is serving its own API on a port it generated a certificate for, and the fact that the README tells you to accept it rather than to install a real certificate is the normal state for a self-hosted management interface.

The one distribution caveat is in the availability section, and it is a practical one. It is often possible to use those packages on other non-LTS Ubuntu releases by picking the closest LTS release prior to the Ubuntu version being run. So the supported set is Ubuntu 22.04 jammy, Ubuntu 24.04 noble, Ubuntu 26.04 resolute, Debian 12 bookworm and Debian 13 trixie, all built for amd64 and arm64, and a non-LTS Ubuntu release can be made to work by pointing at the nearest earlier LTS suite.

That last workaround is the kind of thing that works until an unrelated package pulls in a dependency only present in the newer suite, at which point the whole thing becomes a dependency pinning exercise. Sticking to a listed release is the sane default.

Editorial conclusion

Adopt the Zabbly Incus packages if you want a packaged Incus on a supported Ubuntu or Debian release without building from source, and you are willing to import and verify the signing key yourself. Do not point production at the daily channel, since the README describes those as untested builds, and note that the packages are only built for the listed LTS releases and two CPU architectures. Before you add a repository, verify the key fingerprint against the one in the documentation, and decide which channel you actually want, because the four channels move at very different rates and the daily one is rebuilt constantly.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. zabbly/incus on GitHub