Proxmox vs Docker Decision Guide (2026): the worksheet and decision tree for placing every workload

Why a Proxmox vs Docker decision guide, and not another comparison article

Most "Proxmox vs Docker" articles, including our own comparison of Proxmox and Docker in 2026, explain what each platform is and when to use it. That is the right place to start. It is not enough when you sit down with a list of forty services and have to decide, one by one, where each of them will live on Monday morning. That is where teams stall, and where the expensive mistakes happen: a database in a container that cannot move during maintenance, a regulated workload sharing a Docker host with a test app, a Compose stack forced into an LXC container because a forum post said it saves memory.

This guidebook is the working toolkit for that moment. It turns the comparison into a repeatable process: a decision tree that places one workload in under a minute, a worksheet that records the answer and the reason for it, two reference layouts to sanity-check the result, and a hardening checklist that applies whichever options you pick. You can print the worksheet, fill it in with the people who own each service, and walk out with a placement plan everyone agrees on.

It was written by the engineering team at Petronella Technology Group, Inc., which has designed and supported business infrastructure since 2002 and runs more than ten production AI agents on infrastructure it operates itself. The placement rules in the guide are the ones we use on our own hardware and on client builds.

What is inside the Proxmox vs Docker decision guide

Eleven short sections, designed to be read in order the first time and used out of order after that.

What changed for Proxmox and Docker in 2026

If your notes or runbooks were written before 2026, several of their assumptions are out of date. The guide opens with this table so the rest of it reads against the current platforms.

The practical consequence: a host still on Proxmox VE 8 no longer receives fixes, so upgrading to version 9 is now a security task rather than a feature choice. And the new OCI support is a preview, not a reason to move production Docker stacks onto the Proxmox host.

The four placement options the guide compares

A full virtual machine

A KVM/QEMU virtual machine has its own kernel and virtual hardware. It runs Windows, BSD, appliances and any Linux distribution, and on a cluster with shared or replicated storage it can be live-migrated between nodes while it keeps running. The cost is overhead: every VM carries a full operating system and its own memory. The guide uses the VM as the default whenever the decision tree cannot place a workload with confidence, because moving a service from a VM into a container later is easy, and moving it the other way under pressure is not.

An LXC system container

An LXC system container shares the Proxmox host kernel and runs a complete Linux userland with its own init system, so it behaves like a small Linux server with far less overhead than a VM. Unprivileged containers, which are the default for new containers in Proxmox VE, map root inside the container to an unprivileged user on the host. The limit that matters most for placement: according to the Proxmox container documentation, running containers cannot be live-migrated. Proxmox performs a restart migration instead, which the documentation says normally costs downtime of some hundreds of milliseconds.

Docker inside a virtual machine

Install Docker Engine in a Linux VM and run your images and Compose stacks there. You keep the whole Docker toolchain and gain the VM's isolation, snapshots and live migration. The Proxmox documentation itself says that for use cases demanding maximum isolation and the ability to live-migrate, nesting containers inside a Proxmox QEMU VM remains a recommended practice. For most production container workloads, this is where the decision tree lands.

OCI application containers (technology preview)

Since Proxmox VE 9.1, an OCI image, the image format Docker and other tools publish, can be pulled or uploaded and turned into a container. Proxmox converts it to its LXC stack, so the Docker engine is not involved: Compose files, Docker networks and the docker command line do not apply. Proxmox labels running application containers this way a technology preview. The guide treats the option as something to evaluate in a lab, not as production infrastructure yet.

The guide also answers the question almost every homelab reader asks next: can you run Docker directly inside an LXC container? You can, but it requires the nesting and keyctl container features, which the Proxmox documentation says expose host procfs and sysfs contents and force a choice between systemd-networkd and Docker. We explain why we treat it as a homelab convenience rather than a production pattern.

A preview of the decision tree

The tree asks seven questions in order and stops at the first answer that places the workload. Here are the first four, so you can judge whether the rest is worth your time.

1. Does it need a non-Linux operating system, its own kernel, or custom kernel modules? If yes, it goes in a VM.
2. Does it handle regulated or high-risk data, such as CUI, PHI or payment data, or face the internet directly? If yes, it goes in a VM, or in Docker inside a dedicated VM if it ships as images, because that boundary is stronger and simpler to document for an assessor.
3. Must it keep running while you patch or move a host, with no restart window at all? If yes, it belongs in a VM or a Docker VM on a cluster that can live-migrate, because LXC containers cannot.
4. Is it distributed as a Docker image or a multi-container Compose file? If yes, Docker inside a VM.

