Proxmox VE for a Homelab: Clusters, Storage, Backups and Hardening

Proxmox VE is an open source (AGPL v3) virtualization platform that runs KVM virtual machines and LXC containers on Debian. For a homelab, start with one node on local ZFS, add a second only with a QDevice for a third vote, and back up to a separate Proxmox Backup Server with client side encryption and verify jobs.

This guide goes one level deeper than our walkthrough on how to build a tiny data center at home and covers the virtualization layer: release lifecycle, hardware, quorum, storage failure modes, backups, updates and hardening. Every command, default and date below comes from the Proxmox VE administration guide, FAQ and release history, the Proxmox Backup Server documentation, Debian's release pages, the OpenZFS and QEMU documentation and NIST SP 800-125, checked on 24 October 2026.

Key takeaways

• Proxmox VE is Debian plus a management stack: QEMU/KVM for virtual machines, LXC for system containers, a REST API and web interface on TCP port 8006, and a replicated configuration file system mounted at /etc/pve.
• Each major version tracks one Debian release. Proxmox VE 9 (Debian 13 Trixie) first shipped in August 2025. Proxmox VE 8 (Debian 12 Bookworm) reached end of life in August 2026 according to the project FAQ; upgrade with the pve8to9 checker.
• A cluster needs a majority of votes to change anything. With two nodes, losing either one leaves the survivor read only. A QDevice (corosync-qnetd on a small external host) adds the third vote. HA needs three votes, shared storage and a watchdog.
• Storage choice is a failure mode choice: local ZFS stays on one node, a full LVM-thin pool corrupts guests, NFS and iSCSI make the NAS a single point of failure, and Ceph needs three or more nodes and fast networking.
• Backups run through vzdump. Proxmox Backup Server adds deduplication, incremental uploads, client side AES-256-GCM encryption and verify jobs. Keep the encryption key off the machine you back up.
• The firewall is disabled by default. Enable it with an SSH session open, put admin machines in the management IP set, move management to its own VLAN, require two factor authentication, and give automation expiring, privilege separated API tokens.
• Restore one guest to a new ID on an isolated bridge every month; an untested backup is a guess.

What is Proxmox VE?

Proxmox VE (Virtual Environment) is a complete server virtualization platform delivered as a Debian based operating system image. The FAQ answers the basics directly: it is based on Debian GNU/Linux, its code is licensed under the GNU AGPL version 3, and it runs only on 64 bit CPUs. Supported host architectures are x86_64 and, more recently, aarch64 on specific NVIDIA server platforms; the FAQ says there is no plan to support 32 bit hosts, although 32 bit guests are fine. The introduction chapter of the administration guide says the project started in 2007 and shipped its first stable version in 2008.

Two kinds of guests run on it.

• Virtual machines (QEMU/KVM). The FAQ describes QEMU as an open source machine emulator and virtualizer that uses the Linux KVM kernel module to run guest code directly on the host CPU. The QEMU documentation lists KVM as the accelerator on Linux hosts; without one, QEMU falls back to its much slower Tiny Code Generator. VMs can run any operating system.
• System containers (LXC). Containers share the host kernel, so they are lighter than VMs but limited to Linux guests. Proxmox manages them with pct, which integrates with clusters, storage, the firewall, backups and HA. The FAQ says OCI application containers are a technology preview, that Docker should not run directly on the host, and that orchestration or live migration belongs inside a VM.

Around the guests sit the command line tools you will use daily (qm for VMs, pct for containers, pvesm for storage, pvecm for the cluster, pveum for users, vzdump for backups) and the Proxmox Cluster File System. The introduction chapter describes pmxcfs as a database driven file system that stores configuration files, replicates them in real time to every node through Corosync, keeps its data in a persistent database on disk with a copy in RAM, and has a maximum size of 128 MiB. Everything under /etc/pve, including guest configs, storage.cfg, firewall rules and user ACLs, lives there. That matters for security: anyone who can write to /etc/pve on one node can change every node.

NIST SP 800-125, the Guide to Security for Full Virtualization Technologies (January 2011), exists to discuss the security concerns of full virtualization and recommend ways to address them. The practical reading for a homelab is that the hypervisor and its management interface sit below every guest: whoever controls them controls every VM and container on the box. Everything in the hardening section below follows from that idea.

How do Proxmox VE releases track Debian?

Each Proxmox VE major version is built on one Debian stable release. The FAQ states that Proxmox VE versions are supported at least as long as the corresponding Debian version is supported by the Debian Security Team, which is roughly three years after its release, and that Proxmox uses a rolling release model within a major version, so the latest point release is always the recommended one.

Here is the lifecycle table from the Proxmox VE FAQ, as published on 24 October 2026, with Debian's own dates alongside.

Debian's release page gives exact dates for the bases that matter now. Debian 13 Trixie was released on 9 August 2025, with regular security support until 9 August 2028 and LTS until 30 June 2030. Debian 12 Bookworm was released on 10 June 2023, regular security support ended on 11 July 2026, and LTS runs to 30 June 2028. Note that the Proxmox FAQ ties Proxmox's own support to Debian's regular security support, not to Debian LTS. A Proxmox VE 8 node is end of life even though Debian 12 LTS still exists.

