Proxmox vs Docker: They're Not Rivals — What to Actually Run Where (2026)

Type “proxmox vs docker” into any search engine and you’ll find a decade of forum threads arguing about the wrong question. Proxmox VE and Docker are not competitors. Proxmox VE 9 is a Type-1 hypervisor — it owns your physical hardware and carves it into virtual machines and LXC containers. Docker is an application runtime — it packages a single app and its dependencies into a portable image and runs it. One is the foundation of your homelab; the other is something you run on that foundation. The real 2026 decision is not which to pick — it’s how to layer them: Docker inside a Proxmox VM, Docker inside an LXC, Proxmox-native LXC per service with no Docker at all, or (new this cycle) Proxmox’s own OCI container support.

This guide gives you the layered answer with the details the usual comparisons skip: what Proxmox’s documentation actually recommends (with the real quote, not the folklore), the ZFS storage-driver conflict that silently breaks Docker-in-LXC on most Proxmox hosts, where GPU passthrough really stands for each option, and a decision tree you can run your own setup through. If you’re still deciding between containers and VMs at the Proxmox layer itself, start with our LXC vs VM breakdown — this article picks up where that one ends.

What Proxmox VE actually is (2026)

Proxmox VE is a free, open-source (AGPLv3) Type-1 hypervisor, currently at version 9.2. In Proxmox’s own words, it “tightly integrates the KVM hypervisor and Linux Containers (LXC), software-defined storage and networking functionality, on a single platform.” In practice that means:

• Full KVM virtual machines — Windows, pfSense/OPNsense, Home Assistant OS, anything with its own kernel.
• LXC system containers — lightweight full-Linux-OS containers sharing the host kernel, each with its own IP and filesystem.
• A web UI, clustering, and snapshots — plus first-class Proxmox Backup Server integration for deduplicated, incremental backups of every VM and container.

The no-subscription repository makes it fully usable for homelab without paying anything.

What Docker actually is

Docker Engine is an application container runtime. It pulls OCI-format images (from Docker Hub or anywhere else), layers them onto a shared host kernel, and starts them in under a second. Its real superpower for self-hosters is the ecosystem: nearly every project you’d want to self-host publishes a docker-compose.yml, and Docker Compose turns a whole multi-service stack into one file and one command. What Docker is not: a hypervisor. It can’t run Windows, can’t give a workload its own kernel, and doesn’t manage your physical host. It also isn’t the only engine that runs OCI images — Podman does the same thing daemonlessly and rootless by default, which is a separate decision from the layering question here.

Why the question is framed wrong

Because the two tools sit at different layers, “Proxmox vs Docker” really decomposes into two separate questions:

1. Should my bare metal run Proxmox? For almost any homelab beyond a single-purpose box: yes. Even if you only ever run Docker, putting Proxmox underneath costs you a few percent overhead and buys you snapshots, easy reinstalls, backups, and the freedom to add a VM later. (If you are weighing that hypervisor choice against VMware, the Proxmox vs ESXi breakdown covers why the free tier lands on Proxmox after Broadcom.)
2. How should Docker run on that host? This is the decision with real trade-offs — and it’s the rest of this article.

The four ways to run containers on Proxmox

The Docker-in-LXC debate: what Proxmox actually says

The claim you’ll see everywhere is “Proxmox officially discourages Docker in LXC.” The reality is more precise. There is no wiki page banning it (the oft-cited Docker_on_LXC page simply doesn’t exist), but the official Proxmox documentation does take a position — quoted in Proxmox’s own forum best-practices thread:

“…it is recommended that you run them inside a Proxmox QEMU VM. This will give you all the advantages of application containerization, while also providing the benefits that VMs offer, such as strong isolation from the host and the ability to live-migrate.”

So: a recommendation toward VMs, not a prohibition of LXC. In homelab practice, Docker inside an LXC with features: nesting=1 (add keyctl=1 for some workloads) runs reliably for trusted, internal services — that’s the long-standing consensus across the Proxmox forums and communities like LearnLinuxTV.

