Incus: a system container and VM manager for Linux fleets

What Incus is for, and who ends up running it

The README frames the project as a way to run full Linux systems inside containers or virtual machines through one interface. That covers two audiences. The first is a platform or infrastructure engineer who needs a small private cloud on hardware they own: instances started from distribution images, a network model, storage pools, and a REST API that other tooling can drive. The second is a developer who wants a disposable system container that behaves like a machine rather than an application sandbox.

The distinction matters because Incus is not a container runtime in the Docker sense. It does not build images from a Dockerfile and it does not run a single process per container. A system container gets its own init, its own users, and its own package manager. A virtual machine gets a kernel of its own. Both are managed by the same daemon and appear in the same instance list, which is the actual selling point: you pick the isolation level per workload without changing tools.

The project history is part of the pitch. Incus began as a community fork of Canonical's LXD after Canonical took the LXD project back from the Linux Containers community, and the README states it is maintained by the same developers who first created LXD. It is released under Apache-2.0 with no contributor licence agreement. If your organisation has ever had to reason about a CLA before contributing a patch, that absence is a concrete difference, not a slogan.

The daemon, the Unix socket, and why local access equals root

Architecturally, Incus is a daemon plus clients. The daemon owns instances, storage pools, networks, and cluster state, and exposes all of it over a REST API. The command line client and any other client speak to that API. Locally they reach it through a Unix socket; remotely they reach it over the network with authentication.

The README is blunt about the local socket. It states that local access to Incus through the Unix socket always grants full access, including the ability to attach file system paths or devices to any instance and to tweak security features on any instance. It then draws the conclusion directly: only give that access to users you would trust with root access to your system.

That is a design decision with consequences. Putting a user in the right group to run incus commands is equivalent to giving them root, so the usual Unix instinct of adding a colleague to a group for convenience is the wrong move here. The remote API is the intended path for anything multi-user, and the README lists restricting access to the daemon and the remote API as one of its security points.

Clustering is where the API-first design pays off. The README says Incus scales from one instance on a single machine to a cluster in a full data center rack. The repository's Makefile references Cowsql, a distributed SQLite built on Raft, and requires it to be present before the build proceeds. That is the mechanism behind the cluster: a replicated database rather than a separate control plane service you install and babysit. It also explains why building Incus from source is not a single go build command.

Installing Incus and starting a first instance

The README does not carry install instructions itself. It points to the Getting started page in the Incus documentation at linuxcontainers.org/incus/docs/main/tutorial/first_steps/, and it lists release tarballs on the GitHub releases page. Commercial support is available from Zabbly for users of their Debian or Ubuntu packages, which the README links at github.com/zabbly/incus. That is where to look for a current release on Debian or Ubuntu.

Building from source is documented in the Makefile, and it is worth reading before you try. The build target checks for Cowsql and aborts with a message telling you to run make deps first. The relevant part is short:

make deps
make

The first command sets up the Cowsql and Raft dependencies, either under vendor/ or under $(GOPATH)/deps depending on whether a vendor directory exists. The second builds all Incus binaries. The Makefile also exposes narrower targets: make client builds only the incus client, make incus-agent builds the agent, and make incus-migrate builds the migration tool. If you only want the command line client against an existing remote, make client is the smaller job.

Once a daemon is reachable, the normal workflow is to create an instance from a remote image and then get a shell inside it. The Incus documentation's first steps tutorial is the reference for the exact commands and remote names, and the README's try-it page at linuxcontainers.org/incus/try-it/ lets you click through the interface before installing anything. The client binary is incus, and it is the same command whether you are talking to a local daemon or a remote one.

One build detail that catches people out: the Makefile sets OVN_MINVER to 24.03.0 and OVS_MINVER to 3.3.0. If you plan to use OVN networking, those are the minimum versions the build expects, and a distribution shipping older packages will not satisfy them.

Where Incus is the wrong tool

The first limitation is in the README itself. Local socket access is root-equivalent, so Incus does not give you a safe shared host for untrusted users. If your requirement is that each developer gets an isolated environment they cannot use to touch another developer's files, a single Incus daemon with group-based access does not deliver that. You need separate daemons, separate machines, or a different access model.

