The first real decision in any Proxmox lab is Proxmox VM vs LXC: should a given service run in a full virtual machine or a lightweight Linux container? Get it right and a single mini PC quietly runs a dozen services. Get it wrong and you’ll burn RAM you didn’t need to spend — or fight isolation problems for a week. Here’s the rule I actually use on my cluster, service by service.

The one-sentence rule

Use an LXC container by default; reach for a VM when you need a different kernel, hard isolation, or a self-contained networking/storage stack. Everything below is just that rule applied to real cases.

What’s the actual difference?

An LXC container shares the Proxmox host’s Linux kernel and runs as isolated userspace. It boots in under a second, uses a fraction of the RAM, and resizes on the fly. A VM (KVM) emulates a whole machine with its own kernel — heavier, but fully isolated and able to run non-Linux operating systems.

	LXC container	Virtual machine (KVM)
Overhead	Very low (MBs)	Higher (full OS)
Boot time	~1 second	Tens of seconds
Kernel	Shared with host	Its own
Isolation	Process-level	Hardware-level (stronger)
Runs Windows/BSD?	No (Linux only)	Yes
Snapshots / live migrate	Yes / limited	Yes / yes

When to use an LXC container

• Most self-hosted apps: Pi-hole, Nginx Proxy Manager, the *arr stack, Vaultwarden, databases.
• Anything you’ll run several of: containers let one node hold far more services.
• Learning Linux: a disposable container is the perfect sandbox — break it, destroy it, redeploy in seconds.

When to use a full VM

• Docker / Kubernetes: run your container engine inside a VM, not nested in an LXC — it’s the supported, headache-free path.
• A different OS: Windows, OPNsense/pfSense, TrueNAS, BSD — anything that isn’t the host’s Linux kernel.
• Hard isolation: a vulnerable machine in a security lab, or anything you don’t fully trust.
• GPU/PCIe passthrough: local AI boxes and transcoding rigs want a VM.

The case that trips everyone up: Docker

You can run Docker inside an LXC, and plenty of guides show it. But the moment you hit a kernel-feature or permissions wall, you’ll wish you hadn’t. My standing advice: create one Ubuntu/Debian VM as your Docker host, give it enough RAM, and run your container stacks there. Keep single-purpose native services as LXC.

# Quick gut check before you create a guest:
# 1. Does it need its own kernel or a non-Linux OS?      -> VM
# 2. Is it Docker/Kubernetes?                            -> VM (Docker host)
# 3. Does it need GPU/PCIe passthrough?                  -> VM
# 4. Is it an untrusted / vulnerable target?             -> VM (isolated)
# Otherwise:                                             -> LXC

Frequently asked questions

Are LXC containers safe to run on the host?

For trusted, self-hosted apps, yes — use unprivileged containers (the default). For anything untrusted or deliberately vulnerable, use a VM; the hardware-level isolation is the point.

Can I convert an LXC to a VM later?

Not directly — there’s no one-click convert. It’s usually faster to redeploy the service in the right guest type, which is exactly why this decision is worth making up front.

---

This is one of dozens of “which way?” calls a homelab forces on you. For the full picture, start with The Complete Proxmox Homelab Guide. And if you’d rather have every one of these decisions made for you — VM vs LXC for each service, resources, storage, and build order — that’s precisely what a Lab Blueprint delivers: a custom plan, in days, no calls.