Running Docker on Proxmox: pick VM or LXC, not the host

Proxmox Virtual Environment ships with solid virtualization and LXC (Linux container) management out of the box, which covers most self-hosting needs without reaching for Docker at all. Sometimes you reach for Docker anyway, either because you are new to the platform and want a familiar workflow for spinning up FOSS (free and open source software) services, or because the specific project you want to run ships only as an OCI (Open Container Initiative) container that resists an LXC install. The Docker question on Proxmox is not really a Docker question. It is a where-do-you-run-Docker question, and the honest answer depends on the hardware sitting under your PVE (Proxmox Virtual Environment) host.

Here is what to know about the three real options, where each one shines, and where each one breaks down on systems you actually have at home.

Why this is even a choice

Proxmox gives you three plausible places to put a Docker engine:

• Inside a Linux VM (the default Docker Engine install on Ubuntu Server or a minimal Debian image)
• Inside an LXC container, treating the LXC as a host for the Docker engine
• On the PVE host itself, with no isolation at all

Each path trades isolation for performance differently, and most of the loud advice you read online is written from the perspective of one specific hardware tier. On a modern 8-core, 32GB machine, the VM option feels bulletproof and people tell you to use it for everything. On a recycled 2014 laptop with 4GB of RAM, the LXC option is the only thing that boots in a reasonable time, and people tell you to use it for everything. Both groups are right on their own hardware and wrong on the other. The right answer for your setup depends on what you actually have.

The VM path: safer, heavier, recommended in the docs

Running Docker inside a dedicated VM is the path the Proxmox documentation leans toward, and for good reason. You create a VM, install a minimal Linux distribution on it, run the standard Docker Engine install, and use that VM as the single home for every container you want to run. As long as you give it enough resources, the experience is predictable, well-understood, and easy to snapshot or migrate.

Why people reach for this option first:

• The VM provides a clean kernel boundary between Docker and the PVE host
• Networking, storage, and snapshots behave the way Docker users expect
• AppArmor and seccomp profiles apply the way upstream intended
• A standard Ubuntu Server image has every dependency Docker needs, with no surprises

The cost is overhead. On weaker hardware that 4GB VM with Docker Engine running a few lightweight services is already running short of headroom before you have asked the VM to do anything else. On more capable hardware, the overhead is barely noticeable, and you gain the predictability of having one VM to back up, snapshot, and migrate.

• Use the VM path when your host has 16GB or more RAM and you want one container home to manage
• Use the VM path when you want clean separation between PVE and your containers
• Use the VM path when you are running sensitive services, like anything exposed to the internet
• Skip the VM path when you are reusing older hardware that cannot spare the RAM

The LXC path: lighter, shareable, harder to debug

Running Docker inside an LXC is the workhorse option for low-power and shared-hardware setups. You create a privileged or unprivileged LXC, install Docker Engine on it the same way you would on any other Linux host, and point that LXC at the container workloads you want to run. The LXC consumes less memory than a VM because there is no separate kernel running, and you can spin one up in seconds on hardware a VM would not boot on comfortably.

The trade is isolation. An unprivileged LXC is still a process tree on the host kernel, which means a container escape gives an attacker access to PVE rather than to a sandboxed VM. The Docker socket, networking, and storage all live one layer closer to the host than they would in a VM setup.

What you get in return:

• Much lower memory and CPU overhead than a VM
• The ability to share PCI devices, including GPUs, across multiple LXC containers concurrently
• Faster boot times and more predictable performance on older hardware
• A familiar Docker workflow for anyone who already uses Docker elsewhere

What you give up:

• True isolation between containers and the PVE host
• Some networking assumptions Docker makes do not apply cleanly inside LXCs
• Snapshot and restore behavior can break on certain backup pipelines
• AppArmor regressions after major PVE updates have broken nested Docker in the past

A practical safety net is to keep privileged Docker-in-LXC setups confined to non-sensitive workloads. Lightweight self-hosted services that are not exposed to the internet are the realistic use case.

• Use the LXC path when your hardware cannot spare the memory for a full VM
• Use the LXC path when you want to share a GPU across several containers
• Use the LXC path for offline or home-only services that cannot hurt much if compromised
• Avoid the LXC path when the containers need to run anything that accesses the open internet

The PVE-host path: appealing in theory, awful in practice

Installing the Docker Engine directly on the Proxmox host is the third option, and it is the one almost every guide quietly tells you to skip. The reasons are not subtle:

• Docker creates its own iptables (the Linux kernel firewall rule manager) and bridge networking rules that can override or break PVE’s networking
• A PVE update that touches networking can suddenly break every container that was running fine yesterday
• Anything that compromises a container now has direct access to PVE, including every VM and LXC running on the host
• There is no clean rollback path, because the Docker install pollutes the host’s package set

The single appeal is that there is no overhead, and on a weak machine that argument sounds tempting until the first network break wipes out a weekend. Run Docker Engine on the Proxmox host only for the briefest of experiments, and never on a host that is also running real workloads.

Picking the right path for what you have

A simple decision tree works in practice:

• If your machine has 16GB or more of RAM and you want one home for everything, run Docker inside a VM
• If your machine has less than 8GB of RAM and you want to keep overhead low, run Docker inside an LXC
• If you need to share a GPU across several containers, run Docker inside an LXC and bind the device in
• If your services need to face the open internet, run Docker inside a VM with a real firewall in front
• If you are only experimenting for an afternoon, run Docker on the host and accept the mess

Hardware-tier shortcuts that hold up across most setups:

• Modern multi-core server with plenty of RAM: VM path wins on isolation, with no real performance penalty
• Recycled desktop or office PC from the last decade: LXC path wins because the VM path runs out of headroom
• Single-board computer like a Raspberry Pi 4 or 5: LXC path, with care taken to keep the workload small
• Multi-GPU or iGPU setup that needs shared access across containers: LXC path is the only sane way to share

A short setup checklist

Whichever path you pick, the day-one setup is the same:

• Update Proxmox to the latest stable before installing anything
• Decide the path before you start, not after you have deployed half a dozen containers
• Document the hostnames and IPs of any VMs or LXCs that run Docker, so backups find them
• Snapshot or back up the VM or LXC before running a major Docker version upgrade
• Keep one container home per use case if possible, so a clean rebuild does not touch other workloads

Trade-offs worth naming

Every option here carries a real cost. The VM path burns memory you might want to spend on the workloads themselves, and snapshotting a VM with hundreds of running containers can be slow if you have not tuned it. The LXC path takes more care to set up securely, and you will hit at least one networking quirk that wastes an afternoon. The PVE-host path is the worst of both worlds on a real machine, because you get none of the isolation and all of the risk of a host-side configuration change.

The honest framing is that none of these paths is wrong, but each is wrong for the wrong hardware. Pick based on what you actually have, document the choice, and revisit it if you upgrade the host or change the workload mix.

Bottom line

For most readers, the answer is going to be a VM on capable hardware and an LXC on older hardware, with the PVE-host option reserved for experiments that you are willing to roll back. Spend ten minutes thinking about the path before you start, and you will save yourself hours of debugging later. The Docker ecosystem does not care which path you pick, as long as you pick one and commit to keeping it clean.