Point releases inside a major version bring new kernels, QEMU, ZFS and Ceph. From the Proxmox VE release history (roadmap page):

Three release note details matter for a homelab. Proxmox VE 9 dropped GlusterFS storage because it is no longer maintained upstream. Hyper converged Ceph must be on 19.2 Squid before the 8 to 9 upgrade. And the 7.0.2-6 kernel on the 9.2 ISO had issues with some megaraid_sas RAID controllers and certain NVMe drives in JBOD mode, fixed in 7.0.14-15; for affected hardware, Proxmox recommends installing from the 9.1 ISO and upgrading. Read the known issues for your hardware before you install.

What hardware does a small Proxmox cluster need?

The installation chapter separates minimum requirements, which are for evaluation only, from recommended ones.

The FAQ gives the quick test for hardware virtualization on x86:

egrep '(vmx|svm)' /proc/cpuinfo

vmx is the Intel VT-x flag and svm the AMD-V flag. No output means either the CPU lacks it or it is disabled in the firmware setup.

ECC memory. The Proxmox installation chapter does not list ECC as a requirement. The OpenZFS hardware page says no technique in ZFS, or any file system, can protect against bit flips, so ECC memory is highly recommended. In a homelab it is a cost decision: worth it if the box holds irreplaceable data, an accepted risk if every guest is rebuildable and backed up elsewhere.

Disks and controllers. Two rules come straight from the documentation. ZFS on top of any hardware RAID is not supported and can result in data loss, and neither ZFS nor Ceph is compatible with a hardware RAID controller. Use a plain SATA or SAS host bus adapter, or onboard ports. Since Proxmox VE 8.1 the installer also writes a ZFS ARC (read cache) limit of 10 percent of host memory, clamped to 16 GiB, into /etc/modprobe.d/zfs.conf, before 8.1 the installer set no limit at all. If you installed from an older ISO, set zfs_arc_max yourself.

Network cards. The cluster chapter recommends a dedicated physical NIC for cluster traffic and says a dedicated 1 Gbit NIC is enough in most situations, because Corosync needs low and consistent latency rather than bandwidth. For hyper converged Ceph, the Ceph chapter recommends at least 10 Gbps and notes that a single modern NVMe SSD can already saturate a 10 Gbps link.

Boot media. Install to SSDs, not USB sticks or SD cards, because logs and the pmxcfs database write constantly. A ZFS mirror across two small SSDs survives one disk failing; the system administration chapter documents proxmox-boot-tool for keeping both disks' EFI partitions in sync after a replacement.

CPU vendors across nodes. The cluster chapter says online migration is only supported between nodes with CPUs from the same vendor.

How many nodes do you need for quorum?

Proxmox VE gives every node one vote by default, and the cluster can only change state when a majority of votes is present. Quorum is the integer part of half the votes, plus one.

Worked example 1, two nodes. Total votes are 2, so quorum is 2 / 2 + 1 = 2. If either node fails or the link between them drops, the survivor holds 1 vote, which is less than 2. The cluster file system goes read only on that node: running guests keep running, but you cannot start, stop, migrate or reconfigure them until quorum returns. Two nodes therefore give you less availability for cluster operations than one node does.

Worked example 2, two nodes plus a QDevice. Total votes become 3, quorum is 3 / 2 + 1 = 2 (integer division). Lose one node and the survivor plus the QDevice hold 2 votes, so the cluster stays quorate. Lose the QDevice instead and the two nodes still hold 2 votes. You tolerate any single failure.

Worked example 3, three nodes. Total votes are 3, quorum is 2, and you tolerate one node failure. With five nodes, quorum is 3 and you tolerate two failures. The cluster chapter gives a larger case: in a 15 node cluster, 7 nodes can fail before the cluster becomes inquorate.

That is why the HA chapter lists "at least three cluster nodes (to get reliable quorum)" as its first requirement, and why the cluster chapter says that for two node clusters, a QDevice can provide the third vote.

How does Proxmox VE clustering work?

A Proxmox VE cluster has three moving parts: Corosync for membership and messaging, the quorum rules above, and pmxcfs for replicated configuration.

Corosync and the cluster network. The requirements list in the cluster chapter is short and strict:

• All nodes must reach each other on UDP ports 5405 to 5412 for Corosync.
• Date and time must be synchronized.
• An SSH tunnel on TCP port 22 between nodes is required.
• All nodes should run the same version.
• The root password of an existing node is required to add a node.

The network requirements section asks for latencies under 5 milliseconds between nodes, and warns against sharing a network between Corosync and storage except as a low priority fallback. Since Corosync 3 (Proxmox VE 6.0), traffic uses the Kronosnet transport over UDP unicast with up to 8 links. The docs recommend at least one extra link on a different physical network, and caution that a single link on top of a bond can misbehave in some failure scenarios.

