Proxmox VE
Proxmox VE (Virtual Environment) is a free, open-source hypervisor built on Debian that combines KVM virtual machines and LXC containers under one web-based console, with clustering, live migration, and backup built in. It turns one physical machine into a real virtualization platform instead of just a Docker host, capable of running several operating systems side by side on the same hardware.
License: the Proxmox VE core is licensed under the GNU Affero General Public License, version 3 (AGPLv3), confirmed directly from the official Proxmox VE FAQ. Proxmox Server Solutions GmbH, the company behind the project, sells separate paid subscriptions for enterprise support and an Enterprise update repository; neither changes the license on the code itself.
Quick facts: Official site proxmox.com · Documentation pve.proxmox.com/pve-docs · Source developed via mailing list at git.proxmox.com, read-only mirror at github.com/proxmox/pve-manager · Current stable Proxmox VE 9.x, built on Debian 13 (Trixie) · Backup handled by a separate product, Proxmox Backup Server.
What Proxmox VE actually does
Proxmox VE bundles two virtualization technologies homelabs eventually want anyway. QEMU/KVM runs full virtual machines: any guest OS, real hardware-level isolation, live migration between cluster nodes with shared storage. LXC handles lightweight Linux containers sharing the host kernel, closer to a fenced-off process than a full computer. Both live in the same web interface, alongside ZFS or Ceph storage pools, VLAN-aware networking, and scheduled snapshots plus backups. Clustering lets several nodes share one login and move a running VM between machines without downtime.
The hardware question nobody should skip: virtualization flags and IOMMU
Running Proxmox VE at all needs an Intel 64 or AMD64 CPU with the VT-x or AMD-V flag, the feature that lets KVM run guests at close to native speed. Check with egrep '(vmx|svm)' /proc/cpuinfo on any Debian-based system if there’s doubt. That part rarely trips anyone up; most desktop and laptop CPUs from the last decade have it.
PCI passthrough is the real friction point. Handing a physical device, a SATA controller, an HBA, a GPU, straight to a VM (so it can talk to disks directly instead of through a virtual one) needs IOMMU support: VT-d on Intel, AMD-Vi on AMD. Some consumer motherboards expose it in the BIOS, some don’t, and IOMMU groups don’t always split the way a parts list assumes; a network card sharing a group with an M.2 controller shows up more than anyone would like. Confirm passthrough works on the exact motherboard before buying drives for a virtualized NAS, not after.
Before you buy anything: check VT-x/AMD-V and VT-d/AMD-Vi separately, they’re not the same flag. VT-x/AMD-V is on almost every recent CPU. VT-d/AMD-Vi, needed for PCI passthrough, is a separate BIOS setting not every consumer board exposes, worth confirming from the motherboard’s manual before ordering hardware.
Hardware: Proxmox’s documented minimum is 1 GB of RAM, for evaluation only. A realistic homelab floor is 16–32 GB, plus NVMe storage if ZFS is part of the plan. Our Balanced Homelab build is sized for exactly this.
Installing Proxmox VE
Proxmox VE installs from its own ISO onto bare metal in the usual case. Installing on top of a running Debian system is documented and possible, but the ISO path is what almost everyone uses.
- Download the ISO from the official downloads page and flash it to a USB drive.
- Boot from that USB drive and step through the graphical installer: target disk, filesystem (ext4, or ZFS for snapshots and redundancy), time zone, root password, and a static management address.
- Reboot, then open the management address on port 8006 in a browser and log in as root.
- From Datacenter, decide which package repository to use before doing much else (see the next section).
The installer partitions the whole target disk. Point it at a drive with anything worth keeping, and it will erase that drive without a second warning. Double-check the disk selection screen, especially on a machine with more than one drive installed.
Free vs. Enterprise: what “no-subscription” actually means
Every fresh install points at the pve-enterprise repository, which needs a paid subscription key. Switching to pve-no-subscription instead, a couple of edits in /etc/apt/sources.list.d/, is the standard homelab move and costs nothing.
What the free repository gives up: almost nothing functional. Same packages as Enterprise, minus a support contract and a slightly less conservative update cadence. The one visible difference is a login pop-up reminding you no subscription is active; cosmetic, nothing in the software is disabled. Paid subscriptions buy support and the Enterprise update pace, not features.
Homelab use cases
The case for moving off a single Docker host is running more than one operating system on the same box without any of them getting in each other’s way. A common layout: TrueNAS or OpenMediaVault in its own VM with a SATA controller or HBA passed through via IOMMU, so ZFS sees real disks; Home Assistant OS in a second VM, since it expects to own its environment; a Windows VM for the one app that needs it; and LXC containers, or a dedicated VM, running Docker for everything else. A container manager like Portainer fits naturally inside that Docker VM. Proxmox’s own developers recommend Docker run inside a VM rather than nested in LXC, which has a track record of breaking after kernel updates.
Proxmox VE vs. ESXi vs. XCP-ng
VMware ESXi was the default answer for years, until Broadcom’s 2023 acquisition ended the free ESXi tier and folded licensing into subscription-only bundles, a well-documented shift that sent homelabers looking for alternatives (the full origin story, from a 2005 Vienna startup to Broadcom-driven adoption, is in our history of Proxmox VE). XCP-ng, built on the Xen hypervisor with roots in Citrix’s XenServer, is the other free option: solid live migration, and a paid XOA management layer mirroring Proxmox’s own Enterprise/no-subscription split. Unraid takes a different angle, storage-array-first with Docker and VMs layered on top, better suited to a NAS that also runs VMs than a hypervisor that also runs a NAS.
| Category | Proxmox VE | VMware ESXi | XCP-ng |
|---|---|---|---|
| Cost | Free, AGPLv3, paid support optional | Free tier gone after the Broadcom acquisition; subscription only | Free core, open source; paid XOA tiers optional |
| Containers | Native LXC alongside VMs | VMs only, no native container layer | VMs only, no native container layer |
| Storage | ZFS, Ceph, LVM, hardware RAID | VMFS, vSAN (paid add-on) | Local storage, XOSAN, several backends |
| Best fit | Homelabs and small businesses wanting VMs and containers together | Organizations standardized on the VMware/Broadcom stack | Homelabs wanting Xen-based free virtualization with an enterprise upgrade path |
Proxmox VE: pros and cons
- Free core with no functional limits on the no-subscription repository, AGPLv3 licensed
- Runs full VMs and lightweight LXC containers side by side, plus clustering and live migration once shared storage is set up
- ZFS and snapshots built in: roll back a broken update in a couple of clicks instead of rebuilding
- Backed by a company that also sells support, not a purely volunteer project that can stall
- Bare-metal install, no gentle on-ramp from an existing OS the way Docker offers
- PCI passthrough for disk controllers or GPUs depends on motherboard IOMMU support that varies machine to machine
- Running Docker directly on the Proxmox host isn’t recommended; it wants its own VM
- Enterprise repository nag on login until the source list is switched, cosmetic but mildly annoying out of the box
FAQ
Is Proxmox VE really free?
Yes. The core is AGPLv3 licensed and the no-subscription repository is fully functional with no feature gate. Paid subscriptions buy support and the Enterprise update cadence, not extra capabilities.
Can I run Docker directly on Proxmox VE?
Not on the host itself; Proxmox’s own documentation advises against it. The standard approach is a VM, commonly Debian or Ubuntu, running Docker inside it.
Do I need IOMMU or VT-d for a basic Proxmox VE setup?
No. VT-d and AMD-Vi only matter for PCI passthrough, handing a physical device straight to a VM. A host running plain VMs and LXC containers with no passthrough only needs the baseline VT-x/AMD-V flag that almost every modern CPU already has.
What’s the difference between a Proxmox VM and an LXC container?
A VM gets its own virtual hardware and kernel: full isolation, any guest OS. An LXC container shares the host’s kernel and is Linux-only, lighter on resources but less isolated.
Proxmox VE earns its Advanced label less through button-mashing complexity than through the concepts it assumes: IOMMU groups, storage backends, network bridges, a bare-metal install that doesn’t forgive a wrong disk pick. Past that first setup, it turns one box into the NAS-plus-smart-home-plus-everything-else lab a single Docker host can’t quite become. Our homelab setup guide for beginners covers the hardware decisions that lead here; TrueNAS and Unraid, common VM guests once passthrough works, are covered in detail elsewhere on this site; OpenMediaVault is covered too.