ProxCenter: a multi-cluster control plane for Proxmox VE
ProxCenter is an alternative to VMware vCenter for Proxmox environments. It provides a modern, intuitive web interface to manage multiple Proxmox VE clusters and Proxmox Backup Server instances from a single pane of glass.
At a glance
- What is it?
- ProxCenter is a TypeScript web application that puts several Proxmox VE clusters and Proxmox Backup Server instances behind one interface, with a Community edition and a paid Enterprise tier that adds DRS, alerts and a three-node HA control plane.
- Who is it for?
- Adopt ProxCenter if you run more than one Proxmox VE cluster and want one console for inventory, consoles, backup visibility and RBAC, and if you accept that DRS, alerting and the three-node control plane sit behind an Enterprise token. Do not adopt it if you manage a single standalone PVE host, since the native web UI already covers that case without a second PostgreSQL database in the path.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ProxCenter targets in a Proxmox estate
Proxmox VE ships a competent per-cluster web UI. The friction starts when an operator has more than one cluster, or a cluster plus a Proxmox Backup Server, and has to keep separate browser tabs, separate credentials and separate mental models for each. The README frames ProxCenter as an alternative to VMware vCenter for Proxmox environments: a single console where every cluster appears in one inventory, alongside PBS instances. The topic list on the repository points at the same audience, naming ceph, cluster-management, datacenter, pbs and pve-cluster. This is aimed at infrastructure teams and managed service providers who already run Proxmox at a scale where per-cluster logins have become the bottleneck, not at someone with one node in a homelab. The Enterprise MSP mode, described as multi-tenant fleet management with license stacking, makes that second audience explicit.
Architecture: one port, PostgreSQL as the only source of truth
The architecture section of the README is unusually specific for a UI project, and it is the part worth reading first. A single process serves both HTTP and WebSocket on port 3000, with Nginx optional in front for TLS termination. PostgreSQL is described as the only source of truth, and schema migrations run at startup rather than as a separate operator step. Proxmox VE, Proxmox Backup Server and the migration source hypervisors are all reached outbound, with no agent installed on the managed hosts. That last point matters for change control: adopting ProxCenter does not mean touching every PVE node. The Enterprise tier adds two internal-only components, a Go orchestrator that handles DRS, jobs, alerts, reports and flow telemetry, and a WeasyPrint sidecar for PDF rendering. Neither is exposed publicly according to the diagram description, which keeps the externally reachable surface at the single application port. The stack is Docker Compose based, and the installer places persistent volumes under /opt/proxcenter.
Installing and upgrading the Compose stack
The README gives two install paths. The Community edition is a one-liner: curl -fsSL https://proxcenter.io/install/community | sudo bash. The Enterprise edition uses the same script with a token argument: curl -fsSL https://proxcenter.io/install/enterprise | sudo bash -s -- --token YOUR_TOKEN. According to the README, the installer provisions Docker, the Compose stack, PostgreSQL and the persistent volumes under /opt/proxcenter, after which the operator opens http://your-server:3000 and creates the first admin account. Upgrades are a pull and a restart from that directory: cd /opt/proxcenter, then docker compose pull and docker compose up -d. Schema migrations run automatically on startup, so there is no separate migration command to remember. One configuration detail is called out explicitly: if ProxCenter sits behind a reverse proxy, the README says to enable the "Behind reverse proxy" toggle in the connection settings, otherwise failover can switch to the internal node IPs. That is a small setting with a large failure mode, and it is the kind of thing that only shows up during an incident if it was missed at install time. Note that piping a remote script into sudo bash means trusting whatever proxcenter.io serves at that moment; the README does not describe a signature or checksum step.
Where the Community edition stops and Enterprise begins
The feature list marks three items as Enterprise: DRS workload balancing, which the README attributes to the Go orchestrator; alerts, reports and notifications, covering email digests, severity routing and scheduled reports; and MSP mode for multi-tenant fleet management. High availability is also Enterprise, and it is the most opinionated part of the design. Three nodes sit behind a Keepalived virtual IP with quorum on two of the three. PostgreSQL is replicated by Patroni, which elects a single writable primary through etcd. Every node runs a local HAProxy that routes database traffic to the current primary and leader-only traffic, DRS included, to the elected orchestrator. Converting an existing single-node install is driven by a wizard under Settings > High Availability, and the README points to a separate HA prerequisites page. The Community edition still covers multi-cluster inventory, topology including the Ceph CRUSH tree, noVNC and SPICE consoles, backup and replication visibility, and RBAC with SSO. For a team that mainly wants one inventory view and consolidated consoles, the free tier is the substantive part of the product.
The licence metadata does not match the product tiers
GitHub reports the licence as NOASSERTION, meaning the repository does not carry a licence file that the platform can classify. The README's own badge says "Community | Enterprise", and the install commands are split along the same line. Those two facts together mean the terms that actually govern your use are not visible in the repository metadata. This is not a reason to avoid the project, but it is a reason to read the Community and Enterprise terms on proxcenter.io before a procurement decision, and to have someone who can interpret them look at the MSP mode in particular, since multi-tenant use and license stacking raise questions a single-site deployment does not. Nothing in the supplied material describes the licence text itself, so treat the tier boundary as a commercial question rather than a code question. The repository does run CodeQL and a security scan workflow, and links SonarCloud badges for security, reliability and maintainability ratings, which at least indicates automated analysis is part of the pipeline.
Migration claims and the limits of what the README shows
Cross-hypervisor migration is listed as a feature, covering VMware, Hyper-V, Nutanix and XCP-ng, with warm migration via CBT called out. That is an ambitious claim, and the README does not document per-source caveats, supported guest operating systems, or what happens to a VM whose source disk layout has no clean mapping to Proxmox storage. A screenshot labelled Hypervisor Migration is not evidence about edge cases. The same caution applies to the warm migration path specifically: CBT-based transfer depends on the source hypervisor exposing changed-block tracking in a usable form, and the material here does not say which source platforms that covers. If migration is the reason you are evaluating ProxCenter, the honest position is that the repository shows the feature exists as a UI surface, not that it handles your particular source estate. Test it against one disposable VM per source platform before planning a fleet cutover. The backup and replication feature is described as fleet-wide visibility and reporting, which is a monitoring claim rather than a claim that ProxCenter replaces PBS scheduling.
How this differs from running the Proxmox UI and PBS side by side
The realistic alternative is the combination most Proxmox operators already use: the native Proxmox VE web interface per cluster, the Proxmox Backup Server interface for backup, and something like Grafana or Zabbix for cross-cluster metrics. That combination has no additional database, no Docker stack, and no outbound credentials stored in a third-party application. Its weakness is exactly ProxCenter's premise: there is no shared inventory, no single RBAC model spanning clusters and PBS, and no unified console. ProxCenter's architectural difference is that it introduces its own PostgreSQL as the source of truth and reaches into PVE and PBS over the API, so the native tools remain the systems of record for the hypervisor while ProxCenter becomes the system of record for its own configuration, roles and job state. That is a real operational addition. You are now responsible for backing up the ProxCenter database, and in the Enterprise HA layout, for the Patroni and etcd cluster underneath it. The trade is deliberate: consolidation of the operator experience in exchange for one more stateful service in the critical path.
Release cadence and what an upgrade actually costs
The three most recent releases, v1.4.7 on 2026-08-14, v1.4.8 on 2026-08-24 and v1.4.9 on 2026-08-29, land roughly one to two weeks apart, and the last push to the default branch is dated 2026-09-10. That is an active cadence, and it sets the maintenance expectation: if you track releases, you are running docker compose pull and docker compose up -d in /opt/proxcenter on a similar rhythm, with migrations executing on startup each time. The README states that migrations run automatically, which removes a manual step but also means an upgrade is not fully reversible by image tag alone if a migration has already altered the schema. That is the concrete cost to weigh. For a single-cluster install the cost is a Compose pull every few weeks. For an Enterprise HA deployment it is a rolling operation across three nodes with a Patroni-managed database, and the README does not describe a documented rollback path. Pin the image tags you deploy rather than following latest, and check the release notes for migration-affecting changes before pulling.
Editorial conclusion
Adopt ProxCenter if you run more than one Proxmox VE cluster and want one console for inventory, consoles, backup visibility and RBAC, and if you accept that DRS, alerting and the three-node control plane sit behind an Enterprise token. Do not adopt it if you manage a single standalone PVE host, since the native web UI already covers that case without a second PostgreSQL database in the path. Before installing, confirm three things: whether the repository's NOASSERTION licence metadata resolves to a written Community versus Enterprise agreement on proxcenter.io, that Proxmox VE 8.x or 9.x matches your fleet, and that the machine you install on can hold the Docker stack plus PostgreSQL under /opt/proxcenter.
Community notes