pmxcfs. Corosync replicates every write to /etc/pve to all nodes. When a node loses quorum, the file system on that node switches to read only. When you join a node, the cluster chapter warns that all existing configuration in that node's /etc/pve is overwritten by the cluster's. Join only empty nodes, or nodes whose guests you have backed up and are prepared to recreate.

Fencing and HA. If you enable high availability for a guest, the HA manager must be sure a failed node is really dead before restarting its guests elsewhere, otherwise two copies of the same VM could write to the same disk. Proxmox uses a watchdog for this. The HA chapter says a hardware watchdog can be used and that, if none is available, it falls back to the Linux kernel software watchdog, softdog. A node that loses quorum while running HA services cannot reset its watchdog, so it resets itself after the 60 second watchdog timeout. This self fencing is why HA without reliable quorum and shared storage is dangerous, and why the HA chapter also asks for "hardware redundancy (everywhere)" and reliable server components.

QDevice. The Corosync Quorum Device is a daemon on each cluster node that talks to an external arbitrator, corosync-qnetd. Key points from the cluster chapter:

• Only QDevice Net is supported as the arbitrator. It gives its vote to one partition at a time, only to a partition it can reach and that would be quorate with its vote.
• The QDevice talks to the cluster over TCP/IP and does not need Corosync's low latency, so it can run outside the cluster's LAN.
• The external host needs only network access to the cluster and the corosync-qnetd package. The docs recommend running it as an unprivileged user (the Debian package already does) and say traffic between the daemon and the cluster must be encrypted.
• Proxmox supports QDevices for clusters with an even number of nodes and recommends one for two node clusters. For odd sized clusters it discourages them: the QDevice then provides N minus 1 votes, so if the QDevice itself fails, no other node may fail. The 15 node example drops from tolerating 7 failures to tolerating none while the QDevice is down.

A single board computer, a small Debian VM on your NAS (not on the cluster itself) or a small cloud VM reachable over a VPN all work as QDevice hosts. Do not power it from the same outlet as one of the nodes, or one outage takes out both.

Which storage model fits a homelab?

Proxmox VE's storage chapter lists every backend with its level, whether it is shared and whether it supports snapshots. The homelab relevant rows are below, with the failure mode that each one carries.

Local ZFS. The default choice for a small lab: zvols for VM disks, snapshots, clones and checksums on every block. Its weakness is locality: if the node dies, its guests are gone until you restore them. Proxmox's storage replication framework (pvesr), which supports local ZFS only, replicates guest volumes to another node using snapshots, sending only incremental changes after the first full sync, on a schedule between once a minute and once a week. That turns a node loss into "start the replica, lose the changes since the last run." For deeper ZFS layout choices, mirrors versus RAIDZ and scrubs, see our home NAS and ZFS guide.

LVM-thin. The default when you install on ext4 or XFS. It is fast and supports snapshots, but it is local and has no data checksums. The storage chapter's warning applies to every thin provisioned backend: if the storage runs full, all guests using volumes on it receive I/O errors, which can cause file system inconsistencies and corrupt data. Watch free space and do not over provision.

NFS, SMB and iSCSI shares. A NAS share lets every node see the same disk images, which makes live migration fast and HA possible, and makes the NAS a single point of failure for every guest on it. The storage chapter warns that internal qcow2 snapshots block a running VM and are particularly slow on NFS, taking minutes or even hours on large disks. For iSCSI, Proxmox puts LVM on the LUN, and multipathing is usually a requirement.

Ceph. Ceph is distributed storage that replicates data across nodes. Proxmox VE can run it hyper converged on the same nodes as your guests. The Ceph chapter sets the bar: at least three nodes, at least 12 OSDs evenly spread across them (recommended), at least three monitors for quorum, 10 Gbps or faster networking, and host bus adapters instead of RAID controllers. New pools default to 3 replicas with a min_size of 2. The chapter says plainly: do not set min_size to 1, because that allows writes with a single copy and can lead to data loss. The cluster chapter adds that a Ceph cluster stops serving if only (N minus 1) / 2 nodes or fewer remain. Ceph is a good way to learn how production clusters behave; it is a poor way to store the only copy of anything on three second hand mini PCs with 1 Gbit NICs.

Comparison: single node, two nodes with QDevice, three node Ceph

Whatever you pick, none of these is a backup. Replication and Ceph copy deletions, encryption by ransomware and corruption just as faithfully as they copy good data.

How do backups and restores work?

Every Proxmox VE backup, whether to a local directory, an NFS share or Proxmox Backup Server, is driven by vzdump. The backup chapter calls it a fully integrated solution that uses the capabilities of each storage and guest type, and backups can run on demand or as scheduled backup jobs.

Backup modes

For VMs, vzdump offers three consistency modes:

• stop: shuts the VM down cleanly, backs it up, then restores the previous state. Highest consistency, with downtime.
• suspend: kept for compatibility; the docs recommend snapshot mode instead.
• snapshot: the lowest downtime. A live backup copies data blocks while the VM keeps running. If the QEMU guest agent is enabled (agent: 1) and running, Proxmox calls guest-fsfreeze-freeze and guest-fsfreeze-thaw to flush and freeze the guest file systems around the snapshot, which improves consistency.

