How to Build a Homelab with Proxmox VE: Run Multiple Servers on One Machine

What Proxmox VE does in a homelab

Proxmox Virtual Environment is a Debian-based virtualization platform normally installed directly on a physical server. It is commonly described as a Type-1 hypervisor platform because guest workloads run on the host through kernel virtualization and container facilities rather than through a desktop hypervisor application. That description does not mean there is no host operating system. A Proxmox VE installation includes a Debian host layer, the Linux kernel, KVM/QEMU, LXC, storage services, networking components, and the Proxmox management stack.

KVM virtual machines and LXC system containers solve different problems. A KVM VM emulates or paravirtualizes hardware and boots its own operating-system kernel. An LXC container uses the Proxmox host's Linux kernel while isolating processes, filesystems, users, and networking with Linux container mechanisms. Containers can be efficient, but they do not have the same isolation boundary or operating-system flexibility as VMs.

Plan the failure boundaries before installing

Consolidation makes administration easier, but it also concentrates risk. If the physical host loses power, every guest on it stops. If the only disk fails, the host and its guests may be lost together. If backups are stored only on that host, the same hardware failure, filesystem problem, or administrative mistake can affect both production data and its supposed protection.

Before installation, decide which services are essential, where guest data will live, where backups will be copied, and how the host will be shut down during a power event. Document the management address, bridge layout, storage names, guest IDs, and recovery credentials somewhere that remains available when the server is offline.

Physical and logical traffic flow

A typical single-node design has one physical Proxmox host, a Debian-based host layer, multiple KVM and LXC guests, and a Linux bridge connected to the home LAN. Guest disks reside on local storage, while backups should be written or copied to a separate failure domain. If Localtonet is used, its client runs on a suitable device that can reach the Proxmox management service and establishes an outbound connection to a Localtonet relay. That outbound path does not remove the need to secure the Proxmox login itself.

Hardware, firmware, and network requirements

Do not size a host from an arbitrary promise such as a fixed number of VMs. Capacity depends on each workload's peak CPU demand, active memory, storage latency, network traffic, and availability requirements. Start with an inventory of the services you intend to run, then preserve headroom for the Proxmox host, filesystem cache, backups, updates, and temporary workload spikes.

Address planning

Assign the Proxmox management interface a stable address. This can be a static address configured during installation or a carefully managed reservation, depending on the network design. Avoid choosing an address already inside a DHCP pool unless the router reserves it for the host. Record the address, prefix length, gateway, DNS server, and hostname before beginning.

Plan guest addressing separately. Guests attached to the main bridge can normally obtain addresses from the LAN's DHCP server, use DHCP reservations, or use static addresses that do not conflict with the pool. Infrastructure services such as DNS resolvers should have predictable addresses, while disposable development guests can usually remain dynamic.

Firmware checklist

• Enable Intel VT-x or AMD-V for KVM virtualization.
• Enable Intel VT-d or AMD IOMMU only if PCIe passthrough is planned.
• Use a boot mode supported by the hardware and selected installer configuration.
• Confirm the intended installation disk is visible and distinguish it from every data disk.
• Review boot order so the installer media starts once and the installed disk starts afterward.
• Configure predictable behavior after power loss if unattended recovery is important.

Install Proxmox VE 9.2

The current Proxmox download page lists Proxmox VE 9.2 ISO Installer version 9.2-1. The x86-64 ISO is 1.71 GB, was last updated May 21, 2026, and has the SHA-256 checksum shown below. An ARM64 installer is also listed separately, so download the image matching your architecture.

Proxmox VE 9.2 ISO Installer 9.2-1
SHA-256:
4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6c

sha256sum proxmox-ve_9.2-1.iso

Post-install verification checkpoint

Do not create important guests until the basic host is healthy. In the web interface, confirm that the node is online, the expected processor and memory are visible, the configured storage is active, and the management bridge has the planned address. From the node shell, collect the installed package versions and network state:

pveversion -v
ip address show
ip route show
lsblk

From another LAN device, confirm that the management address responds as expected and that the web interface remains reachable after a controlled reboot. If a second storage disk is intended for later use, verify its identity with lsblk and persistent links under /dev/disk/by-id/, but do not initialize it yet.

Configure Proxmox VE 9 updates correctly

Proxmox VE 9 is based on Debian 13, code-named Trixie. Do not add a Debian 12 Bookworm Proxmox repository to a Proxmox VE 9 host. Mixing release suites can create conflicting dependencies and leave the host in an unsupported package state.

