Proxmox VE dedicated servers

A Proxmox dedicated server is a physical, single-tenant machine running Proxmox VE — the Debian-based open-source virtualisation platform — directly on the hardware. Instead of renting a slice of someone else’s hypervisor, you get the whole box: a web UI and REST API for spinning up KVM virtual machines and LXC containers, full root on the host, and every core and gigabyte of ECC RAM to allocate as you see fit.

The strongest reason to run it here is the economics and the ownership. Proxmox VE is released under the GNU AGPLv3 and is free to run in production with no per-socket or per-core hypervisor licence — a paid subscription buys the enterprise update channel and support, not the features. Deploy it as a ready image on ECC EPYC hardware in under a minute, and the entire virtualisation host is yours — no VMware-style per-core bill, and no shared hypervisor between you and the metal.

New to hypervisors? Read our bare-metal hypervisor guide.

What Proxmox VE actually is

Proxmox VE is a complete virtualisation platform, not just another Linux distribution. It layers a management stack on top of Debian — the current release, Proxmox VE 9.2, is built on Debian 13 "Trixie" — and gives you two virtualisation technologies under one roof: the KVM hypervisor for full virtual machines and LXC for system containers. You drive both from a single web interface on port 8006, or from a REST API and the pvesh / qm / pct command-line tools if you would rather automate.

Because the whole platform is open-source, everything is on the host and nothing is held back behind a licence tier. Built-in clustering, live migration, software-defined storage with ZFS and Ceph, an integrated firewall, and a backup framework all ship in the free download. On a Serverside box you have full root over that host, so the version you run, the repositories you enable, and the update cadence are entirely your call — the appliance is yours to operate, not a managed slice you rent access to.

Subscription vs no-subscription repositories

This is the part that trips up first-time Proxmox operators, and it is worth getting straight. Proxmox VE ships with the Enterprise APT repository enabled, which requires a paid subscription key to pull from. Without a key, apt updates fail against that repository — so the first thing most people do on a fresh box is switch to the free no-subscription repository instead. On Proxmox VE 9 both are defined in the modern deb822 .sources format under /etc/apt/sources.list.d/, and you disable the one you are not using rather than deleting it.

The two repositories differ in testing and support, not in features. Proxmox’s own guidance is that the no-subscription repository "can be used for testing and non-production use" and is "not recommended on production servers", because its packages are not as heavily validated as the enterprise channel. A subscription is billed per occupied CPU socket per year — a socket counts once regardless of core count — and unlocks the stable enterprise repository plus support tickets with an SLA. It does not unlock any feature: every capability is already in the free download.

Whichever repository you choose, a host without an active subscription shows the familiar "No valid subscription" dialog on web-UI login. It is a nag, not a limitation — the platform is fully functional either way. Because you own root on a Serverside machine, you decide whether to buy a subscription for the enterprise channel and support, or run the no-subscription repository and manage updates yourself.

VMs vs LXC containers — when to use which

Proxmox gives you two ways to carve up a host, and choosing well is most of the skill. A KVM virtual machine is full hardware virtualisation: it boots its own kernel, runs any operating system — Windows, the BSDs, any Linux — and is strongly isolated from its neighbours and the host. That isolation and OS-agnosticism is why VMs are the right choice for anything you do not fully trust, anything non-Linux, and anything you want to live-migrate between cluster nodes with no downtime.

An LXC container is a system container: it shares the host’s kernel and runs a Linux userland on top of it. That makes it far lighter than a VM — it starts in a fraction of a second, carries almost no memory overhead, and lets you pack many more workloads onto the same hardware. The trade-off is that it must be Linux and the isolation is weaker than a full VM, since every container leans on the one shared kernel.

In practice most Proxmox hosts run a mix: LXC for the dense estate of Linux services where efficiency matters — reverse proxies, internal tooling, self-hosted apps — and KVM VMs for Windows guests, anything requiring a different kernel, and workloads that need firm isolation or live migration. A 32-core, 512 GB box has ample headroom to run both patterns at once.