Containers use the same mode names, but snapshot mode requires every backed up volume to be on storage that supports snapshots. Two options help on a small box: backup fleecing caches old blocks on fast local storage so a slow backup target does not throttle guest writes, and the metadata change detection mode lets container backups to Proxmox Backup Server skip unchanged files. For archives on ordinary storage, the backup chapter says zstd is the fastest of the three compressors (lzo, gzip, zstd) and the only multi threaded one.

Retention

Retention options such as keep-last, keep-daily, keep-weekly, keep-monthly and keep-yearly decide what is pruned. The backup chapter's own example keeps the last 3, 13 daily and 9 yearly backups, and explains why keep-last is useful: it protects the extra manual backup you take just before a big upgrade.

Proxmox Backup Server

Proxmox Backup Server (PBS) is a separate product, also AGPL v3 licensed, built for backing up Proxmox VE guests and hosts. Its technical overview explains why it is so much more efficient than plain vzdump archives:

• Chunking. Backup data is split into chunks. VM disk images use fixed size chunks, typically 4 MiB. Container and file backups use dynamic size chunks, so inserting a few bytes into a file does not shift every following chunk.
• Content addressing and deduplication. Each chunk is identified by the SHA-256 checksum of its content. A chunk already present in the datastore is not stored again, so ten nightly backups of a mostly unchanged VM take little more space than one.
• Incremental uploads. Only chunks that are not already in the datastore are uploaded. For VMs, Proxmox VE can also use dirty bitmaps that track which blocks of a disk image changed since the last backup, so only the modified chunks need to be uploaded.
• Client side encryption. The PBS storage plugin documentation says you can optionally encrypt on the client with AES-256 in GCM mode. The key is stored at /etc/pve/priv/storage/<STORAGE-ID>.enc, readable only by root. The server stores ciphertext and cannot read your data.

The documentation spells out the catch: without the key, backups are inaccessible, and a key stored only on the system being backed up dies with it. It recommends a password manager copy, a USB stick in a secure place and a paper copy from proxmox-backup-client key paperkey. You can also configure an RSA master public key so every backup carries its AES key encrypted to that master key; guard the master private key the same way.

Prune, garbage collection and verify jobs

On PBS, pruning removes snapshot indexes but frees no space. Garbage collection does that in two phases: mark updates the access time of every referenced chunk, and sweep removes chunks older than a cutoff, either the start of the oldest running backup or 24 hours and 5 minutes before the run began (a grace period that exists because file systems usually mount with relatime). Freed space therefore appears about a day after you prune.

Verify jobs re-read stored chunks and check their checksums. The PBS maintenance chapter recommends a frequent (hourly or daily) job that checks new and expired backups and a weekly or monthly job that re-verifies everything, because disks degrade over time and an old, working backup can silently rot. The defaults are 1 reader thread and 4 verify threads.

The PBS documentation also covers ransomware protection, including the 3-2-1 rule and restrictive user and token permissions. In a homelab, the cheapest version is a second PBS or removable datastore that the Proxmox VE hosts cannot write to directly.

Restores

The backup chapter lists two restore tools: qmrestore for VMs and pct restore for containers, plus the web interface. The qmrestore man page documents the options you need for a safe test restore: <archive> <vmid>, --storage to choose where disks go, --unique to assign a new random MAC address so the restored VM does not clash with the original on the network, --start (off by default) and, for PBS only, --live-restore, which starts the VM immediately while the restore continues in the background. During a live restore the VM runs with limited disk read speed, and the backup chapter warns that if a live restore fails, the VM is left in an undefined state with possibly incomplete data, so use it for urgent recovery rather than for routine tests. Single file restore from the storage's Backups tab lets you pull one file out of a VM or container backup on PBS without restoring the whole guest.

How do repositories and updates work?

Proxmox VE ships its packages through APT repositories alongside the normal Debian ones. Since Debian 13 Trixie, the package repositories page uses the deb822 format: .sources files under /etc/apt/sources.list.d/, and apt warns about the legacy one line format (apt modernize-sources converts it).

All of them are signed: each stanza carries Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg, and the Debian stanzas point at the Debian archive keyring. Never remove those lines or add trusted=yes to silence an error; signature checking is the only thing standing between your hypervisor and a tampered mirror. The docs also note that subscription keys are bound to the host architecture, so an arm64 host needs an arm64 key.

Most homelabs run without a subscription: add Enabled: no to the enterprise stanza and add the no-subscription repository, keeping the base Debian repositories too.

Minor updates. The FAQ says point release upgrades, such as 9.1 to 9.2, are done like any normal update, from the web interface (node, then Updates) or:

apt update
apt full-upgrade

The FAQ adds one condition: only continue if apt update did not hit any error. Use full-upgrade, not plain upgrade, which holds back new or replaced packages such as a new kernel series, and reboot after a kernel update.

