Proxmox LXC vs VM vs Docker in 2026: Which to Use for What

Every few years, the same argument bubbles back up in the Proxmox world. Someone asks an honest, practical question: why not just run Docker inside an LXC? It works, it's fast, and it uses less memory, and plenty of people have been doing it for years without issue.

Then the replies roll in: "Unsupported." "Just use a VM." "It'll break on upgrade." "Containers inside containers is asking for trouble."

Fast forward to 2026, and here we are again, still arguing, still deploying, and still breaking the "rules" in homelabs and edge servers everywhere. Even with newer features and a slightly softer official stance from Proxmox VE, the Docker-in-LXC debate refuses to settle down.

People aren't being stubborn. The tradeoffs are real, and the incentives on both sides haven't gone away.

Two platforms, one kernel, zero patience for each other

The debate comes down to a simple architectural tension. Proxmox is a virtualization platform. Docker is also a virtualization platform, just at a different layer. Both rely heavily on the Linux kernel to do their job.

An LXC container on Proxmox shares the host kernel, and Docker containers also expect to talk directly to the host kernel. When you run Docker inside an LXC, you're stacking two systems that both assume they're "closest" to the kernel.

Most of the time, Linux is flexible enough to make this work, until one day it isn't.

Kernel updates, AppArmor profile changes, cgroup version shifts, and filesystem driver tweaks are not exotic edge cases. They're normal parts of keeping a host secure and up to date. When something changes at the Proxmox layer, Docker doesn't know or care that it's running inside LXC. Likewise, Proxmox doesn't test its updates against Docker running inside containers it doesn't officially support, and the horror stories come out of that gap.

"But I've been running Docker in LXC for years"

You'll hear this a lot, and it's usually true.

Many users have run Docker inside unprivileged LXCs for five, six, even seven years. Some upgraded straight through multiple major Proxmox releases without a single incident. Their takeaway is obvious: the risk is overblown.

The catch is that success here is unevenly distributed. If your workloads are light, your storage layout is simple, and you don't rely on edge-case kernel features, Docker in LXC can feel rock solid. If you're pushing GPUs, advanced networking, or storage drivers that sit right on the boundary between kernel and user space, cracks start to show.

That unpredictability is exactly why Proxmox keeps repeating the same advice. It does work for many people, but when it fails, it fails in ways Proxmox can't easily support or debug.

Scenario one: "Just use LXC, no Docker"

The least controversial setup is also the least fashionable: plain LXCs, traditional packages, systemd services, maybe glued together with Ansible.

From Proxmox's perspective, this is the happy path. LXCs are first-class citizens, tested and documented, and kernel updates are expected to work here.

The downside is obvious if you've spent the last decade living in container land. Many modern services don't really ship as "software" anymore. They ship as Docker images, with no apt repo and no clean install guide, just a compose file and a prayer.

Rebuilding those stacks by hand isn't impossible, but it's work, and it keeps being work. Dependencies change and docs drift, and suddenly your "simple" LXC looks like a custom distro you're maintaining alone.

Scenario two: Docker inside LXC

This is the controversial middle ground, and the reason the debate won't die.

On paper, Docker-in-LXC doesn't buy you much isolation. Both layers use the same kernel features: namespaces, cgroups, capabilities. You're not really safer, and you're not meaningfully faster either. You're doubling up on abstraction. Paths get mapped twice, ports get forwarded twice, and UID and GID mappings become a minor personality test.

And yet people keep doing it, because the ergonomics are unbeatable. Docker Compose is easy, documentation exists, backups are simple, and migration is often just copying a directory and re-running a stack.

Performance and security are the smaller worries here. The bigger one is compatibility drift. Docker updates its runtime, Proxmox updates its kernel or LXC profiles, and nobody is coordinating those changes across layers. Most of the time, nothing explodes. Sometimes it does.

When it breaks, it usually breaks after an upgrade, and then you're on your own.

Scenario three: Docker in a VM

This is the boring, safe answer, and in production, boring usually wins.

A VM gets its own kernel, which keeps both Docker and Proxmox happy. Updates are far less likely to cause weird permission failures or kernel feature mismatches. Live migration works, HA works, and support tickets make sense.

The cost is overhead. Even a lean VM needs memory for its kernel, its init system, and its idle processes. On a big server, that's noise. On a small box or a power-constrained homelab, it's the difference between fitting everything and having to make choices.

GPU passthrough also gets trickier. A VM tends to monopolize hardware unless you carefully slice it up, and not everyone wants to deal with that complexity.

Still, if uptime matters more than squeezing every last watt, this is the path Proxmox actually designs for.

Why upgrades are the real villain

The most common breaking points are boring details. A container runtime changes how it touches /proc. An AppArmor profile tightens slightly. A storage driver flips its default behavior.

Each change is reasonable in isolation. Combined across layers, they can stop containers from starting at all.

That's why people say "Docker in LXC breaks on upgrades." They mean that you're running two fast-moving systems that don't test against each other.

If you delay upgrades, keep good backups, and accept occasional downtime, that risk might be fine. If you need predictable behavior on day one of a new release, it probably isn't.

The OCI wildcard

Recent versions of Proxmox have added early support for running OCI images directly, without spinning up a Docker daemon inside an LXC. It's a subtle shift, but an important one.

Instead of nesting runtimes, Proxmox treats the image as input and runs it with its own container stack. That removes one entire layer of friction: there's no Docker socket and no runc inside LXC, just Proxmox managing the container lifecycle itself.

It's promising, and it's also not finished. There's no mature equivalent to Docker Compose yet, orchestration is basic, and upgrades are cautious. Right now it feels like a glimpse of a future where this debate might finally cool off, though not something everyone can bet their infrastructure on today.

Why the argument keeps coming back

This debate survives because the answer depends on your priorities.

If you value efficiency above all else, LXCs, with or without Docker, are incredibly compelling. Memory sharing is real, startup times are instant, and resource usage feels honest.

If you value stability and support, VMs win by default. The isolation is cleaner, the blast radius is smaller, and the rules are clearer.

And if you value convenience, Docker remains hard to beat. That convenience doesn't disappear just because someone tells you it's "unsupported."

So people keep mixing and matching. They accept the risks that matter least to them and ignore the rest. Then a new Proxmox release lands, something changes, and the conversation starts all over again.

In 2026, the tools are better, the kernels are smarter, and the warnings are clearer, but the tradeoffs are still there.

That's why this debate refuses to die: depending on how you run your systems, everyone in it is a little bit right.