Short answer: LXC runs a full Linux system in a lightweight container — its own init, its own services, SSH into it like a small VM. Docker runs one application process per container, built from a versioned image, meant to be thrown away and recreated rather than logged into and patched. They solve different problems and are not really competing for the same job, even though both are called “containers” and both share the host’s kernel instead of virtualizing hardware.
| LXC | Docker | |
|---|---|---|
| What it holds | A whole Linux OS userland: init, systemd, several services, a package manager | One process and its exact dependencies, nothing else |
| How you build it | Start from a distro template, then configure it like a VM | A Dockerfile describes exact, reproducible build steps |
| Persists state | Yes, by default — it is a machine you keep | No, by design — state belongs in a volume, the container itself is disposable |
| Typical workflow | ssh in, apt install, edit config files, systemctl restart | docker build, docker push, docker run a new image; never edit inside it |
| Networking | Gets its own IP on a bridge, like a VM | Gets an internal IP by default; ports are explicitly published to the host |
| Isolation | A full container, cgroups + namespaces, same strength as Docker's | Same underlying mechanism — cgroups and namespaces |
| Running several services | Normal: one container can run nginx, a database and a cron job together, like a VM would | One process per container is the convention; several services means several containers |
| Image ecosystem | Distro templates (Debian, Ubuntu, Alpine…), far smaller library | Docker Hub: hundreds of thousands of prebuilt application images |
| Orchestration | None built in; Proxmox and Incus add a management layer | Docker Compose for one host, Kubernetes/Swarm for a cluster |
| Best fit | Replacing several small VMs with something lighter, keeping the VM mental model | Packaging and running one application, reproducibly, anywhere |
What LXC actually is
LXC (LinuX Containers) is the original Linux container technology, predating Docker by several years, and it containerizes an entire operating system rather than a single program. An LXC container boots init (often systemd) as PID 1, runs multiple services side by side, keeps its own /etc, its own users, its own cron jobs, and behaves for almost every practical purpose like a lightweight VM: you ssh into it, apt install things, edit config files in place, and the state you leave there stays until you change it again. This is the model KVM vs OpenVZ and the rest of the virtualization comparisons on this site assume, because it is the one most VPS users already know from a real VM.
What Docker actually is
Docker containerizes one application process, built from an image that lists its exact dependencies in a Dockerfile and never changes once built. A Docker container has no init system by convention (PID 1 is your application itself, or a minimal init such as tini) and no expectation of state surviving a restart — delete the container and run the image again, and you get back exactly what you started with, which is the entire point. Anything that must persist — a database’s files, uploaded content — goes in a named volume or a bind mount, kept deliberately outside the container. Installing it on a fresh server is covered in installing Docker on Ubuntu and Debian.
What they actually share
Both are “containers” in the technical sense: namespaces for process, network and filesystem isolation, cgroups for resource limits, and the host’s own kernel underneath — no hypervisor, no virtualized hardware, no second kernel booting. Neither is “more isolated” than the other at this layer; Docker even uses runc, which traces its lineage to LXC’s own isolation primitives. The real difference is entirely about what each one assumes you are packaging: a machine, or a process.
When LXC is the better fit
- You want several small VM-like environments on one host without full hardware virtualization’s overhead — Proxmox VE uses LXC for exactly this, alongside full KVM virtual machines, letting you pick per workload.
- The workload is a whole legacy stack: an old application tied to specific OS packages, several services that were never split apart, or software that genuinely expects to be administered like a server rather than redeployed from an image.
- You want to manage it the way you already manage a VM: SSH in,
apt upgrade, edit files, restart services — no build pipeline, no image registry.
When Docker is the better fit
- You are packaging one application to run the same way on your laptop, a CI runner and a server, which is Docker’s whole reason to exist.
- You want a huge library of ready-made images: Postgres, Redis, Nextcloud, n8n and almost anything else self-hosted ships an official Docker image; almost none ship an LXC template.
- You want disposable, reproducible deploys: roll back by running the previous image tag, rather than restoring a snapshot of a machine that drifted.
- You plan to scale to several hosts later, where Kubernetes and Swarm give you a path LXC has no equivalent for.
Proxmox LXC vs Docker inside a Proxmox VM
On Proxmox VE specifically, the practical question is usually not “LXC or Docker” but “run the app in an LXC container directly, or run Docker inside a VM”, since Proxmox does not run Docker containers natively as first-class citizens (and running Docker inside an LXC container, rather than a VM, is unsupported and prone to breaking on kernel updates). The common, working pattern is a small KVM virtual machine dedicated to Docker, with Docker Compose managing everything inside it, while LXC containers handle the lighter, VM-like services directly. See what is Proxmox VE for how Proxmox itself fits LXC and KVM together.
Docker vs Kubernetes: a different question
Kubernetes is not an alternative to Docker in the way LXC is — it is an orchestrator that schedules containers (commonly, though not exclusively, built as Docker images) across many machines, handling restarts, scaling and networking between them. A single VPS running a handful of services has no real need for it; Docker Compose already covers “several containers, one host, started together”. Kubernetes earns its complexity once you are coordinating containers across more than one physical or virtual machine.
Can one host run both?
Yes, and it is common: a Proxmox host running LXC containers for lightweight services next to a VM dedicated to Docker, or a single Debian VPS running both lxc/lxd (now incus, the actively developed fork) for one or two full-OS containers and Docker Compose for everything packaged as an image. Nothing about either technology excludes the other on the same kernel.
Frequently asked
What is the real difference between LXC and Docker?
LXC containerizes a whole operating system — its own init, several services, state that persists — and you administer it like a small VM. Docker containerizes one application process, built from an image, meant to be thrown away and recreated rather than logged into and patched by hand. Both use the same underlying Linux kernel features (namespaces and cgroups); the difference is entirely in what each one assumes you are packaging.
Can I run Docker inside an LXC container?
It is possible but unsupported and prone to breaking on kernel updates, because Docker expects certain kernel features an LXC container does not reliably expose. The common, working pattern on Proxmox is a small KVM virtual machine dedicated to Docker, with LXC containers handling the lighter, VM-like services separately.
Is LXC more or less secure than Docker?
Neither is inherently stronger at the isolation layer — both rely on the same Linux namespaces and cgroups, with no hypervisor underneath either. LXC's full-OS model gives a container more to secure (a whole running system, patched like a VM), while Docker's single-process model gives each container less surface, but a misconfigured LXC container and a misconfigured Docker container can both be broken out of.
Is Kubernetes an alternative to Docker, like LXC is?
No — Kubernetes is an orchestrator that schedules containers (commonly Docker images) across several machines, not a replacement for Docker itself. A single VPS running a handful of containers has little use for it; Docker Compose already covers that case on one host.