Major upgrades. The FAQ says major version upgrades are supported but must be carefully planned and tested and never started without a current backup. The 8 to 9 upgrade guide is built around a checklist script, pve8to9, shipped in the latest 8.4 packages, which you run before, during and after the upgrade (pve8to9 --full for all checks). The outline is:

1. Update the 8.4 node fully and run pve8to9 --full until it reports no failures.
2. Move guests off the node or shut them down; in a cluster, upgrade one node at a time.
3. If you run hyper converged Ceph, upgrade it to Ceph 19.2 Squid first.
4. Change every Debian and Proxmox repository from bookworm to trixie, and remove any Bookworm specific third party repositories.
5. Run apt update, then apt dist-upgrade. The guide says this takes under 5 minutes on a fast SSD server and can take 60 minutes or more on a slow spinning disk.
6. Re-run pve8to9, then reboot into the new kernel.

The guide also points at Trixie changes that surprise people: /tmp is now a tmpfs using up to 50 percent of memory, and files in /tmp and /var/tmp are cleaned regularly while the system runs. The 9.0 release notes add that network interface names may change during the upgrade because of new naming policies and NIC features in the newer kernel, so keep console access to each node. It ships a migration script that disables LVM autoactivation for guest volumes, strongly recommended on shared LVM. For the Debian side of this history, see our Debian release history.

How do you harden a Proxmox VE host?

The goal is simple: nobody should reach port 8006, SSH or the cluster ports unless they are an administrator on an administrator's device, and anyone who does reach the login page should still need a second factor.

Keep the management interface off the guest and home LAN

The network chapter documents putting the host's management address on its own VLAN. With a VLAN aware Linux bridge, guests get their VLAN tags on their virtual NICs, and the host address lives on a VLAN subinterface of the bridge. The example in the docs puts management on VLAN 5:

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0.5
iface vmbr0.5 inet static
        address 10.10.10.2/24
        gateway 10.10.10.1

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

On your router, allow only the admin workstation VLAN to reach the management VLAN, never forward port 8006 from the internet, and reach the lab remotely through a VPN. Keep Corosync and storage traffic on their own networks. Our home firewall build covers the router side.

Turn on the built in firewall carefully

The firewall chapter states that the firewall is completely disabled by default. Configuration lives in pmxcfs: /etc/pve/firewall/cluster.fw for cluster wide rules, IP sets, aliases and security groups; /etc/pve/nodes/<nodename>/host.fw per node; and /etc/pve/firewall/<VMID>.fw per guest.

When you enable it, traffic to all hosts is blocked by default, with exceptions for the local network to the web interface, SSH and other important services. The chapter's advice is to open an SSH session to a host before enabling the firewall so you keep access if something goes wrong. To allow remote administration, add your admin IP addresses to the standard IP set called management; it automatically generates the rules for the web interface, VNC and SPICE consoles and SSH, and the local cluster network is added to it automatically. When the firewall is enabled, Corosync accept rules are generated automatically.

The ports Proxmox VE uses, from the same chapter:

Proxmox also offers proxmox-firewall, an nftables based implementation. The firewall chapter still labels it a technology preview, so for a homelab you rely on, keep the default implementation unless you want to help test.

Per guest firewalls are worth enabling too. The ipfilter option restricts each guest NIC to its configured addresses, which stops a compromised guest from spoofing another guest's IP on the same bridge.

Users, login sources and two factor authentication

Proxmox VE authenticates users against Linux PAM (root@pam), its own authentication server (@pve), LDAP directories or OpenID Connect. The user management chapter notes that root@pam is an unconfined administrator that cannot be deleted. Keep it for break glass access and log in daily as a named @pve admin, granted the Administrator role through a group.

Two factor authentication comes in two flavors. An authentication source (Proxmox calls these realms) can require it for every user (TOTP or a hardware OTP key), or each user can opt in from the Two Factor panel with:

• TOTP, any authenticator app, no server setup needed.
• WebAuthn, hardware security keys or platform authenticators. It needs a trusted HTTPS certificate (the docs suggest ACME, for example with the built in pvenode acme commands) and the WebAuthn settings under Datacenter options.
• Recovery keys, single use codes you print and lock away so a lost phone does not lock you out.

The chapter documents lockouts: 8 failed TOTP attempts disable the user's TOTP factors until they log in with a recovery key, and WebAuthn and recovery keys allow 100 tries before all second factors are blocked for an hour. An admin can clear a lockout with pveum user tfa unlock <user>.

API tokens with least privilege

Automation such as a monitoring exporter, Terraform style provisioning or a backup script should never use your password. The user management chapter documents API tokens:

• Tokens can have their own permissions and expiry dates and can be revoked without disabling the user.
• New tokens default to separated privileges: the token gets only what an ACL grants it, intersected with the user's permissions. The docs say to disable privilege separation only when an integration genuinely needs the user's full permissions.
• Set an expiry timestamp so abandoned automation stops working.
• The secret is shown only once, at creation.
• Console endpoints are not available to tokens.

Use the built in roles. PVEAuditor is read only; PVEVMUser can view, back up, power manage and use the console of VMs; PVEVMAdmin fully administers VMs; PVEDatastoreUser can allocate backup space. A monitoring token needs PVEAuditor on / and nothing more.