Storage: ZFS, Ceph, and LVM-thin on bare metal

Proxmox VE supports several storage backends, and running on bare metal is what lets you pick the right one instead of inheriting whatever a cloud host imposes. On a single node, the two defaults you meet are local — a directory store for ISO images, container templates, and backups — and local-lvm, an LVM-thin pool holding VM disks and container root volumes. If you install onto ZFS instead, that block store becomes local-zfs.

ZFS is the popular single-node choice because it brings instant snapshots, block-level replication between nodes, checksummed data integrity, and compression to your VM storage. The cost is RAM: ZFS wants roughly 2 GB of base memory plus about 1 GB of ARC cache per terabyte of pool. Recent Proxmox installs cap the ARC at 10% of installed RAM by default, but the rule of thumb is why virtualisation hosts want plenty of memory — which is exactly why our sample configurations lead with 384 GB and 512 GB of DDR5.

Ceph is the other end of the scale: a distributed, self-healing storage layer that pools disks across a cluster so any node can run any VM, integrated directly into the Proxmox web UI. It is genuinely hyper-converged and genuinely demanding — Proxmox recommends at least three nodes and a dedicated network of 10 Gbps or more for Ceph traffic, rising to 25 Gbps and beyond for NVMe-backed pools. That is where owning the bare metal pays off: real NVMe on the host and a fast private uplink between your servers are what make replicated and clustered storage perform, rather than a virtualised disk on a shared backend.

Clustering, quorum, and HA

Several Proxmox hosts can be joined into a single cluster, managed as one. Under the hood corosync handles messaging between nodes and pmxcfs — the Proxmox Cluster File System — keeps /etc/pve in sync across all of them, so every node sees the same VMs, storage, and configuration. From there you get live migration and, with shared or replicated storage, high availability that restarts guests elsewhere when a node fails.

The catch every cluster operator learns is quorum. A cluster only acts when a majority of nodes can vote, which is why an odd number of nodes is recommended and why three is the practical minimum for reliable HA. A two-node cluster cannot hold quorum on its own if one node drops — the fix is a QDevice, a lightweight external arbitrator that supplies a tie-breaking vote so a two-node (or even-node) cluster survives a single failure.

This is where owning the network matters as much as owning the hardware. Corosync is latency-sensitive and Ceph replication is bandwidth-hungry, and neither belongs on your public interface. You can put virtual private networking between your Serverside servers so cluster messaging, storage replication, and live-migration traffic all ride a private link, keeping the management and replication plane off the public internet entirely while the fast uplink carries the load.

Deploying Proxmox VE on Serverside

Proxmox VE is a first-class deployment image in our OS catalog, so a fresh hypervisor is imaged onto bare metal and reachable at its web UI in under a minute — no ISO to mount, no installer to click through before you can build a VM. From there the host is entirely yours: full root means you choose which repository to run, when to upgrade, whether to buy a subscription, and how to lay out your cluster, with nothing locked from our side.

If you would rather build the host yourself, you can. A custom iPXE configuration lets you netboot your own Proxmox build or a pinned version onto the metal, and plug-and-play ISO mounting with KVM console access is always there as a fallback — mount the Proxmox installer, watch it come up from the console, and pick your own ZFS layout. Either way the network edge sits in front of the hypervisor: always-on, inline DDoS mitigation on our 2 Tbit/s+ network filters attacks before they reach your management plane on port 8006, and self-service firewall rules let you restrict who can reach it.

Boot your own Proxmox build with custom iPXE

You are not limited to our stock image. Custom iPXE configurations let you chain-boot a Proxmox build or installer you control straight onto the hardware, so the host comes up exactly as you specified rather than from a template you did not choose.

That is the route for teams that pin a specific Proxmox and kernel combination across a fleet, or that fold post-install steps — repository selection, storage layout, cluster join — into a single reproducible boot definition. We hand you the metal and stay out of the boot chain.