LXC vs Docker on Proxmox: Which Container Type Should You Use?

"Should this be an LXC or a Docker container?" is one of the most common questions new Proxmox users ask, and it is usually the wrong question — because LXC and Docker are not competing answers to the same problem. They are two different kinds of container built for two different jobs. LXC gives you a lightweight, persistent Linux system that you administer like a tiny always-on server. Docker gives you a disposable, image-defined application that you throw away and recreate without a second thought. Confusing the two leads to fragile setups: people cram stateful services into throwaway Docker containers, or hand-configure LXC containers so heavily that they become impossible to reproduce. This guide draws the line clearly, shows how each performs and persists on Proxmox, and — most usefully — explains how they fit together rather than compete.

Key Takeaways

• Different container models — LXC is a system container (a whole lightweight OS); Docker is an application container (one app and its dependencies).
• Persistence differs by design — LXC is meant to be a long-lived machine you maintain; Docker containers are disposable and rebuilt from images, with data kept in volumes.
• Proxmox treats LXC as a first-class citizen — you create and manage LXC natively in the UI; Docker typically runs inside an LXC or a VM rather than directly on the host.
• Reproducibility favors Docker — a Dockerfile plus compose file recreates a service identically anywhere; an LXC is configured more like a pet server.
• The best answer is usually both — LXC as the lightweight host, Docker for the apps running on it, with the choice of host driven by how much isolation you need.

Two Different Ideas of "Container"

The single most important thing to understand is that LXC and Docker sit at different altitudes. LXC (Linux Containers) is a system container. When you create one on Proxmox, you get something that behaves like a small virtual machine: it boots an init system, has its own users, runs multiple services, and you SSH in and manage it as a persistent host. It shares the Proxmox host kernel, which is why it is so much lighter than a full VM, but from the inside it feels like a complete Linux install.

Docker is an application container. A Docker image bundles one application and exactly the dependencies it needs, and a running container is that single app as a process, isolated from everything else. You do not "log in and administer" a Docker container the way you do an LXC — you define it in a Dockerfile, run it, and when something changes you rebuild the image and replace the container. The container itself is meant to be disposable; its identity lives in the image, not in the running instance.

This is why "LXC vs Docker" is really "persistent machine vs disposable app." Once you see them that way, most placement decisions answer themselves. The distinction between system-level container flavors is explored further in Privileged vs Unprivileged LXC Containers on Proxmox, which matters a great deal for security.

How Proxmox Treats Each One

Proxmox VE was built with LXC as a first-class object. In the web UI, "Create CT" spins up an LXC container from a template with a few clicks — you pick resources, a template, networking, and it is running in seconds. It integrates with the same storage, backup, snapshot, and firewall systems as VMs. This is exactly why LXC is so popular for homelab services: it is the lightest way to run a persistent Linux workload with full Proxmox management around it, as shown in 6 Must-Have LXC Containers for Your Proxmox Homelab.

Docker is a different story. Proxmox does not run Docker containers as native cluster objects — there is no "Create Docker Container" button that stands beside VMs and LXC. Instead, you run a Docker engine somewhere and let it manage its containers. The two established patterns are Docker inside an LXC and Docker inside a VM. Proxmox VE 9.1 blurred this a little by adding OCI image support to LXC, letting you launch certain container images directly as system containers — covered in Proxmox VE 9.1 OCI LXC: Running Any Container Image — but that is a convenience for simple images, not a replacement for a real Docker engine with compose, networking, and the full ecosystem.

Performance and Resource Overhead

Both container types are dramatically lighter than a VM because neither boots its own kernel — they share the host's. That shared-kernel model is the whole reason a Raspberry Pi or an N100 mini-PC can run a dozen containers where it would struggle with even a couple of full VMs.

Between the two, the overhead difference is modest and often misunderstood. An LXC carries slightly more baggage because it runs a complete userland and an init system managing multiple services. A single Docker container is leaner in isolation because it is just one process and its libraries. But this rarely decides anything, because you do not usually compare one LXC to one Docker container — you compare one LXC to one LXC-hosting-many-Docker-containers. The real overhead question on Proxmox is almost always "container vs VM," and there both win decisively. If you want measured numbers on that comparison, LXC vs KVM on Proxmox: Measured Resource Overhead has the benchmarks.

Persistence and State: Pets vs Cattle

Here is where the philosophies genuinely diverge, and where people get burned. An LXC container is a pet. You set it up, install packages, tweak configs, and it keeps that state across reboots and for years if you let it. That is a feature when you want a stable, long-lived service — but it also means the container accumulates undocumented changes, and rebuilding it from scratch means remembering everything you did.

A Docker container is cattle. The running container is expendable; all the important state is supposed to live in named volumes or bind mounts, and the configuration lives in a Dockerfile and compose file checked into version control. You can delete the container and recreate it byte-for-byte from the image in seconds. This makes upgrades and migrations trivial — pull a new image, recreate, done — but it forces discipline: any data not deliberately placed in a volume is gone when the container is replaced.

The practical implication is about where you put state. Databases, media libraries, and config directories want persistent storage regardless of container type. With LXC that persistence is the container's own disk plus Proxmox LXC Bind Mounts: Share Host Paths with Containers for host data. With Docker it is volumes, and if that Docker engine runs inside an LXC, you are layering the two persistence models — which works fine as long as you keep track of which layer owns the data.

The Real Workflow: Use Them Together

On a well-run Proxmox host, this is rarely an either/or decision. The dominant pattern is LXC as the lightweight host and Docker as the app runtime on top of it. You create an LXC, install the Docker engine, and run your applications as Docker containers with compose — getting Docker's reproducibility and huge image ecosystem while keeping the low overhead and native Proxmox management of LXC. The setup and the important tuning knobs are covered in Running Docker Inside LXC Containers on Proxmox.

There is an important caveat: running Docker inside an unprivileged LXC requires enabling nesting and, for some workloads, keyctl and specific feature flags. It works well for homelab use, but because the LXC shares the host kernel, the isolation is weaker than running Docker inside a dedicated VM. When you need firm isolation — untrusted images, multi-tenant workloads, anything internet-facing that you want walled off from the host — put the Docker engine in a VM instead. The tradeoffs of that specific choice are laid out in Docker in LXC vs VMs on Proxmox — Which Setup Wins?.

Once you are running Docker at any scale, a management layer helps enormously; Managing Docker on Proxmox with Portainer and Dockge covers the two most popular options for keeping compose stacks tidy.

When to Pick Each One

Reach for a plain LXC when:

• You want a lightweight, persistent Linux host you administer directly — a Pi-hole, a WireGuard endpoint, a small database, a file share.
• The service is not distributed as a container image, or you prefer to manage it as a normal machine.
• You value native Proxmox snapshots, backups, and firewall integration around a single service.

Reach for Docker (inside an LXC or VM) when:

• The software ships as an image and you want reproducible, version-controlled deployments.
• You run many small services and want compose to define and update them declaratively.
• You value throwaway-and-recreate upgrades over hand-maintained hosts.

Choose the Docker host by isolation need: an LXC when you want density and Proxmox integration for trusted workloads; a VM when you need strong isolation for untrusted or internet-facing containers.

Conclusion

LXC and Docker only look like rivals until you see that they answer different questions. LXC is the lightweight persistent machine Proxmox manages natively — perfect for services you run and maintain like small servers. Docker is the disposable, reproducible application layer — perfect for the sprawl of image-based apps that define a modern homelab. The setups that age well do not pick a side; they use LXC as the efficient host and Docker for the apps, choosing an LXC or a VM to run the engine based on how much isolation the workload demands. Start by sorting each service into "persistent machine" or "disposable app," place it accordingly, and your Proxmox host stays both lean and reproducible. If you are ready to build the hybrid setup, Running Docker Inside LXC Containers on Proxmox is the place to begin.