Containers, guests and the host itself

• Prefer unprivileged containers (the default). The container chapter says they map container root to an unprivileged host user, and that the LXC team considers privileged containers unsafe and does not treat new escapes from them as CVE worthy. Run anything internet facing in a VM.
• Do not run extra services on the host. Every package you add to the hypervisor widens its attack surface and complicates upgrades.
• Keep the host patched, including CPU microcode, which the OpenZFS hardware page notes often fixes CPU errata through BIOS updates, and shut down gracefully on a UPS signal; see our homelab UPS guide.

Step by step: build, cluster, store, back up and lock down

This walkthrough builds two Proxmox VE 9 nodes, pve1 (10.10.10.1) and pve2 (10.10.10.2) on management VLAN 5, a QDevice on a small Debian box at 10.10.10.5, a ZFS mirror for guests on each node, and a Proxmox Backup Server at 10.10.20.10 on a storage VLAN. Adjust names and addresses to your network.

Step 1: write the installer to a USB stick

Warning: the next command overwrites the target device completely. Writing to the wrong device destroys its data. Run lsblk before and after plugging the stick in, and confirm the device path by size and model before you run dd.

Download the ISO from the Proxmox downloads page and compare its SHA256 checksum with the one published there. Then:

# 1. Identify the USB stick: compare output before and after plugging it in
lsblk -o NAME,SIZE,MODEL,TRAN

# 2. Only when you are certain /dev/XYZ is the USB stick:
dd bs=1M conv=fdatasync if=./proxmox-ve_*.iso of=/dev/XYZ

The dd form is the one in the installation chapter. On older hardware, note that the chapter says Secure Boot must be disabled to boot installers older than 8.1; current installers support it.

Step 2: install each node

Boot the stick, choose the graphical installer, and on the target disk page open Options and select ZFS (RAID1) across your two boot SSDs. Set a fully qualified hostname (pve1.lab.example), the management IP on the address you will later move to VLAN 5, and a strong root password. After the reboot the installer prints the URL, https://10.10.10.1:8006.

Log in, then check the version and the virtualization flag:

pveversion
egrep -c '(vmx|svm)' /proc/cpuinfo   # should be greater than 0 on x86

Step 3: configure repositories and update

Without a subscription, disable the enterprise repository and add no-subscription. Edit /etc/apt/sources.list.d/pve-enterprise.sources and add Enabled: no to its stanza, then create /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

If you do not use Ceph, disable the Ceph enterprise stanza the same way. Then:

apt update          # stop here if this prints any error
apt full-upgrade
reboot              # if a new kernel was installed

Repeat steps 2 and 3 on pve2.

Step 4: create the cluster and join the second node

Warning: joining overwrites the joining node's /etc/pve. Join only a freshly installed node with no guests, or back up its guests first.

On pve1, create the cluster with Corosync on the management network as link 0 and, if you have a second NIC, a dedicated link 1:

pvecm create homelab --link0 10.10.10.1 --link1 10.30.30.1
pvecm status

On pve2, join by pointing at pve1:

pvecm add 10.10.10.1 --link0 10.10.10.2 --link1 10.30.30.2

By default, pvecm add authenticates against pve1's API, prompts for its root@pam password and verifies its SHA-256 certificate fingerprint. Afterwards, pvecm status on either node should list two members and Quorate: Yes.

Step 5: add the QDevice

On the external Debian host (not a guest on the cluster):

apt install corosync-qnetd

On both cluster nodes:

apt install corosync-qdevice

On one node:

pvecm qdevice setup 10.10.10.5
pvecm status

The setup copies the cluster's SSH key to the QDevice host, so make sure root can log in there with a key, or temporarily with a password, during setup. If you see Host key verification failed., the cluster chapter suggests pvecm updatecerts. pvecm status should now show the flags Quorate Qdevice and a third vote. Test it: shut down pve2 and confirm you can still start and stop guests on pve1.

Step 6: add a ZFS mirror for guests

Warning: zpool create -f destroys whatever is on the named disks. Confirm every device by serial number with ls -l /dev/disk/by-id/ and lsblk first, and use the by-id paths, never /dev/sdX, which can change between boots.

# 1. Identify the two data disks by model and serial
lsblk -o NAME,SIZE,MODEL,SERIAL
ls -l /dev/disk/by-id/ | grep -v part

# 2. Only after confirming both IDs:
zpool create -f -o ashift=12 tank mirror \
  /dev/disk/by-id/ata-EXAMPLE_SERIAL_A \
  /dev/disk/by-id/ata-EXAMPLE_SERIAL_B

# 3. Register it as Proxmox storage for disk images and container volumes
pvesm add zfspool vmdata -pool tank -content images,rootdir -nodes pve1
pvesm status

The administration guide's ZFS examples use ashift=12 (4 KiB sectors) and the mirror keyword exactly as above. Do the same on pve2, naming the pool identically if you want ZFS storage replication between the nodes. Optionally set up replication for important guests in the guest's Replication panel, every 15 minutes, to the other node.

