Running multiple services on a single physical server has always been a classic challenge for sysadmins. Virtual Machines (VMs) offer full isolation but have significant overhead. Docker is efficient, but it is designed for application containers, not full OSes. LXD sits between these two options as a container system that provides a VM‑like experience but works as lightly as a container.
What is LXD?
LXD (pronounced lex‑dee) is a system container and virtual machine manager developed by Canonical, the company behind Ubuntu. Since 2015, LXD has been Canonical’s official solution for managing Linux‑based system containers, and the platform has now evolved to also manage VMs.
As of April 2026, LXD is at feature release version 6.8, available via the latest/stable or 6/stable channels in the Snap Store. Users who need long‑term stability can use the LTS channel 5.21/stable, which receives security updates and bug fixes without major feature changes. This project is open‑source and uses the AGPL‑3.0 licence.
The Linux virtualisation ecosystem has three major layers that need to be understood:
- Traditional VMs (KVM, QEMU, Hyper‑V): Emulate full hardware, have their own kernel, provide maximum isolation, but have high overhead.
- Application containers (Docker, Podman): Isolate a single process or application and share the host kernel, making them very efficient but not a full OS.
- System containers (LXD/LXC): Run a full Linux OS inside a container and share the host kernel, resulting in minimal overhead and strong isolation.
LXD occupies the third layer while also being able to reach the first layer because the platform also supports QEMU‑based VMs. This ability makes it a single, flexible platform for various deployment scenarios.
System Container Manager
LXD is a daemon that runs on top of liblxc and provides a feature‑rich REST API for managing containers and VMs. The CLI commands communicate with the LXD daemon through a Unix socket or the network when you run a command like lxc launch, which then coordinates with liblxc to create and run the container.
Each LXD container runs a full Linux operating system complete with an init system (e.g. systemd), a service manager, and processes that run simultaneously. This is fundamentally different from Docker, which generally runs only one main process per container.
Differences between LXD, LXC, and Docker
Confusion between LXD and LXC is very common. Understanding the differences between the three is critically important:
| Aspect | LXC | LXD | Docker |
|---|---|---|---|
| Type | Low‑level container tool | System container & VM manager | Application container runtime |
| Interface | CLI & library (liblxc) | REST API, CLI, Web UI | CLI, REST API, daemon |
| Target workload | Full OS container | Full OS container & VM | Single process/application |
| Image management | Manual | Built‑in image server | Docker Hub / registry |
| Common use | System level, scripting | Servers, VPS, private cloud | Microservices, CI/CD, development |
LXD is not a new version of LXC. LXD is a management layer built on top of LXC to provide ease of use, better security, and enterprise features such as clustering, live migration, and storage management that are not available natively in LXC.
Application Container vs. System Container
Understanding this difference is very important before choosing the right tool:
- Application containers (Docker, Podman) package a single process or application. This technology is suitable for microservices, CI/CD pipelines, and immutable image‑based deployments.
- System containers (LXD) simulate a full operating system and allow multiple processes to run together. This solution is suitable for isolating user environments, running multiple services inside one unit, or building a simple private cloud.
The official LXD documentation states that system containers are suitable when all required functionality is compatible with the host kernel. On the other hand, a VM is the better choice if you need your own kernel because of functionality incompatibilities.
VM Support in LXD
LXD has natively supported VMs using QEMU as a backend since version 4.0. Containers and VMs can be managed through the same interface, whether the CLI or the built‑in Web UI. The only difference in management is the --vm flag when creating an instance:
# Create a container (default)
lxc launch ubuntu:24.04 container-name
# Create a VM
lxc launch ubuntu:24.04 vm-name --vmThe convergence of containers and VMs into a single platform is one of LXD’s main selling points compared to other solutions.
Advantages of LXD
High Performance through Minimal Overhead
LXD system containers share the host kernel, so CPU and memory overhead is much smaller than in traditional VMs. Hardware emulation is not needed. As a result, a server with 16 GB of RAM can run dozens of LXD containers simultaneously, while a traditional hypervisor might handle only a few VMs under the same conditions.
According to performance tests from the Canonical community, LXD container startup times average under one second, while VMs take tens of seconds to fully boot.
Strong System Isolation
Each LXD container runs in isolated namespaces, including network namespace, PID namespace, mount namespace, and user namespace. This means that processes inside one container cannot see or affect processes in another container or on the host.
LXD runs containers in unprivileged mode by default. This mechanism maps root inside the container to a non‑root UID on the host via UID/GID mapping. Even if a process escapes the container, it only has the access rights of an ordinary user on the host system.
Additional security layers are provided by:
- AppArmor profiles: Prevent containers from performing dangerous actions such as inter‑container signalling and writing to sensitive system files.
- Seccomp policies: Block dangerous system calls such as kernel module loading, kexec, and forced unmount.
Scalability and Flexibility
LXD can run from a single instance on a developer’s laptop to a full cluster in a data centre rack. The built‑in clustering feature allows managing hundreds of nodes through a single control point. This ability underpins Canonical’s move to position LXD as the foundation for MicroCloud, their small‑scale private cloud solution.
Common use cases include:
- Hosting web servers (Nginx, Apache) and databases (MySQL, PostgreSQL) in separate containers.
- Building VPS‑in‑VPS for multitenancy needs.
- Isolated per‑project development environments.
- CI/CD runners with clean environments that can be snapshotted and restored.
- Testing operating system configurations without risking damage to the host.
Advanced Storage Management
LXD supports various storage backends, including ZFS, Btrfs, LVM, Ceph, and plain directories. ZFS is the recommended backend because it supports copy‑on‑write, allowing new containers to be created from snapshots in milliseconds.
The built‑in snapshot feature of LXD is also very useful for backup and rollback. A container can be snapshotted before making major changes and then restored in seconds if something goes wrong.
REST API and Integration Ecosystem
LXD provides a complete, documented REST API to simplify integration with automation systems such as Ansible, Terraform, or custom shell scripts. Client libraries are available for Python (pylxd) and Go. The built‑in Web UI can be enabled for visual management directly from a browser without additional installation.
Installing LXD
System Requirements
Make sure your system meets the following minimum requirements before starting the installation:
- Linux operating system (Ubuntu 24.04 LTS or Ubuntu 26.04 LTS recommended).
- At least 20 GiB of free disk space.
- Root or sudo access to the system.
- Internet connection to download packages and container images.
LXD is installed by default on Ubuntu Server cloud images. The easiest way for other systems is via snap.
Step 1: Install LVD via Snap
Snap is Canonical’s recommended way to install and update LXD. This method ensures that you always get the latest tested version from the chosen channel. Run the following command to install LXD:
sudo snap install lxdFollow the snap installation guide at snapcraft.io if snap is not already available on your system.
Check the active version if LXD was already installed and you want to ensure the version is 5.21 or newer:
snap list lxdStep 2: Add User to the lxd Group
LXD communicates through a Unix socket that can only be accessed by members of the lxd group. Add your active user to this group:
sudo usermod -aG lxd "$USER"
newgrp lxdThe newgrp lxd command activates the group membership in the current terminal session without requiring a logout. There is an important security note: access to the lxd group is equivalent to root access because a lxd user can attach any filesystem path or device to any container. Only grant this access to trusted users.
Step 3: Initialise LXD
After installation, run the initialisation command to set up the basic LXD configuration, including the storage pool and network configuration:
lxd init --minimalThe --minimal flag runs the initialisation with safe default values that are suitable for most scenarios. Run the command without that flag if you want to interactively configure options such as the storage backend (ZFS, Btrfs, LVM) or network availability:
lxd initThis interactive process will ask several choices:
- Storage backend: ZFS (recommended), Btrfs, LVM, or directory.
- Size of the storage pool or block device to use.
- Exposing LXD over the network (for clustering or remote access).
Step 4: Network Configuration (Bridge Networking)
LXD automatically creates a bridge network named lxdbr0 during initialisation, allowing containers to connect to the internet via NAT. Verify that the bridge is active:
lxc network listThe expected output will show lxdbr0 with status CREATED. Use the following command if the bridge needs to be configured manually:
lxc network create lxdbr0 ipv4.address=10.10.10.1/24 ipv4.nat=true ipv6.address=noneStep 5: Create Your First Container
Create your first Ubuntu container once LXD is ready. The lxc launch command downloads the image, creates the container, and starts it immediately:
lxc launch ubuntu:24.04 first-serverLXD will download the Ubuntu 24.04 LTS image from the official Canonical image server (ubuntu:). The downloaded image is stored in a local cache, so subsequent container creations are much faster.
Verify the container is running:
lxc listEnter the container’s interactive shell:
lxc shell first-serverYou are now inside the container as root. All normal Linux commands run normally inside this isolated environment.
Managing Containers: Basic Commands
Here is a list of the most frequently used lxc commands for day‑to‑day container management:
lxc list: List all containers and VMs.lxc init ubuntu:24.04 container-name: Create a container without starting it.lxc start container-name: Start an existing container.lxc stop container-name: Stop a container.lxc delete container-name: Delete a container (must be stopped first).lxc exec container-name -- command: Run a command inside the container from the host.lxc info container-name: Show detailed container information.lxc config set container-name limits.cpu=2 limits.memory=1GiB: Set resource limits.
Creating Snapshots and Restoring
Snapshot capability is one of the most important LXD features for server operations. Create a snapshot before making major configuration changes:
lxc snapshot container-name before-update: Create a snapshot named “before‑update”.lxc info container-name: List snapshots.lxc restore container-name before-update: Restore the container to the snapshot state.lxc delete container-name/before-update: Delete an unnecessary snapshot.
Updating LXD and Holding Auto‑Updates
Snap automatically updates LXD according to the default settings. System administrators are advised to hold automatic updates on production environments and apply them manually during scheduled maintenance windows:
sudo snap refresh --hold lxd: Hold automatic updates for LXD.sudo snap refresh lxd: Manually update LXD when ready.sudo snap refresh --unhold lxd: Remove the hold and return to automatic updates.
Advanced Usage Scenarios
Running a Web Server in a Container
A practical example of this use is isolating Nginx in its own container so that it does not interfere with other services on the host. After the container is running, enter it and install Nginx:
lxc launch ubuntu:24.04 web-server
lxc exec web-server -- bash -c "apt update && apt install -y nginx"
lxc exec web-server -- systemctl enable --now nginxUse a proxy device configuration to expose the container’s port to the host:
lxc config device add web-server port80 proxy listen=tcp:0.0.0.0:80 connect=tcp:127.0.0.1:80Using Profiles to Standardise Configuration
LXD profiles are sets of configuration that can be applied to many containers at once. This feature is very useful for standardising resource limits, devices, and network configuration across your infrastructure:
lxc profile list: List existing profiles.lxc profile create production: Create a new profile.lxc profile edit production: Edit a profile.lxc profile launch ubuntu:24.04 app-server --profile production: Apply a profile when creating a container.
Containers Based on Distributions Other Than Ubuntu
LXD is not limited to Ubuntu alone. The community image server (images:) provides images for various Linux distributions such as Debian, Alpine, Fedora, Arch Linux, and openSUSE:
lxc image list images:: List all available images.lxc launch images:debian/12 debian-server: Run a Debian container.lxc launch images:alpine/3.19 alpine-server: Run a very lightweight Alpine Linux container.
Accessing the LXD Web UI
LXD provides a web‑based graphical interface that can be enabled for visual management. The Web UI can be accessed via a browser after you configure LXD to listen on the network:
lxc config set core.https_address :8443Access it via a browser at https://SERVER-IP:8443.
The Web UI provides a container dashboard, image management, network configuration, and storage without needing any additional application installation.
Conclusion
LXD is an ideal solution for sysadmins and developers, offering container efficiency with a VM‑like experience, characterised by minimal overhead, strong isolation, and advanced storage management for both production and development servers. Backed by Canonical’s consistent security support and a comprehensive REST API, this platform is a reliable choice for automating and managing a variety of modern workloads.