The second is the build and dependency surface. Incus is written in Go, but the Makefile requires Cowsql, a C library, and the build runs with CGO and a specific CGO_LDFLAGS_ALLOW value that wraps pthread_create. The go.mod file lists a long dependency set including AWS SDK v2 modules, go-criu for checkpoint and restore, go-lxc, and Incus OS packages. This is a project that expects to be packaged by a distribution or a vendor, not compiled casually on a laptop. The README's own advice to use only supported versions points the same way.

The third is scope. Incus manages instances, storage, and networks. It is not an orchestration system for application deployments, it does not schedule workloads across a fleet based on resource requests, and it does not replace a configuration management tool. If what you actually need is to run a dozen stateless services with rolling updates, the instance model is a layer below the problem you are solving.

The fourth is that the README documents no upgrade or rollback procedure. Release announcements live on the Linux Containers discussion forum and release tarballs on GitHub, but the README itself is silent on how to move a cluster between versions. Treat that as something to establish from the documentation before you run a cluster you care about.

Incus versus Proxmox VE

The comparison people reach for is Proxmox VE, and the difference is in the control plane rather than the feature list. Proxmox is a hypervisor distribution: you install it as the operating system, and it brings its own kernel, web interface, and cluster stack. Incus is a daemon you install on a Linux system you already run. Your host stays your host, with your configuration management, your monitoring agent, and your existing kernel.

That difference decides a lot. If you are standing up dedicated virtualization hardware and want a browser console and nothing else, Proxmox matches that workflow more directly. If you have a fleet of Ubuntu or Debian machines that already exist and you want instances on them without reimaging, Incus fits the machines you have. The README's framing of a small private cloud on existing resources is exactly this position.

The second difference is the container model. Incus runs both system containers and virtual machines under one API, so a workload that does not need its own kernel can skip the virtual machine overhead without moving to a different tool. Proxmox is built around virtual machines first. If your workloads are mostly Linux and would be fine sharing a kernel, that is a real cost difference in memory and boot time, though the README makes no performance claim and none should be assumed.

The third is licensing and governance. Incus is Apache-2.0 with no CLA. Proxmox VE components are distributed under AGPL-3.0 with a separate subscription repository for enterprise packages. If your organisation has rules about copyleft in the infrastructure layer, that is a decision point you should resolve with your own legal team rather than from a review.

Maintenance, releases, and what the licence does not cover

The repository was last pushed on 2026-09-21 and is not archived, so work is ongoing. The release cadence is visible in the tags: Incus 7.4 on 2026-08-27, Incus 7.3 on 2026-07-31, and an LTS line at 7.0.1 released 2026-07-10. The existence of a separate LTS tag is the useful signal here. If you are running a cluster, the LTS line is the one to track, because it implies a different support window from the monthly releases.

Upgrade cost is where the README is thin. It documents bug reports, community support on discuss.linuxcontainers.org, and commercial support from Zabbly for their Debian and Ubuntu packages, but it does not describe a version upgrade procedure or a rollback path. Before putting a cluster into production, read the documentation tree under doc/ rather than the README alone.

On licensing: Incus is released under Apache-2.0 and the README states it is free of any CLA. That is permissive, and it means you can embed the client library in your own tooling. Note that the go.mod module path is versioned, github.com/lxc/incus/v7/client, so code importing the client is tied to a major version and will need updating when that major version moves. Apache-2.0 also carries a patent grant and requires attribution for redistributed modifications. None of this is legal advice; check your own obligations before shipping a modified build.

The security page in the repository, linked from the README, is the document to read before deployment. The README's own list is short and worth repeating as a checklist: keep the OS patched, use only supported versions, restrict daemon and API access, avoid privileged containers unless required, and secure your network interfaces.

Editorial conclusion

Adopt Incus if you want containers and virtual machines under one API and are willing to run a privileged daemon on every host. Do not adopt it if you need per-user isolation from the local socket, or if you want a hypervisor appliance with a browser console and nothing else. Before committing, read doc/explanation/security.md, confirm which Incus version your distribution ships, and check whether you need Zabbly packages for a current release.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. lxc/incus on GitHub
3. Project website
4. README
5. Releases