A subscription provides access to the enterprise repository. A non-subscribed homelab can use the no-subscription repository. The subscription notice is expected when no valid subscription is installed. Do not patch Proxmox JavaScript files to suppress it. Such modifications are unsupported, are replaced by package updates, and can make troubleshooting harder.

Preferred repository workflow

Use the repository management interface for the installed Proxmox version when possible. Select the node, open its update repository view, disable enterprise entries for which the host has no subscription, and add the no-subscription Proxmox VE repository. Review the resulting suite before updating. If a Ceph repository has been configured, manage it separately and select only a repository appropriate for that Ceph deployment.

Deb822 configuration for Proxmox VE 9

Current installations may use Deb822 .sources files rather than legacy one-line .list entries. The Proxmox VE 9 no-subscription definition uses the Trixie suite:

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 manage repositories manually, place that definition in an appropriately named file such as /etc/apt/sources.list.d/proxmox.sources. Disable the enterprise Proxmox entry rather than leaving both channels active without understanding the intended package policy. Do not overwrite the Debian base repository definitions, and do not change their suite to a different Debian release.

After confirming the repository configuration, refresh metadata, review the proposed changes, and perform the upgrade:

apt update
apt full-upgrade

Read the package plan before approving it. Investigate held packages, removal of core Proxmox packages, release-suite conflicts, or repository signature errors rather than forcing the upgrade. When a new kernel is installed, schedule a controlled reboot after guests have been shut down or migrated as appropriate. Then verify the running version again with pveversion -v.

Choose between KVM VMs and LXC containers

Create a first virtual machine

Workload-dependent VM options

Create an LXC system container

Understand bridges, guest addressing, and segmentation

A standard installation commonly creates a Linux bridge such as vmbr0 and associates it with a physical network interface. The host management address is configured on the bridge, while VM and container interfaces attach to it as virtual ports. This design lets the host and guests communicate through the physical LAN without giving each guest a physical NIC.

Do not move the management address casually from the bridge to its underlying physical interface. A bridge configuration must preserve the correct physical port, address, prefix, gateway, and VLAN behavior. Network changes can immediately disconnect the browser session, so make them from a local console or with an independent recovery path.

Network verification checklist

• Confirm the Proxmox host has only the intended management addresses.
• Confirm the default route points to the correct router.
• Confirm DNS resolution from the host and each guest.
• Confirm guests attached to the bridge receive addresses from the expected subnet.
• Test traffic between segments against the intended firewall policy.
• Verify that management port 8006 is not exposed by an unintended router port-forwarding rule.

Choose storage by capability and failure behavior

Proxmox separates the physical or logical storage backend from the content placed on it. One storage entry may hold ISO images and backups, while another holds VM disk images and container root filesystems. Snapshot support is not limited to ZFS. It depends on the backend, disk format, and guest configuration.

Thin provisioning improves allocation flexibility but does not create physical capacity. Monitor both guest-visible filesystems and the underlying thin pool or ZFS pool. A snapshot also consumes storage as changed blocks accumulate. Long-lived snapshots can therefore cause unexpected capacity pressure.

Create a ZFS pool only after designing redundancy

Use the Proxmox storage interface or an official ZFS workflow, and identify disks through persistent paths under /dev/disk/by-id/. Device names such as /dev/sdb can change across boots or hardware changes.

First inspect the available devices and persistent identifiers:

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
ls -l /dev/disk/by-id/

A two-disk mirror has the following command shape. Replace both placeholders with the complete, verified persistent identifiers for the intended disks:

zpool create -f vmdata mirror \
  /dev/disk/by-id/REPLACE_WITH_FIRST_DISK_ID \
  /dev/disk/by-id/REPLACE_WITH_SECOND_DISK_ID

zpool status vmdata
zpool list vmdata

Do not copy that command until the disk identities and desired redundancy are confirmed. After the pool reports healthy, add it through Datacenter → Storage → Add → ZFS, choose the pool, and select only the content types it should hold. Test a disposable guest before moving important workloads.

Do not enable ZFS deduplication as a routine homelab optimization. It adds substantial operational and memory considerations and should be used only after workload-specific evaluation. Compression is a separate feature and should not be confused with deduplication.

Use community helper scripts cautiously

The Proxmox VE Helper-Scripts community project provides one-command installation workflows for services, containers, and VMs. Its current requirements list Proxmox VE 8.4, 9.0, 9.1, and 9.2, root shell access on the Proxmox host, and internet connectivity during installation.

Because individual script paths and commands can change, use the current community script catalog instead of copying a stale raw script URL from an old article. Search for the service, open its current page, confirm that Proxmox VE 9.2 is supported, read the documented default resources and post-install notes, and inspect the command before running it.

