Proxmox vs Docker: What to Run Where

You just built a Proxmox box, or inherited one, and now you want to run some Docker workloads on it. Every search result frames this as a choice — Proxmox or Docker — and that framing is wrong. It's the reason people end up either abandoning a working Proxmox install or trying to cram Docker into the wrong place.

They're not rivals — they're different layers

Proxmox and Docker solve two completely different problems, and comparing them head-to-head only makes sense if you first accept that they sit on top of each other, not next to each other.

Docker's own documentation describes it as "an open platform for developing, shipping, and running applications" that packages software "in a loosely isolated environment called a container" — see the Docker overview docs. That's an application concern.

Proxmox, by contrast, is concerned with hardware. It turns one physical server into many isolated virtual machines and containers. You almost never choose one instead of the other — you choose Proxmox to build the machine, then decide what runs on it, and Docker is usually part of that answer.

What Proxmox actually is

Proxmox Virtual Environment is a Type-1 (bare-metal) hypervisor — it installs directly on hardware, not inside another operating system. The current 9.x line is built on Debian 13 "Trixie", using KVM for full virtual machines and LXC for lightweight system containers, per Proxmox's own documentation.

Inside Proxmox you have two building blocks: a VM (a full virtual machine with its own kernel, booted like real hardware) and an LXC container (a lightweight "system container" that shares the Proxmox host's kernel but otherwise behaves like a small full OS, with its own init system, users, and services).

What Docker actually is

Docker is a container runtime for applications, not a hypervisor. A Docker container packages one app — say, a Django API or a Next.js frontend — along with its exact dependencies into an image, then runs that image as an isolated process that shares the host's kernel. Our introduction to Docker and first-container walkthrough cover the mechanics if you're new to it.

The mental model is different from a VM or an LXC system container: a Docker container is meant to be disposable. You don't patch it in place — you rebuild the image and replace the container. That's a deliberate design choice, not a limitation.

LXC vs Docker: both are containers, but not the same job

This is where the confusion actually lives, because "LXC" and "Docker" are both containers, and people assume interchangeable means identical.

LXC (Proxmox's system containers) are built to act like a lightweight full operating system: their own init process, their own systemd services, multiple long-running processes, persistent state you manage like a small VM. You'd use one to run, say, a full Samba file server or a Pi-hole install that behaves like a dedicated box.

Docker containers are built to run one process, be stateless by default, and be torn down and recreated constantly. You'd use Docker to run your app stack — a database, an API, a frontend — each as its own container, orchestrated with a compose file.

In my homelab: the real topology

Here's what I actually run, because the abstract version of this argument is less useful than the concrete one. This site's own infrastructure runs on a Proxmox host, and Docker never touches the bare metal directly. The layout looks like this:

1. Proxmox VE installed directly on the physical server — the bare-metal hypervisor layer.
2. A dedicated Debian VM, created and managed through Proxmox, with its own allocated CPU, RAM, and disk.
3. Docker and Docker Compose installed inside that VM — nothing Docker-related runs on the Proxmox host itself.
4. Application containers (API, database, frontend, reverse proxy) running as Docker Compose services inside the VM.
5. Everything web-facing sits behind a reverse proxy — see our Nginx vs Caddy vs Traefik vs HAProxy guide if you're picking one — exposed from that same VM.

The Proxmox host stays boring on purpose: it just runs VMs. All the app-level complexity — image builds, container restarts, dependency updates — lives inside the Docker VM, where it can't destabilize the hypervisor underneath it.

Should your Docker host be a VM or an LXC container?

This is the actual decision hiding behind "Proxmox vs Docker," and it deserves a straight answer.

A VM gives Docker its own full kernel, completely separate from the Proxmox host's kernel. That means proper isolation, clean live migration and snapshots, and no weird interaction between the host's kernel version and whatever Docker expects. It costs a bit more RAM overhead than an LXC would, but it's a small price for stability.

An LXC container shares the Proxmox host's kernel, so running Docker inside one requires enabling nesting features (`nesting=1`, sometimes `keyctl=1`) and, in many setups, running the container privileged. It can work for trusted, non-critical workloads, and it's lighter on resources.

If you're just experimenting, an LXC with nesting enabled is fine. If you're running anything you actually depend on — including a live website — put Docker in a VM.

Proxmox vs Docker: side-by-side by layer

Layer	Virtualization type	Isolation	Resource use	What it's for	Backup/snapshot
Proxmox	Type-1 hypervisor (KVM for VMs, LXC for system containers)	Hardware-level via KVM; kernel-shared via LXC	Heavier per VM, lighter per LXC	Running whole operating systems and infrastructure	VM snapshots + `vzdump` backups
Docker	Application container runtime	Process-level, shares the host kernel	Very light — containers start in seconds	Packaging and running one application per container	Image rebuilds + volume backups, not hypervisor snapshots

Read down the "what it's for" row and the whole argument collapses into one sentence: Proxmox runs machines, Docker runs apps.

Which one do you actually need?

If you're virtualizing hardware — splitting one server into several isolated OS instances — that's Proxmox's job. If you're packaging and running an application with its dependencies, that's Docker's job. In a real homelab you use both, layered: Proxmox creates the VM, Docker runs inside it. If you're still deciding on the hypervisor itself before you get to this question, our Proxmox vs VMware vs Hyper-V guide covers that first decision.

There's no scenario in a self-hosted homelab where "Docker instead of Proxmox" or "Proxmox instead of Docker" is really the right question. The right question is where in your Proxmox topology Docker should live — and for anything you care about staying up, that answer is a VM.

Frequently asked questions

Does Docker replace Proxmox?

No. Docker is an application container runtime; Proxmox is a bare-metal hypervisor. Docker needs an operating system to run on — in a Proxmox homelab, that operating system is usually a VM that Proxmox created.

Can I run Docker directly on the Proxmox host?

Technically yes, but it's not recommended. The Proxmox host is meant to stay dedicated to virtualization; running application containers directly on it mixes hypervisor and app-layer concerns and makes upgrades riskier. A dedicated VM keeps the two cleanly separated.

Is LXC the same as Docker?

No. Both are containers, but LXC builds lightweight full operating systems (with their own init system and services), while Docker packages a single application and its dependencies into a disposable, rebuildable image.

Should I use a VM or an LXC container for Docker on Proxmox?

Use a VM for anything you depend on staying up. A VM gives Docker a fully separate kernel and avoids the nesting and privileged-container issues that make Docker-in-LXC fragile across upgrades. LXC with nesting enabled is fine for low-stakes experiments.

Do I need Proxmox to run Docker at home?

No — Docker runs fine on a plain Linux install, a Raspberry Pi, or a single dedicated machine. Proxmox becomes useful once you want to run multiple isolated environments (a Docker VM alongside other VMs and services) on one physical box instead of buying separate hardware for each.