Step 7: schedule encrypted backups to Proxmox Backup Server

Install Proxmox Backup Server on separate hardware, ideally on the storage VLAN, create a datastore (for example store1) and a dedicated user such as pve-backup@pbs with the DatastoreBackup role on that datastore only. Copy the PBS certificate fingerprint from its dashboard.

On pve1, add the storage with a generated encryption key:

pvesm add pbs pbs-backup \
  --server 10.10.20.10 \
  --datastore store1 \
  --username pve-backup@pbs \
  --fingerprint 'AA:BB:...:FF' \
  --password \
  --encryption-key autogen

The autogen value generates a new key at /etc/pve/priv/storage/pbs-backup.enc. Get it off the host immediately:

proxmox-backup-client key paperkey /etc/pve/priv/storage/pbs-backup.enc \
  --output-format text > qrkey.txt

Print qrkey.txt, store the key in your password manager and on an offline USB stick, then delete qrkey.txt from the host.

Create the schedule under Datacenter, Backup, Add: storage pbs-backup, a nightly time such as 02:00, mode Snapshot, and retention such as keep last 3, daily 7, weekly 4, monthly 6. Enable the QEMU guest agent in VMs for file system freeze. For a one off test:

vzdump 100 --storage pbs-backup --mode snapshot

On PBS, add a daily verify job for new snapshots, a monthly job that re-verifies everything, a prune job and a garbage collection schedule. A manual full verify is:

proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4 --ignore-verified false

Step 8: create an admin user, enable 2FA and an API token

pveum group add admins -comment "Lab administrators"
pveum acl modify / -group admins -role Administrator
pveum user add alice@pve -group admins -password

Log in as alice@pve, open Datacenter, Permissions, Two Factor, add a WebAuthn key (after setting up an ACME certificate) or TOTP, and generate recovery keys. Print them. Once it works, consider requiring TOTP for every @pve login.

For a monitoring exporter, create a separated privilege token with read only rights and an expiry:

pveum user add monitor@pve
pveum user token add monitor@pve exporter -privsep 1 -expire 1798761600
pveum acl modify / -token 'monitor@pve!exporter' -role PVEAuditor
pveum user token permissions monitor@pve exporter

The expiry is a Unix timestamp (1798761600 is 1 January 2027 00:00 UTC). Store the secret printed at creation; it is shown only once.

Step 9: enable the firewall

Open an SSH session to pve1 and keep it open. Then edit /etc/pve/firewall/cluster.fw:

[OPTIONS]
enable: 1

[IPSET management]
10.10.5.0/24   # admin workstation VLAN

Save, then from your admin workstation reload the web interface. From a machine on the guest VLAN, confirm port 8006 is no longer reachable:

nc -vz -w 3 10.10.10.1 8006   # expect a timeout from the guest VLAN

If you lock yourself out, use the open SSH session to set enable: 0.

Step 10: test a restore

Restore a VM backup to a new ID, on the ZFS storage, with a new MAC address, without starting it:

pvesm list pbs-backup --vmid 100
qmrestore pbs-backup:backup/vm/100/2026-10-24T02:00:00Z 9100 \
  --storage vmdata --unique 1

Before starting VM 9100, move its network device to an isolated bridge with no uplink. Start it, check the application data, then destroy it, and write down the date, backup, restore time and what you checked. pct restore follows the same pattern for containers.

Common mistakes

• Building a two node cluster without a QDevice. One node reboots for a kernel update and the other cannot start or stop anything. Add a QDevice or stay on a single node.
• Running Corosync on the storage network. Backup or migration traffic adds latency jitter and nodes drop out of the cluster. Give Corosync its own link and a second fallback link.
• Putting ZFS on a hardware RAID controller. The docs say it is unsupported and can cause data loss. Use an HBA or onboard ports.
• Treating replication or Ceph as backup. They copy deletions and encryption too. Back up to a separate PBS with its own credentials.
• Storing the backup encryption key only on the host. If the host dies, so does every encrypted backup. Use the paperkey, a password manager and an offline copy.
• Never running verify jobs. Chunks can rot on disk. Verify daily for new snapshots and re-verify everything monthly.
• Using the test repository on a lab you depend on. pve-test is for testing new features and fixes. Use no-subscription or enterprise.
• Staying on Proxmox VE 8. It reached end of life in August 2026. Plan the upgrade with pve8to9 and a fresh backup.
• Forwarding port 8006 to the internet. Use a VPN into an admin VLAN instead, and keep 2FA on even behind the VPN.
• Using root@pam for everything, including automation. Create named admin users with 2FA and separated privilege API tokens with expiry for scripts.
• Running internet facing services in privileged containers. Use unprivileged containers or, better, VMs.

FAQ

Is Proxmox VE free for a homelab?

Yes. It is open source under the GNU AGPL v3 and works fully without a subscription, which buys the enterprise repository and support. Without one, use the no-subscription repository, which the docs describe as suitable for testing and non production use.

What version of Debian is Proxmox VE 9 based on?