Questions five through seven separate the long-lived Linux services that fit an unprivileged LXC container from the lab-only candidates for OCI application containers, and set the default for anything still undecided. Each answer in the PDF comes with the reason, so the worksheet records not only where a service runs but why.

How the workload placement worksheet works

The worksheet has one row per service and five yes-or-no columns: non-Linux or own kernel, regulated data or internet-facing, zero restart window, ships as a Docker image or Compose file, and GPU or device passthrough. Seven placement rules are applied in order and the result goes in the final column. Three worked examples are filled in to show the pattern: an internal wiki that ships as a Compose file lands in a Docker VM, a DNS resolver lands in an unprivileged LXC container, and a file server holding controlled unclassified information lands in its own VM.

Two rules in the worksheet prevent the most common mistakes we see. Regulated workloads always get their own VM and never share a Docker host with general applications. And GPU workloads that need a whole device usually go in a VM with PCI passthrough, while container device sharing is reserved for several trusted services that must share one card. Keep the completed sheet with your system documentation: it doubles as the record of why each service runs where it does, which is exactly what an auditor or a new engineer will ask for.

An excerpt from the LXC vs Docker comparison table

The full table in the guide has eleven rows across all four options. Here are four of them.

Sources: Proxmox VE Administration Guide, container chapter; Proxmox VE Roadmap. The backup row reflects the documented vzdump behavior that bind mount points and device mount points are not backed up.

Two reference layouts: homelab and production

Single-node homelab or small office lab

One host running Proxmox VE 9.2 with the firewall enabled and two-factor authentication on the admin login. One Linux VM runs Docker Engine 29 and holds every Compose stack, so all of them can be snapshotted and backed up as a unit. Always-on network services such as DNS, a reverse proxy and monitoring run as unprivileged LXC containers. Backups go to a separate disk or NAS, with an off-box copy. With one node there is no high availability, so the guide tells you to plan for restart downtime during host updates.

Three-node production cluster with Proxmox Backup Server

Three nodes, which the Proxmox high availability documentation lists as the minimum for reliable quorum, with shared or replicated storage, redundant power and network, and a dedicated cluster network. Tier 1 workloads and anything handling regulated data get their own VMs. Docker hosts are split by trust zone, never mixing regulated and general workloads. Proxmox Backup Server runs on separate hardware with client-side encryption, remote sync to a second site and scheduled verification. If you are building this, our Proxmox cluster setup guide and Proxmox Backup Server configuration guide cover the build steps.

Backup and high availability: the parts people miss

Two details from the official documentation cause most of the surprises we see after a failure. First, vzdump does not back up the contents of bind mount points or device mount points on a container. If a container keeps its data on a path bind-mounted from the host, that data needs its own backup job. Second, high availability restarts a failed guest on another node. For an LXC container that is always a restart, never a live move, so a service that cannot tolerate even a short restart belongs in a VM and may also need application-level redundancy.

The guide summarizes what Proxmox Backup Server provides according to its documentation: incremental backups that send only changed data, deduplication, client-side encryption with AES-256 GCM, SHA-256 integrity checks, efficient remote sync of deltas to another site, and tape support for long-term archives. It also lists the documented HA prerequisites: at least three nodes, shared storage, hardware redundancy, reliable server components and a watchdog for fencing.

What the security hardening checklist covers

The checklist is split into host and cluster, containers, Docker hosts, and backup and recovery. A few items show the flavor:

• Turn the Proxmox firewall on. The Proxmox firewall documentation states it is completely disabled by default.
• Require two-factor authentication for every administrator. Proxmox VE supports TOTP, WebAuthn security keys and YubiKey OTP, plus single-use recovery keys.
• Use unprivileged containers only. The Proxmox documentation says privileged containers should only be used in trusted environments.
• Limit who controls the Docker daemon. Docker's security documentation says the daemon requires root privileges unless you opt in to rootless mode, and that only trusted users should be allowed to control it.
• Do not rely on ufw in front of Docker. Docker's firewall documentation explains that published container ports are routed before ufw rules apply, effectively bypassing them.
• Encrypt backups on the client and test restores. Keep keys off the cluster and restore something at least once a quarter.

The checklist is a technical baseline. Mapping it to CMMC, HIPAA or NIST SP 800-171 depends on your scope; our team does that mapping as part of CMMC compliance engagements.

If you are leaving VMware

