Proxmox VE provides practically everything needed to manage virtual machines and containers, but its interface is primarily designed for administrators. ProxMate proposes adding a self-service layer on top of the cluster, allowing developers, students, or internal users to create and manage their own resources without being granted access to the Proxmox administration panel. The project is self-hosted, its Community Edition is open source, and it can be deployed with Docker on Linux.

The key points about ProxMate in 30 seconds

ProxMate uses the Proxmox VE API to provide a multi-user portal separate from the administrative interface.
Administrators can assign vCPU, RAM, and storage quotas while users deploy VMs and LXC containers through self-service.
It includes a web console, snapshots, backups, per-VM firewall rules, migrations, monitoring, and 2FA authentication.
It runs on your own infrastructure using Docker and includes an installer for major Linux distributions.
The Community Edition uses the AGPLv3 license, while EDU and commercial editions are also being developed.

For a system administrator, the interesting part is that ProxMate does not attempt to replace Proxmox VE. The hypervisor continues to manage nodes, KVM, LXC, networking, and storage. ProxMate uses its API to add a layer of users, permissions, and provisioning that feels closer to a small private cloud platform.

The practical result is straightforward: the systems team continues administering Proxmox while users receive a much more restricted portal from which they can consume the resources previously allocated to them.

Proxmox as the backend, ProxMate as the self-service portal

ProxMate starts with an already operational Proxmox VE cluster. On top of it, the platform provides a web interface where administrators can create invitations accompanied by CPU, memory, and storage limits.

Once registered, each user can deploy virtual machines and LXC containers without needing to understand the complete cluster structure.

The project supports several provisioning methods. Users can install from an ISO, clone a template, or use its catalog of cloud images. Current documentation lists 20 prepared images, 16 for x86-64 and four for ARM64.

It is also possible to provide a public SSH key during provisioning. This is particularly useful in Linux environments where the goal is to quickly obtain a VM accessible over SSH without first going through an interactive installation.

After deployment, users have access to common operations such as resizing, renaming, rebuilding, starting or stopping machines, creating snapshots, and configuring power schedules.

ProxMate also includes a graphical console through noVNC and a browser-accessible text console with features such as copy and paste and scrollback. This means SSH or other ports do not necessarily have to be exposed simply to troubleshoot a system from its console.

There is also a system for sharing a VM with another user. Three permission profiles are provided: Viewer, Operator, and Manager. None of them, however, allows the shared resource to be deleted, rebuilt, migrated, or shared again.

Administrators have a global cluster view showing CPU, memory and storage utilization, nodes, and virtual machines grouped by owner.

How to install ProxMate on Linux

The project provides an installer that prepares the required dependencies and builds the Docker environment.

Installation starts by downloading the script:

curl-fsSLO https://raw.githubusercontent.com/r0073d-l053r/ProxMate/main/install.sh

Before running it, the developers explicitly recommend reviewing its contents:

less install.sh

Then it can be executed:

bash install.sh

This is an especially sensible recommendation for a tool that will eventually store credentials capable of operating a virtualization cluster.

ProxMate deliberately avoids recommending something like:

curl https://server/install.sh | sudobash

The installer checks for Docker, Docker Compose v2, Git, curl, and OpenSSL, and can offer to install any missing dependencies. It also generates ENCRYPTION_KEY, prepares the .env file, and builds the containers.

The Proxmox token is not entered as a command-line parameter. Instead, it is provided later through the web setup wizard, reducing the risk of the credential ending up in the shell history.

Approximately 4 GB of RAM and 5 GB of available storage are recommended for the build process.

The installer supports Debian, Ubuntu, Fedora, RHEL, CentOS, Rocky Linux, openSUSE, and Alpine. For Arch Linux, it provides the necessary instructions rather than automatically upgrading the system.

Administrators who prefer a manual deployment can use Docker Compose directly:

cp .env.docker.example .envopenssl rand -hex32nano .envdocker compose up -d--build

There is one detail worth checking before taking ProxMate into production.

The example .env initially uses proxmate.example.com in its production configuration. Administrators need to replace that domain or use the corresponding local configuration. NEXT_PUBLIC_API_URL is embedded into the frontend during the build, so changing it afterwards requires rebuilding the image.

ENCRYPTION_KEY is one key you do not want to lose

Another important component for any sysadmin is ENCRYPTION_KEY.

ProxMate uses this key to protect secrets stored by the application, including the Proxmox token, JWT secrets, SMTP credentials, and TOTP secrets.

Therefore, backing up the database alone is not enough.

Administrators should also keep a secure copy of ENCRYPTION_KEY outside the ProxMate server. If the host disappears and the key is lost with it, having a later copy of the database will not be enough to correctly recover those encrypted secrets.

A password manager or corporate secrets management system can be used to store it securely.

The key must also remain unchanged across updates and restarts.

