If everything you run is a container and you own one machine, install Debian and Docker and skip Proxmox entirely. The moment you need even one real VM — Home Assistant OS, an OPNsense router, TrueNAS with disks passed through, a Windows box — Proxmox earns its place, and the layout most homelabs converge on is: Proxmox on bare metal, one Debian VM holding all the Docker stacks, and a few LXC containers for infrastructure services. That costs roughly 2–5% CPU overhead and buys you snapshots, whole-system backups, and the ability to rebuild the Docker world without touching the hypervisor.

The three layouts, compared

LayoutOverheadBackup storyBest for
Debian + Docker on bare metalNoneYour own (restic + compose in git)Single box, containers only
Proxmox → Debian VM → Docker~2–5% CPU, RAM you allocateOne vzdump job covers everythingMixed workloads, tinkerers
Proxmox → LXC per appNear zeroPer-app vzdumpInfra services, GPU sharing

The first row is underrated. A well-organised compose setup on plain Debian is simpler than anything involving a hypervisor, and "simpler" is measured in what breaks at 11pm. Add Proxmox when you have a reason, not because homelab YouTube installs it by default.

Why the Docker-in-one-VM pattern won

KVM's overhead is small — a few percent of CPU and whatever RAM you commit to the guest — and in exchange the entire application layer becomes one object. vzdump (or better, Proxmox Backup Server) backs up the whole VM incrementally; PBS deduplication typically stores weeks of dailies in little more space than one full image. Before a risky upgrade you snapshot the VM and get a one-click rollback that covers every container, volume, and config inside it simultaneously — something Docker alone has no equivalent for. And when you eventually migrate hardware, you move one disk image instead of re-provisioning a host.

Give the VM most of the machine (on a 32GB host I allocate 24GB, leaving the rest for Proxmox and LXCs), use virtio for disk and network, and resist the urge to make three small VMs where one will do — each guest reserves RAM whether it uses it or not.

LXC: the middle ground, with one honest warning

LXC containers share the host kernel, so a Debian LXC running Pi-hole costs a few dozen MB of RAM and effectively no CPU — genuinely free isolation with per-container vzdump backups. They're the right home for small infrastructure that should survive your Docker VM's adventures: DNS, a reverse proxy, a WireGuard endpoint, monitoring. Keep them unprivileged (the default) and the isolation is respectable, though still kernel-shared — a VM remains the answer for anything you genuinely distrust.

The warning: running Docker inside LXC is popular and officially discouraged. It mostly works until a Proxmox kernel or AppArmor update changes something underneath, and the failure reports cluster around exactly those upgrade days. I ran that setup for a year and moved the Docker workload into a VM after the second mysterious breakage; the Proxmox documentation is politely firm that application containers belong in VMs. Use LXC for services installed natively via apt, not as a thinner Docker host.

The exception that keeps LXC in the conversation: iGPU sharing. A VM takes the GPU exclusively via passthrough, but multiple LXCs can share /dev/dri — so Jellyfin transcoding in one LXC and an ML workload in another can both use the same Intel iGPU, which no VM arrangement allows.

The decision tree, compressed

Work through these in order and stop at the first yes. Need Home Assistant OS, a router VM, TrueNAS, or any non-Linux guest: Proxmox. Want snapshot-and-rollback around risky changes, or one backup artifact for the whole lab: Proxmox. Expect a second node someday (clustering, migration): Proxmox. None of the above and everything is a container: plain Debian, and revisit in a year — converting later is an afternoon, not a rebuild, since the Debian host you have simply becomes the VM you restore into.

Layouts that work in practice

A single N100 mini PC serving media and a few apps: bare Debian and Docker; Proxmox would add a layer with nothing to manage. A 32GB ThinkCentre or tower doing real duty: Proxmox with a 24GB Debian VM for Docker stacks, LXCs for Pi-hole and the proxy, and a Home Assistant OS VM — this is the layout I run, and the snapshot-before-upgrade habit has paid for the setup cost several times over. Two boxes: same, plus Proxmox Backup Server on the second machine (or in a VM on it), which turns the 3-2-1 backup strategy for the system layer into a checkbox. Data-level backups remain your job either way — vzdump protects machines, not your photo library's off-site copy.

What I'd do

One machine, all containers: Debian, Docker, compose files in git, done. Anything more — a single VM-shaped workload, or just the itch to experiment safely — put Proxmox down first even if week one is nothing but one Debian VM at 90% of the RAM. The empty hypervisor costs a few percent and no ongoing attention, and it's the difference between "restore snapshot, breathe" and "reinstall weekend" the first time an upgrade goes sideways. LXC for apt-installed infrastructure and iGPU sharing, VMs for Docker and foreign OSes, and no Docker-in-LXC no matter how many forum posts say it's been fine so far.