LXC vs VM on Proxmox: Choosing Isolation for Homelab Services
The beginner question that exposes the whole Proxmox philosophy
The question sounded innocent: when should someone use an LXC, and when should they use a VM? Underneath it sat the anxiety every new Proxmox user eventually runs into. The poster had a few lightweight services already running in LXCs: Jellyfin, Pi-hole, nginx, and similar pieces of the homelab puzzle. They also had two VMs, one for a personal Docker-based app and another for Home Assistant. Then the doubt crept in. They had read that host updates can break LXCs because containers share the host kernel, while VMs are more self-contained, and suddenly the neat little architecture started looking risky.
It's an easy trap to fall into. At first LXCs feel like the obvious answer because they're fast, light, and easy to spin up. Then someone mentions kernel sharing, container escapes, or update breakage, and the pendulum swings hard the other way toward putting everything in a VM. Most experienced users don't treat it like that. The thread's strongest advice was basically to use LXCs by default for many homelab services and reach for VMs when isolation, packaging, Docker stacks, or special operating systems make that the cleaner choice.
That answer only feels unsatisfying because you can't tattoo it on the rack. It's a judgment call. Proxmox gives you both tools because both are useful, and the trick is knowing what kind of mistake you're trying to avoid instead of picking a religion.
LXCs are light, fast, and a little closer to the fire
The case for LXCs is easy to love. They're lightweight, they start quickly, they use fewer resources, and they can make better use of storage. They can share host folders without pretending everything is a network share, and they play nicely with granular Proxmox backups, snapshots, mount points, SDN, and the kind of small-service layout homelab users tend to build: a Pi-hole here, an nginx reverse proxy there, an AdGuard instance, Navidrome, maybe Immich, maybe a media helper. Containers are great for that.
One commenter framed it clearly. By moving services out of one giant Docker VM and into separate LXCs, you get Proxmox-level control over each service. If one breaks, you can restore that container. If one needs storage mounted differently, you can handle that one. If one needs a snapshot before an update, you don't have to snapshot a whole pile of unrelated apps. That granularity is the whole appeal, and a stack of small LXCs can feel like a clean drawer instead of a junk box labeled "Docker."
The same thing that makes LXCs efficient also makes people nervous. They share the host kernel and rely on namespaces and container isolation instead of a fully separate guest OS, so a bad enough kernel bug can matter more than it would inside a VM. Some users pointed to recent Linux CVEs and container-escape conversations as reasons to treat VMs as the safer choice for exposed services. Others pushed back, saying the old "VMs are safer" line is a stale talking point from before unprivileged containers became normal.
Both sides have a point. LXCs are not toys, and they're also not VMs. Pretending otherwise in either direction is how people end up making bad design choices with confidence.
VMs are heavier, but they buy you a wall
The best argument for VMs is still isolation. A VM runs a separate operating system with its own kernel. That doesn't make it invincible, but it gives you a harder boundary. If you're hosting something public-facing, taking real traffic from strangers, or running software you don't fully trust, that extra wall can be worth the overhead. One commenter put it simply: anything that expects real public traffic should probably be a VM and locked down.
Not every public web service has to live in a VM, though. Some users argued that reverse proxies, forward auth, identity providers like Authentik, OIDC, VPNs such as Netbird, and tools like CrowdSec can reduce the practical risk. That's the layered-security camp: don't expose things directly if you don't have to, put authentication in front, limit access, and keep the blast radius small. For a homelab where only family or friends use the service, that may be enough. If the service is truly public, especially if it's messy or high-value, a VM starts to look less like paranoia and more like cheap insurance.
VMs also win when the software expects to be a full machine. Home Assistant OS is the obvious example from the thread; people commonly run it as its own appliance-like VM because that path is simple, supported, and less annoying. NAS operating systems are another case, especially when passing through HBA controllers. A VM is also the natural home for big centralized Docker Compose stacks if the whole point is to manage apps the Docker way instead of translating each service into a separate LXC.
There's a tradeoff, of course. VMs use more CPU, RAM, and storage, they can be slower to start, and they can make file sharing more awkward. They can also blur visibility, because Proxmox sees the VM but not every app inside it. That isn't always bad, since sometimes you want one "media VM" or one "network tools VM." It is a different management style, though: you're choosing a stronger box over a lighter drawer.
Docker in a VM, Docker in an LXC, or no Docker at all
The Docker question is where people start talking past each other. The original setup had one VM running a custom app with Docker, which is a common pattern. A lot of users like Docker inside a VM because it keeps the Docker world contained. You can back up and restore the whole VM and avoid weird nested-container questions. One commenter said they run Docker containers in VMs dedicated by topic, like media or network tools, because that gives them isolation while keeping the app ecosystem grouped.
The LXC fans look at that and ask why you'd wrap every service in Docker inside a VM when Proxmox can manage the service directly as its own container. For them Docker adds another layer, another backup problem, and another place where app state and infrastructure state get tangled. If Jellyfin, Pi-hole, nginx, AdGuard, or Navidrome can run cleanly in an LXC, the LXC gives you simpler Proxmox-native backup, snapshot, mount, and restore behavior. If Immich breaks, you restore yesterday's container and move on. That's the dream.
Docker does have a real advantage in that updates and app deployment can be easier. Compose files are portable, popular, and well documented, and a lot of self-hosted projects ship Docker-first instructions. Some users don't want to translate every app into LXC land and would rather keep a Docker VM and manage apps the way the upstream project expects. That's reasonable.
So Docker in a VM isn't wrong, and LXCs aren't always cleaner. The choice comes down to who you want managing the app boundary. Docker Compose is great if you like app stacks as code. Proxmox LXCs are great if you want each service treated as a first-class unit in the hypervisor. A VM is great when you want to put a wall around the whole stack and stop thinking about host-level weirdness.
The security argument got spicy because everyone was partly right
The thread took the usual sharp turn into security absolutism. One commenter said the advantage of a VM goes beyond "greater isolation": a VM is a truly virtualized environment, while an LXC is a containerized environment running as a process on the host, closer to chroot-style separation. Another argued that modern unprivileged containers make the old security fear feel outdated. Then came the AppArmor and kernel exploit debate, with people arguing about whether certain container-escape paths were blocked, bypassed, fixed, or only relevant under specific conditions.
This is where the beginner's brain melts, and no wonder. The practical answer is simpler than the argument. A VM is the stronger isolation boundary, and an unprivileged LXC is often good enough for normal homelab services that aren't exposed directly to the internet. LXCs aren't as isolated as VMs, and using them isn't reckless either.
The bigger mistake is treating "secure" as a single switch. A public service in a poorly maintained VM with weak passwords and open ports can still be a dumpster fire. A private LXC behind a VPN and forward auth, kept updated and backed up, can be a perfectly reasonable homelab choice. Isolation matters, and so do exposure, patching, authentication, network design, backups, and how painful recovery is when something breaks.
The most useful advice was to classify risk instead of panicking about LXCs. For a public-facing, untrusted, high-value, or enterprise workload, consider a VM. For a private service, a lightweight app with trusted users and an easy restore path, an LXC is probably fine. That's the boring middle, and it's where most good infrastructure decisions live.
The clean rule: use LXCs until a VM gives you something real
For someone trying to organize their brain and their Proxmox host, the thread produced a sane default. Use LXCs for lightweight Linux services, especially things like Pi-hole, AdGuard, nginx, simple media services, monitoring tools, and apps where you want fast startup, low overhead, direct storage mounts, and easy Proxmox-native backups. Use a VM when the software is packaged as an appliance, when you need a separate OS, when you're running Home Assistant OS, when you want a big Docker Compose world, when you're passing through hardware in a way that expects a real machine, or when isolation is the point.
Most of those lightweight LXC services, including Pi-hole, AdGuard, and dozens more, already have one-line deployments in the Proxmox VE Helper Scripts collection, which saves you from building each container by hand.
That also means the original setup wasn't wrong. Home Assistant in a VM makes sense. A personal Docker app in a VM makes sense if Docker is the deployment model. Jellyfin, Pi-hole, nginx, and similar services in LXCs also make sense. There's no need to ditch LXCs; just stop expecting one container type to solve every workload.
There's also a recovery angle that beginners sometimes miss. If each app gets its own LXC, one broken app doesn't necessarily drag down the others, backups can be smaller and more targeted, and restores can be more surgical. A giant VM full of Docker containers may be simpler to update, but if the VM's filesystem or Docker state gets messy, you may be restoring a whole apartment block because one sink exploded. Neither model is perfect, so pick the failure mode you'd rather debug.
The smartest users in the thread weren't trying to win a purity contest. They mixed both, which is the actual Proxmox way: VMs for walls, LXCs for speed and granularity, Docker where Docker makes life easier, and PBS backups everywhere, with no shame or ideology attached to any of it.
Architecture beats superstition
The fear that a host update might break LXCs is not imaginary. Containers share the host kernel, so host changes matter. That doesn't make LXCs bad; it means you should update carefully, back up properly, and avoid putting every critical service in one fragile place. VMs are more self-contained, but they cost resources and add management overhead, and they won't save you from bad architecture, bad backups, or bad exposure.
What the discussion showed is that Proxmox beginners need a decision framework more than definitions. Ask what the service is, how exposed it is, how much you trust it, how it wants to be installed, how painful it would be to restore, what storage it needs, whether it needs hardware access, and whether you care more about isolation or granularity. The answer will usually reveal itself.
For a homelab, the practical default is refreshingly simple: LXCs for most small trusted services, and VMs for Home Assistant OS, Docker-heavy stacks, public-facing workloads, appliance-style systems, and anything where a stronger wall is worth the extra weight. Compared with "everything in VMs," that split is a better mental model.
The best part of Proxmox is that it doesn't force one answer. It lets you build the boring, sensible hybrid that matches your life. Your Pi-hole doesn't need a castle, though your public app might. Your Home Assistant box may want to be its own little appliance, and your media tools might be happier as containers with clean mount points and easy backups. A mix like that may look untidy, but it's what a grown-up architecture looks like.