An LXC (Linux Containers) container is a lightweight, isolated Linux environment that runs on the same kernel as its host machine. Unlike a traditional virtual machine, which simulates an entire computer with its own operating system kernel, an LXC container shares the host’s kernel and uses built-in Linux features to wall off processes, files, and network access. The result sits somewhere between a simple chroot jail and a full virtual machine: you get something that looks and feels like a standalone Linux system, boots in seconds, and uses a fraction of the resources a VM would need.
How LXC Containers Work
LXC is a userspace interface for containment features already built into the Linux kernel. It doesn’t add virtualization technology on top of the operating system. Instead, it orchestrates several kernel features to create isolated environments where processes believe they’re running on their own dedicated machine.
The two most important features are namespaces and control groups. Namespaces handle isolation: each container gets its own view of the system. A container has its own process IDs, network interfaces, mount points, hostname, and user IDs, all invisible to other containers and to the host. Control groups (cgroups) handle resource management. They organize processes into hierarchies and attach controllers that limit how much CPU, memory, disk I/O, or other resources a container can consume. Together, namespaces make containers feel separate, and cgroups prevent any single container from starving the rest of the system.
On top of this, LXC uses filesystem isolation through a mechanism called pivot_root, which gives each container its own root filesystem. The container sees its own directory tree starting at “/”, completely independent of the host’s file structure. This is conceptually similar to a chroot, but more robust and harder to escape.
Security Layers
LXC containers come in two flavors with very different security models: privileged and unprivileged.
Privileged containers run processes that map directly to real user IDs on the host. The root user inside the container is actually root on the host machine. Because of this, security depends entirely on mandatory access controls like AppArmor or SELinux profiles, seccomp filters (which restrict which kernel calls the container can make), and dropping unnecessary kernel capabilities. These layers work, but a kernel vulnerability could theoretically let a process escape the container.
Unprivileged containers take a fundamentally different approach. They use user namespace mapping so that the root user inside the container corresponds to a normal, unprivileged user on the host. Even if a process escapes the container, it lands on the host with no special permissions. LXC still applies AppArmor, SELinux, and seccomp on top of this as extra protection, but the core security doesn’t depend on them. Unprivileged containers are the recommended way to run LXC in production.
System Containers vs. Application Containers
LXC’s main focus is system containers. A system container runs a full Linux userspace, including an init system, system services, and potentially multiple applications, much like a virtual machine would. You can SSH into one, install packages, run cron jobs, and treat it as a lightweight server. It boots faster and uses less RAM than a VM because there’s no second kernel or hardware emulation involved.
This is the key difference between LXC and Docker. Docker targets application containers: single-process, single-purpose units designed to run one service. Docker actually started by building on top of LXC before eventually replacing it with its own execution environment called libcontainer. The two technologies use the same underlying kernel features, but they aim at different audiences. LXC appeals to system administrators who want to run multiple isolated Linux environments on a single host, similar in spirit to FreeBSD Jails or Solaris Zones. Docker appeals to developers who want to package and ship individual applications with their dependencies.
You can run application-style workloads in LXC, and Docker can technically host more complex environments, but each tool is optimized for its primary use case.
LXC vs. LXD
LXC provides the low-level container runtime and command-line tools for creating and managing containers directly. LXD builds on top of LXC to add a daemon-based management layer. Think of LXC as the engine and LXD as the full dashboard.
LXD runs as a background service and exposes a REST API for container management. It adds features like an image store for downloading and sharing container templates, snapshot and restore capabilities, remote host management, clustering across multiple machines, and role-based access control. If you’re managing a handful of containers on a single machine, LXC’s tools may be all you need. If you’re managing dozens of containers across multiple servers, LXD provides the orchestration and workflow tools to make that practical.
System Requirements
LXC runs on any Linux system with a kernel version of 2.6.32 or newer for basic functionality. Attaching to a running container requires kernel 3.8 or later, and unprivileged containers need kernel 3.12 or above. Any modern Linux distribution meets these requirements easily.
Ubuntu, Debian, Arch Linux, and Fedora all support LXC. Ubuntu is particularly well-suited because it ships with everything needed for unprivileged containers out of the box, including the necessary user namespace configuration. On other distributions you may need to enable a few kernel options or configure user ID mappings manually.
The current long-term support release is LXC 6.0, which is supported until June 2029. It receives regular bugfix updates and remains under active development, with recent releases adding features like support for new container image formats and improved handling of modern init systems.
Common Use Cases
LXC containers are popular for running multiple isolated services on a single physical server without the overhead of full virtualization. A hosting provider might run dozens of LXC containers on one machine, each acting as an independent Linux server for a different customer. A development team might use LXC to spin up clean test environments that closely mirror production servers.
- Server consolidation: Run multiple isolated Linux environments on one host with near-native performance and minimal memory overhead.
- Development and testing: Create disposable environments that replicate full Linux systems, complete with services and networking, in seconds.
- Build environments: Isolate software builds in clean containers to ensure reproducibility without the startup cost of virtual machines.
- Legacy application hosting: Run older applications in containers configured with the specific distribution and libraries they require, isolated from the host.
Because LXC containers share the host kernel, they can’t run a different operating system (no Windows containers on a Linux host, for example) and they can’t run a different kernel version than the host. If you need either of those, you need a full virtual machine.