Build a backup and restoration workflow

Proxmox snapshots, built-in backup jobs, and Proxmox Backup Server serve related but different purposes. A snapshot is primarily a short-term rollback point on compatible storage. A backup is a separate recovery artifact. A useful backup plan must account for where the artifact is stored, how long it is retained, how integrity is checked, and whether anyone has successfully restored it.

Place backups in a separate failure domain

A backup stored on the same physical disk as the source does not protect against disk failure. A backup stored on another disk in the same host improves some recovery scenarios but remains vulnerable to host-level failure, theft, power events, and administrative mistakes. Prefer a destination on another system or otherwise separated storage. Proxmox Backup Server can be deployed as a dedicated backup platform, but deploying it as a VM on the only protected host does not create a separate hardware failure domain by itself.

Create and test the backup job

1. Add a backup destination with enough capacity and an appropriate separation from primary storage.
2. Create a scheduled backup job under the datacenter backup configuration.
3. Select the intended guests explicitly or use a controlled selection policy.
4. Set a retention policy that matches available capacity and recovery requirements.
5. Run an initial job manually and read the complete task log.
6. Confirm that the backup is present on the intended destination.
7. Restore a non-production copy using a new guest ID and an isolated bridge or disconnected network interface.
8. Boot the restored guest and validate files, databases, application logins, and service startup.
9. Delete or securely retain the test restoration according to the data policy.

Access the Proxmox interface remotely with Localtonet

The safest default is to keep the Proxmox management interface available only on a trusted management network. When remote browser access is genuinely required, Localtonet can expose a service reachable by a connected device without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The Localtonet client establishes an outbound connection to one of our relay servers, and the tunnel is available only while the selected client is connected and the tunnel is running.

Prepare Proxmox before creating the tunnel

• Install all reviewed security and platform updates.
• Create a named administrator with only the permissions needed for remote tasks.
• Enable multifactor authentication for the remote administrative identity.
• Remove or disable stale accounts and API tokens.
• Confirm the management interface is not already exposed through router port forwarding.
• Review Proxmox firewall and other available access restrictions.
• Verify that the chosen Localtonet client device can reach the Proxmox HTTPS service locally.

The Localtonet client does not have to run directly on the Proxmox host. It can run on a separate, maintained device that has network reachability to the management address. This separation can reduce changes to the hypervisor host and makes the access path easier to disable independently.

Remote verification checklist

• The public address is reachable only while the intended client and tunnel are running.
• The target resolves to the correct Proxmox host rather than another service on port 8006.
• The dedicated account can perform approved tasks but cannot perform unnecessary operations.
• Multifactor authentication is enforced for remote administration.
• No token, local address, hostname, or session information is exposed in shared screenshots.
• Stopping the tunnel makes the public address unavailable.
• Local access remains available after the tunnel stops.

Operate the homelab safely

Update and reboot deliberately

Check repository health before every update. Read release notes for significant upgrades, verify that current backups have completed, and avoid updating the host immediately before it must perform an important task. Use apt update and review apt full-upgrade output rather than applying package changes blindly.

When an update installs a new kernel or otherwise requires a reboot, shut down guests cleanly or schedule the reboot during a maintenance window. Afterward, verify the running kernel, node health, storage status, networking, and each critical service. A package installation finishing successfully does not prove that every guest application recovered.

Monitor resources and storage capacity

Watch host CPU load, memory pressure, swap activity, storage latency, network errors, and task logs. Also monitor the capacity of LVM-thin pools, ZFS pools, directory filesystems, and backup destinations. Thin provisioning and snapshots can allow logical allocations to exceed currently used physical space, so a host can run normally until changed blocks consume the remaining capacity.

Set practical warning thresholds in whatever monitoring system you operate, but keep enough free space to complete maintenance, snapshots, migrations, and backup operations. Investigate unexpected growth rather than only deleting files after storage is already full.

Define guest startup and shutdown order

Guest dependencies should control startup order. A DNS or directory service may need to start before applications that rely on it. A database should be available before its frontend. On shutdown, dependent applications should stop before the database or storage service they use.

Configure only important guests for automatic startup, assign deliberate startup order and delay values, and test a full host reboot. Confirm that guests shut down cleanly before the host powers off. Forced shutdown can damage application data even when the virtual disk remains intact.

Useful inspection commands

Commands that change guest state should be used only after confirming the guest ID and understanding application shutdown requirements. Prefer graceful shutdown through the guest operating system or Proxmox controls before considering forced stops.

Focused troubleshooting

Frequently asked questions