PegaProx: a multi-cluster control plane for Proxmox VE and XCP-ng

The problem PegaProx targets: one pane for many Proxmox clusters

Proxmox VE ships its own web interface, and that interface is scoped to one cluster. If you operate two clusters, you operate two browser tabs, two user lists, two sets of API tokens and two places to look when a node fails. PegaProx exists to collapse that. The README describes it as a web-based management interface for Proxmox VE and XCP-ng clusters, with the ability to manage multiple clusters from a single dashboard covering live monitoring, VM management and automated tasks. The audience is the sysadmin who already has Proxmox running and now has more than one deployment to look after, or a mixed estate where Proxmox and Xen sit side by side. The topics list on the repository confirms the framing: multi-cluster, high-availability, load-balancing, self-hosted. This is not a hypervisor. It is a control layer that talks to hypervisors you already run.

How PegaProx is put together: SSE metrics, role-scoped tokens, per-VM ACLs

The README states that live metrics for CPU, RAM and storage are delivered over SSE, server-sent events. That choice matters for anyone sizing a deployment: SSE is a long-lived HTTP connection per client, so the metrics stream scales with concurrent dashboard viewers rather than with the number of clusters being polled. Access control is layered. There are built-in roles (Admin, Operator, Viewer) plus custom roles, Bearer API tokens that are scoped per role, VM-level ACLs for fine-grained permissions on individual guests, and a multi-tenancy feature that the README describes as isolating clusters for different tenants. Authentication options include TOTP two-factor with a force option, WebAuthn and FIDO2 hardware keys used either passwordless or as a second factor, and LDAP or OIDC against Active Directory, OpenLDAP, Entra ID, Keycloak, Google Workspace and Authentik, with PKCE noted for the OIDC path. The breadth here is the interesting part. A single-cluster Proxmox install rarely needs per-VM ACLs and custom roles; a managed-services provider running several clusters for several customers does. The repository lists JavaScript as the primary language, while the README's badge and the docs point at Python 3.8+ as part of the stack, so expect a JavaScript front end over a Python service layer rather than a single-language codebase.

Getting PegaProx running, and what the README does not give you

This is where the supplied material runs thin, and it is worth saying so plainly. The README lists a website at pegaprox.com, documentation at docs.pegaprox.com, a releases page, a plugins site and a sponsorship page, but it does not include an installation command, a Docker invocation, a configuration file example or a table of config keys. The Python 3.8+ badge implies a Python runtime is expected, and the JavaScript front end implies a Node build step somewhere in the pipeline, but neither is spelled out in the text I have. Anyone evaluating PegaProx should treat docs.pegaprox.com as the actual starting point and check there for the deployment method, the port the web interface binds to, where cluster credentials are stored, and how upgrades are applied. Do not assume a container image exists because the project is self-hosted; the README does not claim one. The one operational detail the README does commit to is on the ESXi side: the ESXi host must have SSH enabled for the import wizard, and the project recommends a maximum of one running VM for the near-zero-downtime transfer path, with offline migration as the more reliable option. That single recommendation tells you more about the maturity of live migration than any feature bullet does.

Where PegaProx is the wrong tool, and what the labels admit

Read the qualifiers. XCP-ng integration is tagged Tech Preview, which covers pool support, power actions, VNC via XAPI, disk and NIC management, and maintenance mode with automatic VM evacuation. Backup verification is tagged Experimental, and the README describes its flow as automated restore, boot, health check and cleanup, with ISO 27001, SOC 2 and HIPAA compliance named alongside it. A feature that restores a backup to prove it works is genuinely useful, but an experimental one should not be the only thing standing between you and a compliance audit. Cross-hypervisor migration between ESXi, Proxmox VE and XCP-ng is listed without a preview label, yet the ESXi guidance to migrate one running VM at a time suggests it is not a bulk operation. If you run a single Proxmox cluster, PegaProx adds a second web interface, a second auth path and a second thing to patch for no consolidation benefit. If you need full XCP-ng management rather than monitoring and power actions, the tech preview label is a stop sign, not a roadmap promise.

The alternative: Proxmox's own interface plus external tooling

The obvious comparison is the Proxmox VE web interface itself, and the difference is architectural rather than cosmetic. Proxmox's interface is a per-cluster view backed by the cluster's own authentication and its own API tokens. It has no concept of a second cluster, so consolidating users, roles and audit across clusters means either synchronising accounts by hand or putting something in front. PegaProx is that something: it holds the identity layer, the role model and the per-VM ACLs, and reaches out to each cluster underneath. The trade-off is a new trusted component. With the native interface, credentials never leave the cluster's own auth system. With PegaProx, the dashboard needs credentials or tokens for every cluster it manages, and it becomes a single point of failure for the management plane even though the clusters themselves keep running. That is the real cost of consolidation, and it is not a reason to avoid the tool, but it is a reason to decide deliberately rather than by default.

Licence and the cost of keeping up with releases

PegaProx is AGPL-3.0. For internal use, that generally means you can run it and modify it, but the network clause is the part to read carefully: if you expose a modified version to users over a network, the AGPL's source-availability obligation can attach to your modifications. I am not a lawyer and this is not legal advice; if you plan to fork PegaProx into a hosted service, get the licence text in front of someone qualified. The release cadence visible in the material is brisk: v1.0.2 on 2026-08-17, v1.1.0 on 2026-08-31, v1.1.1 on 2026-09-07. Three releases in roughly three weeks, with the latest push on 2026-09-10. For an operator that means upgrade work is recurring, and because the project is funded through sponsorships and Open Collective rather than a subscription, there is no vendor SLA attached to it unless you buy the commercial support listed on the sponsors page. Budget for reading release notes before each upgrade, particularly while XCP-ng and backup verification carry preview and experimental labels.

Who should adopt PegaProx, and the three things to check first

The fit is narrow and clear. You run two or more Proxmox VE clusters, or a mixed Proxmox and XCP-ng estate, and the cost of managing identity, roles and monitoring separately has become the actual problem. PegaProx's RBAC, VM-level ACLs, multi-tenancy, LDAP and OIDC support and SSE-based metrics all address that directly. You should not adopt it if you have one cluster, if you need XCP-ng at parity with Proxmox today, or if you cannot accept a dashboard that holds credentials for every cluster it manages. Three things to verify before you commit. First, on docs.pegaprox.com, confirm which listed features are GA and which still carry the tech preview or experimental label, since the README applies those labels unevenly across the feature list. Second, confirm the deployment method and upgrade path, because the README supplies neither. Third, test your identity provider against the LDAP or OIDC path, including the PKCE flow, before you migrate real users onto it. If the XCP-ng tech preview and the experimental backup verification are the features you actually want, wait for the labels to come off.

Editorial conclusion

Adopt PegaProx if you run more than one Proxmox VE cluster and want a single RBAC and identity layer in front of them, and if you can live with XCP-ng support marked tech preview and backup verification marked experimental. Do not adopt it as a replacement for the native cluster tools if you run exactly one cluster, or if you need XCP-ng feature parity today. Before deploying, verify three things against docs.pegaprox.com: whether the cross-cluster load balancer and cross-hypervisor migration are GA or preview, how the AGPL-3.0 network clause applies to your internal deployment, and whether your identity provider works through the LDAP or OIDC path with PKCE.

Official sources

1. License: AGPL-3.0
2. PegaProx/project-pegaprox on GitHub
3. Project website
4. README
5. Releases