Proxmox Was Supposed to Be for Homelabs. Then Someone Reported 10,000 VMs.

Proxmox VE is used for production workloads well beyond small homelabs, according to operators reporting clusters from more than 100 to over 10,000 virtual machines. Those are self-reported figures, not audited deployment totals; the operational test is whether storage, backups and support survive failure.

The accounts discussed clusters across sites, Ceph design, hardware monitoring and backup software choices. The numbers show reported use cases, while the differences between those environments explain why a VM count alone is poor evidence of reliability.

How large are reported Proxmox production deployments?

Operators reported installations ranging from a five-node, 100-plus-VM cluster to a claimed estate exceeding 10,000 VMs, without independent verification.

One operator reported roughly 1,000 production VMs across six locations. When asked for details, they described nine clusters with 41 hosts, plus three standalone hosts used mostly for Proxmox Backup Server and a few other VMs. Their largest individual cluster had eight nodes, and they said Proxmox Datacenter Manager provided a common management view. That distinction matters. A thousand VMs distributed across independent clusters is a different engineering problem from forcing a thousand workloads into one enormous failure domain. The respondent was describing an estate, rather than one giant failure domain.

Then came the most startling claim: another participant said their environment spans three regions, each with three clusters of 30 to 40 servers, hosting more than 10,000 VMs in total. They described NVMe storage, large memory configurations, and multiple 25 Gb network connections. It's an impressive self-reported deployment, not an independently audited benchmark or a recommendation to copy the architecture. Other accounts were easier to picture: a European education operator described 400 VMs on twelve Dell PowerEdge servers, Pure Storage over iSCSI, Cisco networking, and Veeam backup. A different respondent mentioned approximately 800 VMs across two data centers. Clearly, the familiar image of a spare homelab PC misses part of the user base.

The smaller stories may be more useful. A business described moving from a three-host VMware Essentials environment to a five-node Proxmox cluster while keeping its servers, storage, and backup software. Failover tests for a planned ERP deployment had gone well, although the team still wanted more network and firewall redundancy. Another operator reported about ten years running hundreds of Windows and Linux VMs. A university administrator outlined systems spanning payroll, ERP, OpenShift, databases, authentication, networking services, and content management. These systems must work when people arrive on Monday morning.

What makes Ceph risky in small Proxmox clusters?

Ceph availability depends on failure domains, replica policy and enough remaining capacity after a node fails.

The original five-node cluster used Ceph, and that immediately exposed a dividing line in the discussion. One operator described a 25-node Ceph deployment, praising how straightforward it felt to manage from the Proxmox interface. Another said they had run a ten-node hyperconverged cluster carrying about 230 internal and customer VMs for nearly five years, with 100 Gb networking between nodes. A separate participant had moved from iSCSI to Ceph after years on Proxmox and did not regret it. They had the node count and networking to treat distributed storage as an architectural choice.

Before extrapolating from a large VM count, inspect the Ceph cluster availability tradeoffs, which focus on what happens after a node is lost.

Not everyone shared that confidence at smaller scales. One service-provider administrator said their three-node hyperconverged Ceph clusters worked for management services but felt uncomfortably vulnerable when a node failed. For critical customer workloads, they personally would not choose fewer than five nodes. That is a risk preference, not a universal rule. Still, meeting a minimum cluster size does not automatically mean the system has enough spare capacity, failure tolerance, or recovery speed for its workload. Someone else suggested adding a QDevice to a two-node setup, prompting a useful correction. A QDevice helps Corosync quorum; it does not create an extra Ceph storage node or repair Ceph's data-placement risks.

Several administrators avoided Ceph altogether. One reported a three-node environment with roughly 100 workloads using ZFS volumes, replication, and HA. Another used LINSTOR for two small three-node clusters. Others discussed local ZFS arrays, external Fibre Channel storage, iSCSI, and NVMe over TCP. A particularly detailed operator described enterprise SSDs, fast storage networks, and scheduled ZFS replication between availability domains. Their preference for asynchronous replication reflected a conscious tradeoff: lower write latency in exchange for a recovery point that could trail the latest committed transaction by several minutes. For production, what matters is what fails, what survives, and what the application can afford to lose.

