LXD: system containers and virtual machines behind one REST API

What LXD solves, and who it is actually for

The README describes LXD as a system container and virtual machine manager that gives "a unified experience for running and managing full Linux systems inside containers or virtual machines." That wording matters. This is not a tool for packaging one application and its dependencies. It is a tool for booting an entire distribution, with its own init system, users and network stack, and managing it the way you would manage a machine.

The intended audience is stated plainly: you should consider LXD "if you want to containerize different environments or run virtual machines, or in general run and manage your infrastructure in a cost-effective way." In practice that means platform teams, lab and CI operators, and anyone who wants a handful of long-lived Linux systems on one host without reaching for a hypervisor per workload. The README frames the result as "a small private cloud."

One consequence is worth stating early. Because LXD runs whole systems, the isolation boundary and the resource model are different from application container runtimes. The README's own security guidance tells you not to use privileged containers unless required, which is an admission that the default container mode is the one you should stay in.

Instances, images and the REST API underneath lxc

The architecture visible in the repository is a daemon plus clients. The top-level entries include lxd/ (the daemon), lxc/ (the command line client), lxd-agent/ (the in-VM agent), plus lxd-benchmark/, lxd-convert/ and lxd-user/. The client SDKs live in client/, and the README points Go users at pkg.go.dev/github.com/canonical/lxd/client and Python users at github.com/canonical/pylxd. Both SDKs are licensed Apache-2.0, separate from the AGPL-3.0 daemon.

Everything the CLI does goes through the REST API. The README says LXD is "built around a very powerful, yet pretty simple, REST API" and links to a REST API landing page in the documentation. That is the design decision that makes the rest coherent: images, instances, networks and storage are API objects, and lxc is one client among several. The README lists Ansible connection and inventory plugins, a Bolt transport, a Packer builder and a Terraform provider, all of which talk to the same API rather than to the CLI.

Scale is handled by clustering. The README states LXD "scales from one instance on a single machine to a cluster in a full data center rack." The go.mod file shows github.com/canonical/go-dqlite/v3 as a dependency, which is the distributed SQLite layer used for cluster state, and github.com/lxc/go-lxc for the container runtime binding. The presence of grafana/ and lxd-benchmark/ at the top level suggests metrics and load testing are treated as first-class concerns rather than afterthoughts.

Installing LXD and launching a first instance

The README gives a short package table. The daemon only works on Linux; the lxc client is available on most platforms. On Linux the supported package is the snap. On Windows the README lists Chocolatey and on macOS Homebrew, both of which install only the client.

snap install lxd

After the snap is installed, the daemon needs initial configuration. The README does not print the wizard command itself; it directs readers to the Getting started page at canonical.com/lxd/docs/latest/getting_started/ for installation instructions and first steps, so treat that page as the authoritative source for the exact prompts and defaults.

Once a server is reachable, the client is the way in. The README's package table names the client binary as lxc, and the repository keeps its source in the lxc/ directory. A typical first action is listing what the server has available, then creating an instance from an image. The README states that LXD supports images for a large number of Linux distributions, including official Ubuntu images and images provided by the community, but it does not spell out the image server address or the exact create syntax. Check the documentation for the current form before scripting anything.

For remote use, the same client talks to a server over the API. The README's platform table is the practical detail here: a macOS or Windows machine installs lxc and points it at a Linux host, which is why the client and the daemon are packaged separately.

The Unix socket is a root-equivalent trust boundary

The README carries an explicit warning, and it deserves more weight than the surrounding text. Local access to LXD through the Unix socket "always grants full access to LXD," including the ability to attach file system paths or devices to any instance and to change security features on any instance. The README then says you should only give such access to users you would trust with root access to your system.

That is not a caveat you can configure away. It is a property of the local API surface. On a shared build host, a jump box, or any machine where several engineers have shell access, adding someone to the LXD group is effectively handing them root. The same logic applies to the remote API: the README's security list says to restrict access to the LXD daemon and the remote API, alongside keeping the OS patched and configuring network interfaces securely.

A second limitation is version support. The README instructs you to use only supported LXD versions, defined as LTS releases or the latest feature release. Three LTS lines appear in the recent releases: 5.21.7, 5.0.9 and 4.0.13, all dated 2026-08-24. Running a feature release means tracking a faster upgrade cadence; running an old LTS eventually falls outside the supported set. Neither option is free.

LXD versus Docker, Proxmox and KVM

The most common comparison is LXD against Docker, and the difference is the unit of work. Docker packages an application and its dependencies as an image and runs a process; LXD runs a full Linux system with its own init, which is why the README talks about "full Linux systems" and a private cloud rather than about images and registries. If your artifact is a binary plus a config file, Docker is the smaller tool. If your artifact is a machine that someone will SSH into, LXD matches the shape of the problem.

Against Proxmox and KVM the split is containers versus virtualization. LXD offers both: the README says it manages system containers and virtual machines, so a VM in LXD is one instance type among several rather than the only option. A pure KVM stack gives you hardware virtualization and nothing else, which is simpler to reason about but leaves no path to a lighter container instance on the same host. LXD's QEMU-related packaging appears in the repository as lxd-qemu-snap/, and the in-guest side is lxd-agent/, which is what lets the daemon manage a VM instance the same way it manages a container.

The README also lists MicroCloud alongside Ansible, Bolt, Packer and Terraform as tooling for managing LXD at scale. That is the honest framing: LXD is the substrate, and the orchestration layer around it is a separate choice.

Licence, support and what an upgrade actually costs

The repository is licensed AGPL-3.0, per the COPYING file and the project metadata. The client SDKs are the exception: the README states they are licensed Apache-2.0. That split matters if you intend to embed the Go or Python client in your own product, because the permissive licence applies to the SDK and not to the daemon. This is a description of what the repository says, not legal advice; if the AGPL obligations affect your distribution model, get a lawyer to read the licence text rather than a README table.

Support is tiered. LTS releases receive standard support for five years, which the README describes as continuous updates. Commercial support comes through Ubuntu Pro, in both Infra-only and full tiers, and the README links to a service description for the details. Everything else runs on the community channels: a Discourse forum, the documentation site, and GitHub issues.

Upgrade cost is mostly a function of which line you picked. LTS lines move slowly and are the default recommendation for production. Feature releases move faster. Building from source is a separate path with its own toolchain: the Makefile pins GOMIN to 1.26.8, sets GOTOOLCHAIN=local, and expects dqlite and liblxc to be present, with a "make deps" step referenced when they are missing. The Makefile's lxd target refuses to build and prints "Missing dqlite, run \"make deps\" to setup." if the dqlite headers are not found. That is a real barrier for anyone who wants a source build on a distribution without the right packages.

Editorial conclusion

Adopt LXD when you need full Linux systems, not single processes, and you want a REST API plus an lxc client that also runs on macOS and Windows. Skip it if you only ship application containers; Docker or Kubernetes covers that ground with a smaller surface. Before committing, check three things: whether your kernel and distribution are covered by the install documentation at canonical.com/lxd/docs/latest/installing/, which LXD release line you are tracking (5.21 LTS, 5.0 LTS or 4.0 LTS), and whether every user with access to the Unix socket is someone you would trust with root.

Frequently asked questions

Official sources

1. canonical/lxd on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases