Docker vs LXC on Proxmox VE:
differences and when to use which

Application vs system container

LXC and Docker stand on the same Linux foundation: namespaces (PID, mount, net, UTS, IPC, user) and cgroups. Neither boots its own kernel — this is not KVM. They diverge where the lifecycle starts.

LXC is a system container. Inside you get a full userspace: systemd as PID 1, packages, users, cron, several services at once. On Proxmox VE it is a first-class guest type — you create a CT in the GUI or with pct, give it an IP on a bridge, back it up with PBS. Security and bind mounts are covered in LXC containers in Proxmox.

Docker is an application container. A typical OCI image runs one main process (or a small process set) and is built in layers from a Dockerfile. You pull images from a registry, compose stacks, or orchestrate with Kubernetes. Proxmox has no “Docker” guest type — you install the engine in a VM, in nested LXC, or — which we do not recommend — directly on the host.

Comparison table on Proxmox VE

Neither replaces a VM where you need your own kernel or Windows. Empty LXC RAM overhead is minimal — a clean Debian 13 CT is about 16 MB versus about 213 MB as a VM; numbers and context are in VM vs container: RAM usage. Docker still adds a daemon and image layers — density depends on how many containers share one engine, not on “container vs VM” alone.

Three ways to run Docker in the cluster

Proxmox does not forbid Docker. You choose where the engine runs — and that choice decides isolation, backup and HA.

• Docker in a VM (recommended for production): full guest-kernel isolation, live-migrate the VM itself, PBS backup of the whole machine, privileged / overlay2 inside without fighting the hypervisor. The overhead is the VM, not Docker.
• Docker in LXC (nesting): enable nesting=1 under Features; often FUSE as well, when overlayfs is unavailable in an unprivileged CT and the engine falls back to fuse-overlayfs. Denser than a VM, more friction: AppArmor, the devices cgroup, keyctl. HA is a CT restart, not live migration.
• Docker on the Proxmox host: packages and modules on the hypervisor, clashes with PVE upgrades, a container escape closer to the cluster kernel. You can install it — you should not on a production node.

Network, data, backup and HA

LXC gets an address on vmbr, a VLAN tag or SDN — on the wire it looks like a small VM. Docker sits behind the docker0 bridge by default and publishes ports; overlay and macvlan are another layer that Proxmox does not see as a guest.

LXC backup goes through PBS or vzdump (rootfs; bind mounts separately, as in the LXC article). Docker backup is images in a registry plus volumes — PBS will capture them only if the engine lives in a VM or CT whose rootfs includes that data. A Compose file is not a volume backup.

Cluster HA covers CTs and VMs. A running LXC cannot be live-migrated — Proxmox does a restart migration. A Docker container does not live-migrate either: you recreate it on another node (Compose, Swarm, Kubernetes). The difference: with LXC, failover sits in Proxmox ha-manager; with Docker in a VM, failover is the whole machine that holds the engine.

When Docker, when LXC, when a VM

• LXC: long-lived Linux services you treat as small servers — reverse proxy, DNS, monitoring, internal apps, a jump host. One panel, PBS, firewall, resource limits.
• Docker: vendor images, CI, microservices, immutable deploys, Compose, a path toward Kubernetes. Keep the engine in a VM when isolation and live migration matter.
• VM without containers: Windows, a custom kernel or modules, untrusted tenants, compliance that needs hypervisor-level separation.

In one Proxmox cluster the three layers coexist: LXC for dense services, Docker in a VM for application stacks, full KVM where the kernel or Windows is non-negotiable. You are not choosing “a container platform instead of Proxmox” — you pick the tool per workload.