There was also an appealingly ordinary question buried beneath all that network hardware: how difficult is a failed Ceph disk replacement? One person answered that an administrator removes the bad OSD, replaces the drive, assigns the replacement, and lets Ceph recover. That's a useful outline, but the casual description skips the stressful part. Rebalancing consumes capacity and bandwidth, and the cluster needs enough healthy replicas and space to recover safely. At small scale, that margin can disappear faster than expected. A recovery procedure that looks simple when every node is healthy feels very different while applications are already degraded.

Can Proxmox Backup Server cover production recovery?

Proxmox Backup Server is one recovery option, but production readiness depends on tested restores and independent copies.

Some of the strongest production advocates weren't using the same backup stack. One operator described enterprise hardware, monitoring, security scanning, and a 3-2-1 backup topology built around Proxmox Backup Server. Another ran a modest manufacturing cluster with a few critical VMs and used PBS with an off-site copy. For these administrators, backup wasn't an optional accessory. It was part of why they felt comfortable placing real workloads on the platform. The official Proxmox Backup Server documentation describes off-site synchronization and multiple copies, while its verification guidance explains how backup data can be checked for integrity. Neither feature removes the need to rehearse an actual restore.

For the recovery layer, compare plans against a practical Proxmox backup strategy with restore testing.

The argument became sharper when someone asked why a large Proxmox installation used Veeam instead of PBS. One answer was mundane: the organization already owned Veeam under a long-term contract. Others were more pointed. A respondent preferred Veeam for customer systems that could not tolerate extended downtime, arguing that automated testing and warm standby arrangements fit some recovery requirements better than a conventional PBS restore. Another felt PBS was effective but less polished for their needs, especially around tape workflows. Those are opinions and descriptions of particular environments, not proof that one product is categorically safer. Feature coverage, version, licensing, and recovery architecture all need to be checked against the actual workload.

One commenter added another layer of irony: after years of using Veeam, they were now searching for a replacement because of cost and features they no longer needed. That frustration echoes the reason many organizations evaluate Proxmox in the first place. Escape from an expensive virtualization stack can still leave a complicated backup bill, while choosing a less expensive tool can increase the engineering work expected from the team. Recovery is judged by restart time, data loss, and whether anyone rehearsed the procedure.

When is Proxmox ready for enterprise workloads?

Proxmox is ready for a given workload only when the operator can document capacity, monitoring, supported upgrades and a credible recovery plan.

Perhaps the most revealing reply came from an administrator using HPE servers, enterprise SSDs, fast Arista networking, Fortigate firewalls, backup infrastructure, and routine security work. Their Proxmox environment was stable, they argued, because they treated the platform like enterprise infrastructure. That sounds obvious until it meets the temptation to view a lower software bill as permission to save money everywhere else. Proper hardware, segmented networks, monitoring, controlled changes, and tested recovery plans remain necessary. A hypervisor does not remove those obligations. If anything, a team moving away from a familiar ecosystem has to prove it can perform them under pressure.

The discussion also included a less heroic approach: keep the most sensitive machinery on the system already trusted to run it. One participant described hybrid customers who left fermentation-tank telemetry and equipment control on Hyper-V while moving bookkeeping, databases, and mailing-list services to Proxmox. That is not a dramatic platform conversion, and it will never make an impressive migration slide. It is still a legitimate production strategy. The organization gets practical experience with a new stack and can expand only after the failure modes, backup process, and operational responsibilities make sense. For some teams, gradual trust is worth more than a clean architectural diagram.

The reported examples, from a few dozen business systems to a claim exceeding 10,000 VMs, establish something narrower and more useful than a victory for Proxmox over every alternative. Operators are already using it for work that matters. Their success stories deserve attention, but so do the warnings about small Ceph clusters, replication gaps, incomplete recovery automation, and upgrades to customized hosts. No community thread can certify a platform for a particular company's uptime requirements. What it can do is replace a lazy question, "Is Proxmox only for homelabs?", with a harder one: who is responsible for making production survive the day everything stops going to plan?

For the operator who asked, a five-node cluster and 100-plus VMs were already a meaningful beginning. The replies offered reassurance, but also a more demanding standard. The largest number in the room wasn't the measure of maturity. The plan for losing a node, a storage pool, or an entire site was.

I would approve Proxmox for production when the team can demonstrate monitored failure recovery and a supported maintenance process, regardless of whether the estate holds 20 or 10,000 VMs. If those capabilities are absent, start smaller and validate them before adding more workloads.