Updates are performed against published releases rather than directly tracking the main branch:

./deploy/update.sh

A specific version can also be selected:

./deploy/update.sh v0.8.6

Database migrations run automatically when the backend container starts. The documentation advises against executing them manually.

The Proxmox firewall is part of tenant isolation

In a multi-user tool, one of the most sensitive areas is tenant separation.

ProxMate can generate per-VM firewall rules designed to prevent users from reaching the host, other guests, or specific internal networks. However, there is an essential requirement: the Proxmox cluster firewall must be enabled for those rules to provide the intended isolation.

The project itself warns about this requirement during configuration.

This deserves particular attention because installing the portal and creating users does not automatically turn an existing cluster into a secure multi-tenant infrastructure. Network topology, bridges, VLANs, firewall configuration, and Proxmox permissions remain the administrator’s responsibility.

In environments requiring stronger isolation, separate VLANs, dedicated bridges, or Proxmox Software Defined Networking (SDN) features may still be necessary.

Something similar applies to the API token.

One of the configuration issues documented by ProxMate concerns Privilege Separation. Proxmox creates API tokens with this option enabled, which can leave a token without the expected permissions. The result can be confusing: the connection test may succeed while storage queries return empty results or VM creation ends with a 403 error.

The solution should not simply be to grant unlimited permissions. In production, it is preferable to create an appropriate user and role for the integration and grant only the privileges that are actually required.

2FA, passkeys, OIDC and auditing

ProxMate includes several features that are useful for shared installations.

The system supports two-factor authentication using TOTP, passkeys through WebAuthn, and external identity providers via OpenID Connect (OIDC). Administrators can also require 2FA directly from the invitation sent to a user.

SMTP can be configured for password recovery.

Access can also be limited to a specific period. An invitation can grant access for a defined amount of time and, once it expires, ProxMate suspends access and stops the corresponding VMs, but does not automatically delete the resources.

Administrators also have access to audit logs and a /metrics endpoint for Prometheus integration.

The monitoring system provides real-time information about VM CPU, memory, and network usage, while operational features include live migration, node draining during maintenance, and a memory balancer inspired by DRS-style resource management.

Backups, snapshots and recovery

ProxMate includes its own system called MateStates.

It supports scheduled backups, different policies per VM, rotating retention, restores, and quick snapshots. It also performs nightly backups of its own database to a directory on the host.

Once again, it is important to distinguish convenience features from a proper backup strategy.

The existence of these functions does not remove the need to maintain external backups, test restoration procedures, and keep both the required data and ENCRYPTION_KEY outside the host.

For a homelab, a simple configuration may be enough. Production environments should continue to apply the same backup practices used for any other virtualization infrastructure.

An IDE and AI coding agents inside the VMs

One of the more unusual features is ProxMate IDE, currently labeled as beta.

It allows code-server, the browser-based VS Code environment, to run inside the user’s own VM. The project also integrates OpenCode as a coding agent and allows administrators to determine which models are available.

The approach keeps the development environment inside the VM assigned to each tenant rather than turning the ProxMate server itself into a shared execution environment.

There is also an agent-assisted installation procedure.

The repository contains DEPLOY_WITH_CLAUDE.md, designed to be provided to Claude Code with instructions to follow the deployment process. The runbook covers HTTPS, API token creation, tenant isolation, and initial configuration, requesting confirmation before making certain changes to production systems.

For an experienced administrator, this may be more interesting as an example of agent-assisted infrastructure management than as a replacement for manually reviewing what changes are going to be applied to a system.

ProxMate is still a young project and should be treated accordingly before being placed in front of critical infrastructure. Even so, it addresses a familiar problem for Proxmox administrators: allowing other people to use the cluster without turning them into cluster administrators.

For Linux labs, homelabs, universities, development teams, or small internal infrastructures, this intermediate layer could eliminate a considerable amount of manual provisioning work. The administrator keeps Proxmox underneath; users get something much closer to a small private cloud portal on top.

Frequently asked questions

Does ProxMate replace the Proxmox VE interface?

No. ProxMate uses Proxmox VE as its virtualization platform and communicates with it through the API. Its purpose is to provide a multi-user, self-service interface without granting users full administrative access to the cluster.

Which Linux distributions can run ProxMate?

The installer supports Debian, Ubuntu, Fedora, RHEL, CentOS, Rocky Linux, openSUSE, and Alpine, with specific instructions also provided for Arch Linux. Deployment is based on Docker and Docker Compose.

Does the Proxmox firewall need to be enabled?

Yes, if the administrator wants the per-VM isolation model provided by ProxMate to work as intended. Installing the application alone does not replace proper firewall, network, VLAN, or SDN configuration.

Is ProxMate open source?

The Community Edition is available under the GNU Affero General Public License v3.0 (AGPLv3). The project follows an open-core model and is also developing EDU and commercial editions.