Many readers arrive here in the middle of a VMware exit. Proxmox VE includes an integrated importer that adds an ESXi host as an import source and walks each VM through a guided import. The official Proxmox migration documentation says import was tested from ESXi 6.5 up to 8.0, recommends installing VirtIO drivers in the guest before migrating, asks you to power the VM down on the source for a consistent state, warns that VMs with snapshots import significantly slower, and notes that vTPM state cannot be migrated from VMware.

The migration is also the cheapest moment to re-place workloads. Run the decision tree on every VM you move: some will stay VMs, some will become LXC containers or Docker stacks. For the full walkthrough, read our VMware to Proxmox migration guide and the step-by-step ESXi to Proxmox VE migration, or see our VMware to Proxmox migration service.

Who this guide is for

IT managers and systems engineers standardizing a small or mid-sized Proxmox environment will get the most from the worksheet and the production layout. Teams moving off VMware can use it to re-place workloads during the migration instead of copying every VM across as it was. Homelab builders will find the single-node layout and the honest treatment of Docker inside LXC useful. Compliance leads at defense contractors and healthcare organizations can use the placement rules and hardening checklist as a starting point for the evidence an assessor expects, alongside the scoped assessment that formal readiness still requires.

If you are building private AI on the same hardware, the placement rules apply to GPU hosts and model serving too; our Private AI Infrastructure Blueprint covers that build in depth, and our on-premise AI page describes how we deploy it.

Frequently asked questions

Is the Proxmox vs Docker decision guide free?

Yes. We ask for your first name and a work email, and the PDF opens in your browser as soon as you submit the form. There is no charge and no sales call required.

How do I get the PDF after I submit the form?

An "Open the PDF" button appears in the form box right after you submit. The link works in the same browser for 24 hours, so save a copy to your computer. If anything goes wrong, call Penny at 919-348-4912 and we will send it to you.

Can Proxmox run Docker containers?

Yes, in three ways: Docker Engine inside a Proxmox VM, which is the pattern the Proxmox documentation recommends for maximum isolation and live migration; Docker inside an LXC container with the nesting and keyctl features enabled; and, since Proxmox VE 9.1, OCI images converted into LXC containers, which Proxmox labels a technology preview and which does not use the Docker engine.

Should I use LXC or Docker on Proxmox?

Use an unprivileged LXC container for a single long-lived Linux service you would install with a package manager. Use Docker inside a VM for anything that ships as a Docker image or a multi-container Compose file. The decision tree in the guide makes that call one service at a time.

Do the new OCI application containers replace Docker?

Not today. Proxmox converts OCI images to LXC containers and calls running application containers this way a technology preview. There is no Docker engine in the path, so Compose files and Docker networks do not apply. The guide recommends lab evaluation only until the feature leaves preview.

Is my Proxmox VE 8 host still supported?

No. Proxmox VE 8 reached end of support on 31 August 2026, according to the Proxmox support lifecycle announcement. Plan an upgrade to Proxmox VE 9; version 9.2 was released on 21 May 2026.

Can LXC containers live-migrate between Proxmox nodes?

No. The Proxmox documentation says running containers cannot be live-migrated due to technical limitations. A restart migration shuts the container down, moves it and starts it on the target node, normally with downtime of some hundreds of milliseconds.

How many nodes do I need for Proxmox high availability?

The Proxmox high availability documentation calls for at least three cluster nodes to get reliable quorum, plus shared storage, hardware redundancy and a watchdog for fencing. The production reference layout in the guide is built on those requirements.

Does the guide cover CMMC or HIPAA requirements?

It includes a hardening checklist and placement rules for regulated data, and it notes where they support compliance evidence. It is a technical baseline, not a compliance determination. Petronella Technology Group, Inc. is a Cyber AB Registered Provider Organization (RPO #1449) and serves CMMC Level 3 clients, so if you need the mapping done for your scope, call us.

Can Petronella Technology Group, Inc. build or migrate this for us?

Yes. We design and build Proxmox VE clusters, migrate from VMware, set up Proxmox Backup Server, harden and document the environment, and operate it afterward. Call Penny at 919-348-4912 or use our contact page.

Work with Petronella Technology Group, Inc.

Petronella Technology Group, Inc. has built and supported business infrastructure in Raleigh, North Carolina since 2002. Our Proxmox enterprise services cover architecture reviews, cluster builds, VMware migrations, backup design and managed operations, and our managed IT services keep the environment patched and monitored afterward. Our team includes CMMC Registered Practitioners, and we document the environment for the assessments our clients face.

More reading: the Proxmox licensing explainer, our VMware alternative overview, data center virtualization, and the full resources library.