00:00:14 --> 00:00:26
Proxmox versus Docker is one of those questions that keeps coming up for anyone running servers this year. On the surface they look like competitors. So let me start with the obvious one: can Proxmox run Docker?
00:00:27 --> 00:00:44
Yes, it can, but it does not ship Docker. Proxmox V E is a hypervisor that runs virtual machines and L X C system containers. Docker is an application container runtime. They sit at different layers, and in practice most mature stacks end up running both.
00:00:45 --> 00:00:49
So if they are not really competitors, what is the actual decision people are making?
00:00:49 --> 00:01:03
The decision is which workloads belong in which container model, and how the two layers fit together when you run them in the same rack. Proxmox is infrastructure. Docker is application packaging. The question is not which one to pick.
00:01:04 --> 00:01:06
Give me the short version for someone who only has a minute.
00:01:06 --> 00:01:33
Most production shops run Docker inside a Proxmox virtual machine. Not on the Proxmox host directly, and not nested inside an unprivileged L X C container. That is the boring, supportable answer, and the Proxmox documentation agrees. For maximum isolation and live migration, nesting containers inside a Proxmox Q E M U virtual machine remains a recommended practice.
00:01:33 --> 00:01:40
Boring and supportable. I like that. Before we get into the patterns, what changed in 2026?
00:01:41 --> 00:01:54
Four things. First, Proxmox V E eight is out of support. The Proxmox support lifecycle lists its end of life as August 2026. Second, Proxmox V E nine point two is current.
00:01:54 --> 00:01:56
When did nine point two come out?
00:01:56 --> 00:02:09
May twenty-first, 2026. It is built on Debian thirteen point five, which is the release called Trixie, with the Linux seven point zero kernel. That comes from the Proxmox V E roadmap.
00:02:09 --> 00:02:10
And the other two changes?
00:02:11 --> 00:02:32
Third, Proxmox V E nine point one, released November nineteenth, 2025, added the ability to create L X C containers from O C I images. Application containers that way are a technology preview. Fourth, Docker Engine twenty-nine made the containerd image store the default for fresh installs.
00:02:32 --> 00:02:36
Let's take Proxmox first. What is it, actually, in 2026?
00:02:37 --> 00:02:57
Proxmox V E nine point two is a type one hypervisor. It runs on bare metal. It uses K V M and Q E M U for virtual machines, L X C for system containers, Z F S and Ceph for storage, Corosync for clustering, and it gives you a web interface plus a REST A P I for management.
00:02:57 --> 00:03:02
You mentioned O C I images. That is the same format Docker uses, right?
00:03:02 --> 00:03:17
Right, it is the same image format Docker uses. But this is where people get confused. An O C I based container on Proxmox is still an L X C container. It does not run the Docker engine and it does not read a Compose file.
00:03:17 --> 00:03:22
We will come back to that. Why are so many shops looking at Proxmox this year in the first place?
00:03:22 --> 00:03:41
The post-Broadcom VMware licensing wave. A lot of shops that ran vSphere for a decade are now migrating to Proxmox because the per-socket licensing math broke. Proxmox V E itself is open source and free. The paid subscription is for the enterprise repository and support.
00:03:41 --> 00:03:45
Now Docker. What is Docker Engine in 2026?
00:03:45 --> 00:04:03
Docker Engine twenty-nine is an evolution of the same userland container runtime that has powered application deployment for a decade. Release twenty-nine point eight point one shipped September fifteenth, 2026, according to the Docker Engine twenty-nine release notes.
00:04:03 --> 00:04:05
What changed in the twenty-nine line itself?
00:04:06 --> 00:04:22
Engine twenty-nine point zero, from November tenth, 2025, made the containerd image store the default for fresh installs and marked C group version one as deprecated. And BuildKit is the default builder for Docker Engine and Docker Desktop users.
00:04:22 --> 00:04:26
And the thing people forget: Docker is not a hypervisor.
00:04:26 --> 00:04:44
Correct. It does not virtualize hardware. It packages a single process plus its dependencies and runs that image on any Linux kernel. It shares the host kernel through namespaces and C groups, and lets each container believe it has its own filesystem, network, and process tree.
00:04:44 --> 00:04:45
Which is why it is fast.
00:04:45 --> 00:04:57
Fast and dense. It also means a kernel exploit inside a container can theoretically reach the host. That is why kernel isolation matters more for some workloads than others.
00:04:57 --> 00:05:01
Let's get practical. How do you actually run containers on Proxmox?
00:05:01 --> 00:05:14
There are three established patterns, plus a fourth that arrived with Proxmox V E nine point one and is still a technology preview. They trade off security, performance, and operational sanity differently.
00:05:14 --> 00:05:15
Pattern one.
00:05:15 --> 00:05:39
Pattern one is Docker inside a Proxmox virtual machine, and it is the one we recommend for production. You stand up an Ubuntu Server twenty-four oh four L T S virtual machine, or a Debian thirteen Trixie virtual machine, which is the same Debian release Proxmox V E nine is built on. You install Docker Engine inside it and run all your containers there.
00:05:39 --> 00:05:40
Why is that the safe answer?
00:05:41 --> 00:05:57
Because the virtual machine gives you a real kernel boundary. If a container compromises the kernel, it compromises the virtual machine's kernel, not the Proxmox host. You also get live migration, backup snapshots, and clean rollback through Proxmox Backup Server.
00:05:57 --> 00:05:58
What does it cost you?
00:05:59 --> 00:06:11
Roughly five to ten percent of host RAM overhead per virtual machine, and a few seconds of boot time. For anything client-facing, regulated, or hosting paying users, this is the answer.
00:06:11 --> 00:06:12
Pattern two.
00:06:12 --> 00:06:28
Native L X C system containers. These are system containers, not application containers. They look and behave like lightweight virtual machines that share the host kernel. Boot times are sub-second, RAM overhead is minimal, and density is high.
00:06:28 --> 00:06:29
What would you put in one?
00:06:30 --> 00:06:41
Internal services where you control the workload end to end. A Pi-hole, a Plex server, a Home Assistant instance, a Postgres replica for a dev environment. Things like that.
00:06:42 --> 00:06:43
And what would you keep out of one?
00:06:43 --> 00:06:52
Multi-tenant or untrusted workloads. Unprivileged L X C is the default and it is sane, but the security model is still kernel-shared.
00:06:53 --> 00:06:55
Pattern three is the one where experts disagree.
00:06:55 --> 00:07:12
Docker inside L X C. You can run Docker inside an unprivileged L X C container on Proxmox. It needs the nesting feature, and the Proxmox container documentation notes that the key C T L feature is required for Docker in an unprivileged container.
00:07:13 --> 00:07:13
What is the case for it?
00:07:14 --> 00:07:19
Density. You skip the virtual machine kernel, so more workloads fit per host.
00:07:19 --> 00:07:20
And the case against?
00:07:20 --> 00:07:40
It is layered. Two container runtimes, L X C plus run C, harder debugging, single-layer kernel isolation, tangled AppArmor and seccomp profiles, and upgrade risk. The Proxmox V E nine upgrade notes list a known issue with nested containerization, such as Docker inside L X C.
00:07:40 --> 00:07:41
So where do you land?
00:07:41 --> 00:07:47
Fine for a homelab or non-critical internal tools. Never for anything regulated.
00:07:47 --> 00:07:48
Pattern four is the new one.
00:07:48 --> 00:08:13
O C I images as L X C containers, Proxmox V E nine point one and later, technology preview. You can pull an image from an O C I registry, such as Docker Hub, with the Pull from O C I registry button on a storage's container template view, then create a container from it with the wizard or with p c t create. Proxmox converts the image to its own L X C stack.
00:08:13 --> 00:08:15
Does that work for everything on Docker Hub?
00:08:15 --> 00:08:29
According to the Proxmox container documentation, it works for system containers built from suitable O C I images. Running single-purpose application containers this way is currently a technology preview.
00:08:29 --> 00:08:31
So what do you get, and what don't you get?
00:08:32 --> 00:08:50
You get one image managed like any other Proxmox guest, with no Docker daemon. You do not get Docker. No Docker engine, no docker compose, no Docker networks or named volumes. The Proxmox roadmap lists Compose Specification support as a future goal, not a shipped feature.
00:08:50 --> 00:08:52
So it is a lab feature for now.
00:08:52 --> 00:08:58
Try pattern four for a single service in a lab. Keep production Compose stacks on pattern one.
00:08:58 --> 00:09:02
The post has a comparison table. Walk me through the numbers that matter.
00:09:02 --> 00:09:19
Boot time first. A Proxmox virtual machine takes ten to sixty seconds. L X C, the O C I preview containers, and Docker are all sub-second. RAM overhead is five to ten percent per virtual machine, and minimal for the three container options.
00:09:19 --> 00:09:20
And density per host?
00:09:21 --> 00:09:32
Virtual machines are lower, ten to thirty per host is typical. L X C is high, fifty to a hundred or more containers. Docker is the highest, hundreds of containers.
00:09:32 --> 00:09:33
And GPUs?
00:09:34 --> 00:09:46
Virtual machines support full P C I e passthrough. L X C and the O C I containers are limited, through the device C group. Docker needs the NVIDIA Container Toolkit.
00:09:46 --> 00:09:51
People search for Proxmox containers versus Docker. Is that really a fair comparison?
00:09:51 --> 00:10:14
It is really L X C versus Docker. Same kernel features, different jobs. An L X C container is a system container. It boots an init system, runs several services, and is patched with apt like a small server. A Docker container is an application container. It runs one process from an immutable image and keeps state only in attached volumes.
00:10:14 --> 00:10:16
Is there a rule of thumb?
00:10:16 --> 00:10:26
A simple one. If you would treat the workload as a small server, use L X C. If you would treat it as a build artifact, use Docker, and put Docker in a virtual machine.
00:10:26 --> 00:10:31
That brings us to the real question. How should an organization actually decide?
00:10:31 --> 00:10:43
When clients ask us Proxmox or Docker, we walk through seven questions before we recommend a topology. Answer each one for the workload in front of you, and the right architecture usually picks itself.
00:10:43 --> 00:10:44
Question one.
00:10:44 --> 00:11:04
What is the workload? A stateless web app, an internal A P I, a database, a legacy Windows virtual machine, and a GPU inference job each want different layers. Stateless apps love Docker. Stateful regulated workloads love virtual machines. Mixed operating system environments want Proxmox.
00:11:05 --> 00:11:05
Question two.
00:11:06 --> 00:11:28
What is the isolation requirement? Multi-tenant software as a service, defense contractor C U I, healthcare P H I, and payment data all need kernel-level isolation. That means virtual machines, not shared-kernel containers. If you can honestly say this workload trusts every other workload on the host, shared-kernel containers are fine.
00:11:28 --> 00:11:29
Question three.
00:11:29 --> 00:11:50
How does state persist? Docker containers are designed to be ephemeral. Persistent state in Docker means named volumes, bind mounts, or external storage. Virtual machines and L X C containers persist by default. If your team is new to container workflows, the persistence model is where the friction usually shows up.
00:11:50 --> 00:11:50
Four.
00:11:51 --> 00:12:11
How complex is the networking? Single host, single subnet, a handful of containers, and Docker networking is fine. Multi-host service mesh, cross-availability-zone traffic, granular firewall policies, and you are looking at Kubernetes networking plugins, or virtual machine based segmentation with Proxmox S D N.
00:12:11 --> 00:12:13
Five sounds like the one people skip.
00:12:14 --> 00:12:31
What does your team already know? Skill mismatch kills more deployments than technology choice. A team fluent in vSphere will land on Proxmox naturally. A team that has shipped on Heroku or Fly dot io will land on Docker naturally. Pick the layer your team can operate at two in the morning.
00:12:32 --> 00:12:35
Two in the morning is the real test. Six?
00:12:35 --> 00:12:53
Single host or multi-host? One server, one rack, either tool works. Multi-host with high availability, live migration, and shared storage, and Proxmox handles the infrastructure layer. Docker needs Swarm, Kubernetes, or Nomad on top to handle the same problems.
00:12:53 --> 00:12:54
And seven.
00:12:54 --> 00:13:16
Do you need GPU passthrough? Full GPU passthrough for A I training and large inference jobs is cleaner on Proxmox virtual machines with P C I e passthrough. GPU sharing across many containerized inference workloads is cleaner with Docker plus the NVIDIA Container Toolkit. Our own private A I cluster does both.
00:13:16 --> 00:13:20
So once you have answered those, what does the finished design usually look like?
00:13:20 --> 00:13:43
The pattern we deploy most often for clients is layered. Proxmox V E on the bare metal. A small number of purpose-built virtual machines on top: one for Docker workloads, one for the database, one for the management plane, one for the firewall or reverse proxy. Then Docker Compose, or a small Kubernetes, inside the application virtual machine.
00:13:43 --> 00:13:45
Where do backups sit in that picture?
00:13:45 --> 00:14:01
Proxmox Backup Server runs on a separate appliance and backs up everything at the virtual machine level. Containers inside the virtual machine are rebuilt from images on demand. Only data volumes and configuration are treated as precious.
00:14:01 --> 00:14:06
Let's talk about backup a bit more, because that is where you said the two platforms differ the most.
00:14:06 --> 00:14:20
They diverge most sharply there. Proxmox Backup Server is mature, deduplicated, incremental, encrypts at rest, and ships with verify-on-restore. It backs up virtual machines and L X C containers as units.
00:14:20 --> 00:14:21
And Docker?
00:14:21 --> 00:14:34
Docker has no equivalent first-party tool. You pin image versions in your compose file or Helm chart, you back up named volumes with restic or duplicity, and you treat the running container as disposable.
00:14:35 --> 00:14:36
Where do teams get that wrong?
00:14:36 --> 00:14:52
Most teams that get it wrong treated Docker volumes as production storage without a backup plan. If you operate Docker on Proxmox, the cleanest pattern is to let Proxmox Backup Server snapshot the host virtual machine, and treat that as your backup of record.
00:14:53 --> 00:14:57
Let's do some of the questions people ask most. Can Docker replace Proxmox?
00:14:58 --> 00:15:14
No. Docker is an application container runtime, not a hypervisor. If you need to run virtual machines, mixed operating system workloads, or hardware-isolated tenants, you need a hypervisor. Proxmox is one. Docker does not replace it.
00:15:14 --> 00:15:18
If I am migrating off VMware, is the move to Proxmox or to Docker?
00:15:19 --> 00:15:38
Proxmox is the like-for-like replacement. Docker is not a hypervisor, and it cannot host the Windows guests and legacy virtual machines that most VMware migrations involve. Run Proxmox where vSphere was, then layer Docker on top inside the Linux virtual machines where it makes sense.
00:15:38 --> 00:15:45
Here is one for defense contractors and healthcare practices. Does C M M C or HIPAA mandate one over the other?
00:15:45 --> 00:16:01
Neither framework names a specific technology. Both demand documented controls around access, audit logging, encryption, and isolation. Proxmox virtual machines make some of those controls easier to demonstrate because the boundaries are clearer.
00:16:01 --> 00:16:03
So Docker is not ruled out.
00:16:03 --> 00:16:19
Not at all. Docker can absolutely meet the same controls when configured carefully, but the audit story takes more work. We help defense contractors and healthcare clients map either stack to C M M C Level one, Level two, Level three, and HIPAA controls.
00:16:20 --> 00:16:25
How does Petronella Technology Group, Inc. sort a client's environment when you are asked to design one?
00:16:25 --> 00:16:59
We walk the seven questions against every workload and sort each one into three buckets. Regulated and stateful, like defense contractor C U I enclaves, healthcare E H R systems, and financial reporting databases, land on Proxmox virtual machines. Trusted internal services, like monitoring, internal dashboards, and C I runners, land on L X C or on Docker inside a virtual machine. Stateless application workloads, like web stacks, A P Is, and A I inference, land on Docker.
00:16:59 --> 00:17:01
What do you insist on before anything goes live?
00:17:02 --> 00:17:10
We document the topology, the backup recovery time objective, and the rollback path in writing before we ship anything to production.
00:17:10 --> 00:17:12
So if you had to put the whole thing in a few sentences?
00:17:13 --> 00:17:24
Proxmox is the hypervisor layer. Docker is the application layer. Most teams that pick one and ignore the other end up rebuilding the other layer badly inside the one they picked.
00:17:24 --> 00:17:25
So which one do you pick?
00:17:26 --> 00:18:05
Pick Proxmox when you need infrastructure-grade isolation, multi operating system support, live migration, and backup as an appliance. Pick Docker when you need fast application deploys, immutable images, and dense application workloads. And pick both when you operate anything serious, and run Docker inside Proxmox virtual machines as the default starting topology. In 2026, with Proxmox V E eight out of support, O C I images arriving in Proxmox V E nine as a preview, and the VMware migration wave still rolling, the case for running both layers is stronger than it has ever been.
00:18:05 --> 00:18:19
And for anyone who wants all of this in one place, there is a free decision guide that collects the seven questions, the four container patterns, and the comparison tables in one printable file. It is linked from the article in the show notes.
00:18:19 --> 00:18:36
That is the place to start. Walk the seven questions against every workload you run, and the right architecture usually picks itself. For most small business and M S P workloads, that means Docker inside a Proxmox virtual machine as the default starting topology.