The famous ZFS gotcha — now mostly historical. For years, Docker’s default overlay2 storage driver didn’t support ZFS backing filesystems, so Docker inside an LXC on a ZFS-backed Proxmox host fell back badly out of the box, and the community fix was switching to fuse-overlayfs. OpenZFS 2.2 changed this: it added native overlayfs support, so on Proxmox VE 8.1+ (and PVE 9, which ships OpenZFS 2.3) overlay2 simply works in an LXC on ZFS. If you’re on an older pool or you see overlay errors, fuse-overlayfs remains the fallback — or skip the whole question and run Docker in a VM, where the guest’s ext4 makes it a non-issue.

Backup reality: where each option wins

This is the most under-weighted factor in every comparison we read, and it’s where the layered setup pays off:

• Docker in a VM + PBS — Proxmox Backup Server snapshots the entire VM: Docker Engine, every container, every named volume, all application data. Restoring your whole stack after a bad upgrade is one operation. This is the best backup story in self-hosting.
• LXC (native or with Docker) + PBS — also good: PBS backs up the full container.
• Docker on bare metal — you own the problem: volume-by-volume backups with tar jobs or Restic, plus the compose files, plus remembering how it all fit together. It works, but it’s the reason bare-metal Docker hosts tend to be rebuilt rather than restored.

GPU passthrough: which setup actually works

• VM + VFIO — the reliable path. Pass the full GPU to a VM (our step-by-step guide), then install Docker plus the NVIDIA Container Toolkit inside it. This is the standard setup for Ollama, Stable Diffusion, Jellyfin/Plex hardware transcode.
• LXC + device bind mount — contrary to what some comparison pages claim, LXC GPU access does exist: you bind-mount the /dev/nvidia* devices and match driver versions between host and container. It works for CUDA workloads and it’s lighter than a VM — but it’s a different mechanism from VFIO, it couples the container to host driver versions, and it’s more fragile across upgrades.
• Docker bare metal — works, but again forfeits the hypervisor’s snapshot/backup layer around it.

What about Proxmox 9’s native OCI support?

New since PVE 9.1: you can create LXC containers directly from OCI images — the same image format Docker uses. Per the official release notes, creating system containers from suitable OCI images is supported, while application containers from OCI images are explicitly a technology preview. There is no Compose equivalent, no orchestration, and no ecosystem around it yet. It’s a genuinely interesting direction — one image standard across your whole stack — but in mid-2026 it is not a Docker replacement for a real homelab. Watch it; don’t build on it.

The honest decision tree

Run your setup through this, top to bottom:

1. Need Windows, pfSense, Home Assistant OS, or any non-Linux workload? You need Proxmox VMs regardless. Docker slots in as one more VM.
2. GPU-accelerated containers (LLMs, Stable Diffusion, transcoding)? Docker in a VM with VFIO passthrough.
3. Want one-step restore of your whole stack, data included? Docker in a VM, backed up by PBS.
4. Proxmox host on ZFS and set on Docker-in-LXC? On PVE 8.1+ (OpenZFS 2.2+) overlay2 works natively; on an older pool, use fuse-overlayfs inside the container — and know why.
5. Under 16 GB of RAM and every megabyte counts? Docker in an LXC with nesting=1 for trusted, internal-only services is a legitimate choice — size it with our Docker RAM planner.
6. Just running a handful of single Linux services (DNS, reverse proxy, monitoring)? Proxmox-native LXC per service, no Docker needed — lowest overhead, per-service IPs, clean PBS backups.

Most homelabs end up hybrid: a couple of native LXCs for infrastructure services, one Docker VM for the Compose stacks, and headroom for the odd full VM. If that’s where you land, our Docker Compose starter stack fills the Docker VM in about half an hour, and the Proxmox capacity planner tells you how much host you actually need.

Bottom line

Proxmox and Docker answer different questions. Proxmox decides how your hardware is divided; Docker decides how applications are packaged. Put Proxmox on the metal, put Docker in a VM on top of it (or in an LXC if you know the trade-offs and your storage driver), and you get the ecosystem of Docker with the snapshots, backups, and flexibility of a real hypervisor underneath. That layered setup — not a winner-take-all choice — is why the “vs” framing never quite made sense.