Everything we run sits on Proxmox VE, and at this point we wouldn't build on anything else. It's open source, it runs full VMs and lightweight containers side by side, and it quietly does the job other vendors charge five figures for. With VMware's new owners currently torching perpetual licences, a lot of people are discovering it all at once, so this seems like a good week to write up what we'd tell them.
Under the hood it's refreshingly boring: a Debian system with KVM for virtual machines, LXC for containers, ZFS support built into the installer, and a web UI on port 8006 that covers essentially everything from creating guests to live-migrating them between nodes. Clustering is included. High availability is included. There's no licence key, no feature matrix, no call with a sales team to unlock the good parts.
The money question comes up immediately, so: the enterprise repository costs money and funds development, but the community repository ships the same software, and the only toll is a polite dialog at login reminding you that subscriptions exist. We've made our peace with the nag. If Proxmox ends up running anything you'd be sad to lose, buy the subscription anyway, partly for the more conservative update channel and partly because the thing is worth paying for.
What actually sold us on it:
- A web UI that makes daily admin genuinely quick
- VMs and LXC containers on the same box, so nothing runs oversized
- Live migration, so workloads move without going down
- Backups and high availability built in rather than bolted on
- A community big enough that someone has already hit your problem
The VM plus container mix is the sleeper feature. Heavy or fussy things get a full VM: game servers, Windows guests, anything that wants its own kernel. Everything small gets an LXC container at a fraction of the overhead: DNS, the reverse proxy, monitoring, that one internal web app. A container idles in tens of megabytes where a VM wants a gigabyte, so a single modest box comfortably runs a dozen services and the hardware finally earns its keep. And because snapshots are a click, you take one before every risky change and roll back when the change goes badly. It changes how brave you're willing to be on a Tuesday afternoon.
If you're setting up your own, learn from our bruises. Spend the real money on storage, because that's the bottleneck you'll feel first. Mirrored SSDs under ZFS is the sweet spot for a small setup, and if you can stretch to datacentre-grade drives with power-loss protection, do it. Proxmox writes constantly (cluster services, logs, guest IO) and cheap consumer SSDs wear out shockingly fast under that load. Leave ZFS some RAM headroom too; it borrows spare memory for caching and hands it back as guests need it.
If you cluster, give corosync (the cluster heartbeat) its own network link. It cares about latency rather than bandwidth, and the day a backup job saturates a shared link and your nodes start fencing each other is a character-building day. Three nodes is the honest minimum for quorum, and two nodes plus a small quorum device is the acceptable budget version.
Schedule backups before you create your first guest, not after. The built-in vzdump does the job, and Proxmox Backup Server does it better, with deduplication and incremental transfers that make keeping weeks of history cheap. Restore one on purpose before you ever need to in anger. And keep the thing patched. It's Debian underneath, updates are pleasantly unexciting, and the release notes at major versions are short enough to actually read.
A few first-timer traps worth naming, since we've stepped in most of them. A cluster of one is completely fine, so don't feel obliged to buy three boxes on day one; a single node gives you everything except migration and HA, and you can join more nodes later. Don't over-promise memory: KVM guests will happily let you allocate more RAM than the box has, and it works right up until the afternoon it doesn't. If a guest needs real graphics or USB hardware, PCI passthrough works well but read the IOMMU documentation first, because it's the one setup job that still involves editing config files by hand. And think about where guests live before you build them, since live migration wants shared or replicated storage, and discovering that after you've put everything on one node's local disks means an evening of moving disks around.
The nice thing is that mistakes are cheap here. Everything is a VM or a container, so the wrong choice gets rebuilt in minutes rather than a weekend, and the test lab is just another resource pool on the same box.
Do those four things, storage, network, backups, patches, and Proxmox will run for years without drama. Ask us how we know.