Proxmox VE continues to gain ground as a virtualization platform, but sharing a cluster among developers, departments, students, or small teams presents a challenge: giving access to the Proxmox admin panel usually grants far more visibility and management capabilities than necessary. ProxMate aims to solve this by placing a self-hosted web portal over the cluster, allowing each user to manage only their own virtual machines and containers, with quotas, console access, backups, and user isolation.
ProxMate in 20 seconds
- ProxMate adds a multi-user portal on an existing Proxmox VE cluster.
- Each user receives CPU, RAM, and storage quotas and manages their own VMs and LXC containers.
- Includes web console, snapshots, backups, monitoring, migration, and firewall rules.
- It is self-hosted and its Community Edition uses an AGPLv3 license.
- Can be installed via Docker or following a runbook prepared for Claude Code.
The concept deliberately echoes services like DigitalOcean: the administrator retains control of the infrastructure while providing users with a much simpler interface to consume resources. The project itself defines ProxMate as a DigitalOcean-style web UI built on top of an existing Proxmox setup.
This places it in an interesting space between the traditional hypervisor panel and a full cloud platform. ProxMate does not replace Proxmox VE nor is it another hypervisor. It leverages the API to turn its resources into a service that can be shared among multiple users.
ProxMate is released as an open-source project and can also be viewed in its official GitHub repository.
From Proxmox to a small private cloud
One of its core features is the invitation system.
The administrator can grant access with limitations on CPU, memory, and storage. Once inside, the user can create their own VMs and LXC containers without access to the full Proxmox admin panel.
Machines can be deployed from ISO images, templates, or cloud images. The project currently includes 20 pre-made images—16 for x86-64 and four for ARM64, according to its documentation. It also allows an SSH key to be provided during deployment for remote access readiness.
Many typical infrastructure operations are supported, including:
- Power on, shut down, and restart;
- Resizing and rebuilding;
- Snapshots and scheduled backups;
- Tags and batch operations;
- Scheduled power on/off;
- Migration between nodes;
- Graphical console via noVNC and text console;
- GPU passthrough and PCI device requests;
- Automatic VM distribution across available nodes.
It’s also possible to share a VM with another user using three permission levels: Viewer, Operator, and Manager. None of these can delete, rebuild, migrate, or re-share the machine.
This setup is useful for advanced homelabs, labs, small internal infrastructure providers, development teams, and educational centers that already use Proxmox but don’t want to give each user full admin credentials.
ProxMate also offers EDU and Pro/Business editions. Its lead developer, Brandon Jewell, is currently seeking Proxmox users interested in testing these versions prior to release. According to the project, the Community Edition will remain free and open source.
Installing ProxMate
The project provides an installer for Linux machines. The recommended process is notably different because it deliberately avoids the usual curl | sudo bash.
First, download the installer:
curl -fsSL https://raw.githubusercontent.com/r0073d-l053r/ProxMate/main/install.sh -o install.sh
Next, review it:
less install.sh
And only then execute:
bash install.sh
This is more than a matter of aesthetics.
ProxMate needs to store credentials to communicate with the cluster’s API, so blindly executing a script downloaded from the internet is not recommended. The installer checks dependencies like Docker, Docker Compose v2, Git, curl, and OpenSSL, generates an ENCRYPTION_KEY, creates the configuration, and builds the containers.
The Proxmox token is then entered via the web wizard rather than as a command-line argument, preventing it from accidentally being stored in the shell’s history.
Building the system requires approximately 4 GB of RAM and 5 GB of storage. The installer supports Debian, Ubuntu, Fedora, RHEL, CentOS, Rocky Linux, openSUSE, and Alpine, along with a specific procedure for Arch Linux.
There’s also a quite peculiar alternative for 2026.
The repository includes DEPLOY_WITH_CLAUDE.md, a runbook designed for a scheduler agent to follow deployment instructions. It can be provided to Claude Code, requesting it to execute the procedure for installing ProxMate.
This does not mean the agent should have unrestricted production access. The procedure is intentionally designed to pause and request confirmation before certain operations.
Security considerations in a multi-user portal
The effectiveness of ProxMate largely depends on that additional layer not becoming a pathway to access the rest of the cluster.
Its architecture keeps Proxmox credentials on the server. The user’s browser does not receive the token directly; all API operations pass through ProxMate’s authenticated backend.
The project also integrates TOTP for two-step authentication, WebAuthn passkeys, and the possibility to use an external provider via OpenID Connect (OIDC). Sessions use httpOnly and SameSite=Lax cookies, while actions that change data include protection against Cross-Site Request Forgery (CSRF).
However, there is a key aspect every administrator should carefully review before deploying.
User isolation also relies on the Proxmox cluster’s firewall being properly enabled.
ProxMate configures network interfaces for new VMs with firewalls and creates rules to prevent a user’s VM from accessing private RFC1918 networks used by the infrastructure and other guests. It explicitly warns that VM-level rules do not provide the intended isolation if the cluster’s firewall remains disabled.
For setups requiring deeper separation, its documentation recommends considering independent bridges or VLANs per tenant, or utilizing Proxmox’s Software Defined Networking (SDN) capabilities.
The token used for connecting to Proxmox also warrants attention.
While during testing it may be tempting to use root@pam, the documentation advocates creating a specific user and role with necessary permissions. Additional operations, like modifying certain data center firewall settings, may require higher privileges and should be evaluated separately.
ProxMate encrypts secrets like the Proxmox token and SMTP/SSO credentials using AES-256-GCM with the ENCRYPTION_KEY. This key must be stable and kept outside the server itself; losing both the host and the key makes the secrets in backups unusable.
More than just a pretty panel for Proxmox
The project is also starting to incorporate functions beyond basic provisioning.
ProxMate IDE, still in beta, enables running a development environment within a VM based on VS Code/code-server along with OpenCode as a programming agent. The admin controls available models, while the environment stays within the user’s assigned machine.
It includes features like real-time monitoring, audit logging, metrics for Prometheus, node drainage for maintenance, and a memory balancer conceptually similar to a simple DRS.
Its MateStates system adds scheduled backups, VM policies, retention, and restore capabilities. ProxMate also performs nightly backups of its own database.
The repository also declares 718 backend tests for critical areas such as quotas, permissions, firewall rules, VM placement, backups, migrations, cloud-init, and protections against Server-Side Request Forgery (SSRF). Continuous integration checks frontend functionality, Playwright tests, Docker image builds, CodeQL, Trivy, and SBOM generation.
All of this makes ProxMate more than just an alternative dashboard.
The Proxmox ecosystem itself is expanding its management tools. For example, Proxmox maintains Datacenter Manager to oversee infrastructure from a higher layer, with its own backend and API. ProxMate addresses a different challenge: delivering part of that infrastructure directly to end users without handing over hypervisor keys.
That’s probably its main appeal.
A company could reserve 8 vCPUs, 16 GB of RAM, and 200 GB for a developer; a university lab could allocate capacity among students; or a homelab administrator could allow family and friends to create servers without explaining how the entire Proxmox panel works.
It doesn’t automatically turn Proxmox VE into a competitor of AWS, Azure, or any OpenStack platform. Nor does it eliminate the need for network, storage, security, high availability, or capacity management by the administrator.
What it offers is a self-service layer that feels much closer to a small private cloud experience, with Proxmox underneath and full infrastructure under the owner’s control.
And this might be especially valuable now, as more organizations are considering Proxmox for workloads previously run on other virtualization platforms.
Frequently Asked Questions
What is ProxMate?
ProxMate is a self-hosted web portal installed on an existing Proxmox VE cluster. It enables delivering VMs and containers to different users with separate quotas and permissions, without giving them full administrative access to Proxmox.
Does ProxMate replace Proxmox VE?
No. Proxmox continues to run virtual machines, containers, networks, and storage. ProxMate uses its API and adds an extra layer of management and self-service.
Is ProxMate free and open source?
The Community Edition is published under the GNU Affero General Public License v3.0 (AGPLv3). The project follows an open core model, with EDU and commercial editions offering additional features.
Is it safe to expose ProxMate to the internet?
The project incorporates multiple security measures, but a public deployment requires additional configuration: HTTPS, minimal permissions for the Proxmox token, cluster firewall, 2FA or SSO, and avoiding exposing the Proxmox admin interface directly, as recommended in its documentation.