Proxmox VE 9 is based on Debian 13 Trixie. Proxmox VE 9.0 shipped on 5 August 2025 and the current release at the time of writing is 9.2, released on 21 May 2026 on Debian 13.5 with kernel 7.0, QEMU 11.0 and ZFS 2.4.

When does Proxmox VE 8 reach end of life?

The Proxmox VE FAQ lists Proxmox VE 8 end of life as August 2026, a month after Debian 12's regular security support ended on 11 July 2026. Upgrade to 9 with the pve8to9 checker.

Can I run a Proxmox cluster with two nodes?

Yes, but without a third vote, losing either node makes the cluster configuration read only. Add a QDevice running corosync-qnetd on a separate small machine. The docs recommend a QDevice for two node clusters and discourage it for odd sized clusters.

Do I need ECC memory for Proxmox and ZFS?

Proxmox VE does not require it. The OpenZFS hardware documentation highly recommends ECC because no file system, ZFS included, can protect against bit flips in RAM. Use ECC if the data is irreplaceable; otherwise make sure it is backed up elsewhere.

Should I use ZFS or LVM-thin on Proxmox?

Use ZFS for checksums, snapshots, replication and simple mirrors if you have the RAM (about 1 GB per TB of used storage extra). Use LVM-thin for simplicity, but watch free space: a full thin pool causes I/O errors in every guest on it.

How many nodes do I need for Ceph on Proxmox?

At least three. The Ceph chapter recommends at least three nodes with at least 12 OSDs evenly distributed, three monitors, and 10 Gbps or faster networking. Below that, Ceph works for learning but is slow and fragile.

Is Proxmox Backup Server encryption end to end?

The encryption is client side: Proxmox VE encrypts chunks with AES-256-GCM before upload, and the server stores only ciphertext. Restores need the key, so keep copies off the host with proxmox-backup-client key paperkey, a password manager or a master key.

How do I secure the Proxmox web interface?

Keep port 8006 on a management VLAN only admin devices reach, use a VPN instead of port forwarding, enable the firewall with a management IP set, require TOTP or WebAuthn, and give automation API tokens with separated privileges and an expiry.

Can I run Docker on Proxmox VE?

The FAQ recommends against running Docker directly on the host. Run it inside a VM, which also supports live migration. Running OCI application containers natively as Proxmox containers is a technology preview.

Where Safeguard fits

Safeguard's fit here is indirect, and we would rather say so. The hypervisor layer itself is Debian and Proxmox packages that you update with apt, and Safeguard does not patch or scan the Proxmox host. The software supply chain still matters in a homelab, though: the VMs and containers you run on Proxmox pull open source dependencies and container images every time you rebuild them, and that is where the practices below apply. Safeguard does not scan the Proxmox host kernel, its firmware or its Debian packages, and it does not replace your backups; it helps with the repositories and images you build and run inside the lab.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, run safeguard to open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. In a homelab, the same flow applies to the code and images you deploy into your Proxmox VMs and containers.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. A VM on your Proxmox cluster is a natural place for that runner, so scans of your lab's repositories and images run on hardware you control.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. If you already ask an assistant about your homelab services, this is how you let it query the projects you have scanned without handing it more access than it needs.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Proxmox VE FAQ: base distribution, license, CPU support, support lifecycle, upgrades
• Proxmox VE Roadmap and release history
• Proxmox VE administration guide: Introduction (pmxcfs, history, license)
• Proxmox VE administration guide: Installation and system requirements
• Proxmox VE administration guide: Cluster Manager (pvecm, Corosync, QDevice)
• Proxmox VE administration guide: High Availability
• Proxmox VE administration guide: Storage (pvesm)
• Proxmox VE administration guide: Deploy hyper converged Ceph
• Proxmox VE administration guide: Host system administration (network, VLANs, ZFS, ACME)
• Proxmox VE administration guide: Backup and Restore (vzdump)
• qmrestore manual page
• Proxmox VE administration guide: Firewall
• Proxmox VE administration guide: User Management, API tokens and two factor authentication
• Proxmox VE administration guide: Proxmox Container Toolkit
• Proxmox VE administration guide: QEMU/KVM Virtual Machines
• Proxmox VE Package Repositories
• Proxmox VE: Upgrade from 8 to 9
• Proxmox Backup Server documentation: Introduction
• Proxmox Backup Server documentation: Technical Overview (chunks, deduplication)
• Proxmox Backup Server documentation: Backup Client Usage (encryption, master key)
• Proxmox Backup Server documentation: Maintenance Tasks (prune, garbage collection, verification)
• Proxmox Backup Server documentation: Installation
• Debian releases: release, security and LTS dates
• Debian 13 Trixie release information
• OpenZFS documentation: Hardware
• QEMU documentation: Introduction and virtualisation accelerators
• NIST SP 800-125, Guide to Security for Full Virtualization Technologies

Last reviewed: 24 October 2026. Proxmox VE point releases, kernels and repository layouts change several times a year; check the release notes and the administration guide for your exact version before you run any command that creates, joins, upgrades or destroys a node, pool or backup.