Proxmox VE continue de s’imposer comme une plateforme de virtualisation, mais partager un cluster entre développeurs, départements, étudiants ou petites équipes soulève une problématique : accorder un accès au panneau administratif de Proxmox offre généralement une visibilité et des capacités de gestion excessive par rapport aux besoins. ProxMate tente de résoudre ce problème en plaçant un portail web sous hébergement personnel sur le cluster. Depuis cette interface, chaque utilisateur peut gérer uniquement ses propres machines virtuelles et conteneurs, avec quotas, consoles, sauvegardes et isolation entre utilisateurs.

Les points clés de ProxMate en 20 secondes

• ProxMate ajoute un portail multi-utilisateurs à un cluster Proxmox VE existant.
• Chaque utilisateur dispose de quotas CPU, RAM et stockage, et gère ses propres VM et conteneurs LXC.
• Il intègre une console web, snapshots, sauvegardes, supervision, migration et règles de pare-feu.
• Il est auto-hébergé et sa Community Edition utilise une licence AGPLv3.
• Il peut s’installer via Docker ou en suivant un runbook spécialement préparé pour Claude Code.

Ce concept s’inspire délibérément de services comme DigitalOcean : l’administrateur conserve le contrôle de l’infrastructure tout en offrant aux utilisateurs une interface simplifiée pour consommer des ressources. Le projet définit ProxMate comme une WebUI de style DigitalOcean construite sur un Proxmox déjà en place.

Ce positionnement le place entre le panneau traditionnel de l’hyperviseur et une plateforme cloud complète. ProxMate ne remplace pas Proxmox VE ni ne constitue un autre hyperviseur. Il exploite son API pour transformer ses ressources en un service à partager entre plusieurs utilisateurs.

ProxMate est publié en tant que projet open source et son code est accessible dans son dépôt GitHub officiel.

De Proxmox à une petite nuage privée

L’une des fonctions principales repose sur un système d’invitations.

L’administrateur peut donner accès avec des limites pour la CPU, la mémoire et le stockage. Une fois connectés, les utilisateurs peuvent créer leurs propres VM et conteneurs LXC sans disposer d’un accès complet au panneau Proxmox.

Les machines peuvent être déployées à partir d’ISO, de templates ou d’images cloud. Le projet fournit actuellement 20 images prêtes à l’emploi, dont 16 pour x86-64 et 4 pour ARM64, selon sa documentation. Il est également possible d’intégrer une clé SSH lors du déploiement pour accéder à la machine à distance dès sa création.

Parmi les opérations attendues dans une plateforme d’infrastructure :

• démarrage, arrêt et redémarrage ;
• redimensionnement et reconstruction ;
• snapshots et sauvegardes planifiées ;
• étiquetage et opérations groupées ;
• programmation d’allumage et d’arrêt ;
• migration entre nœuds ;
• console graphique via noVNC et console texte ;
• passage à la GPU et dispositifs PCI en mode passthrough ;
• répartition automatique des VM entre les nœuds disponibles.

Il est aussi possible de partager une VM avec un autre utilisateur en utilisant trois niveaux de permissions : Visualiseur, Opérateur et Administrateur. Aucun d’eux ne peut supprimer, reconstruire, migrer ou repartager la machine.

Ce modèle est adapté pour des homelabs avancés, des laboratoires, de petits fournisseurs internes, des équipes de développement ou des centres éducatifs qui utilisent déjà Proxmox, mais sans vouloir transmettre des accès administratifs complets à chaque utilisateur

ProxMate propose aussi des versions EDU et Pro/Business. Son responsable, Brandon Jewell, recherche actuellement des utilisateurs de Proxmox intéressés par tester ces versions avant leur lancement officiel. La Community Edition restera gratuite et open source, assure le projet.

Installation de ProxMate

Le projet fournit un script d’installation pour Linux. La démarche recommandée évite volontairement l’approche usuelle curl | sudo bash.

On commence par télécharger le script :

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

On vérifie son contenu :

less install.sh

Puis on l’exécute :

bash install.sh

Ce n’est pas qu’une question d’esthétique. ProxMate doit stocker des identifiants pour communiquer avec l’API du cluster. Exécuter cécie un script téléchargé sans vérification serait risqué. Le script vérifie la présence de dépendances comme Docker, Docker Compose v2, Git, curl et OpenSSL, génère une ENCRYPTION_KEY, configure le système et construit les conteneurs.

Le token Proxmox s’ajoute ensuite via l’interface web, et non en argument en ligne de commande, pour éviter qu’il ne soit stocké accidentellement dans l’historique.

Pour la construction, il est conseillé d’allouer environ 4 Go de RAM et 5 Go de stockage. La compatibilité couvre Debian, Ubuntu, Fedora, RHEL, CentOS, Rocky Linux, openSUSE et Alpine, avec une procédure spécifique pour Arch Linux.

Une alternative très particulière est aussi évoquée pour 2026 dans le dépôt.

Ce dernier inclut un fichier DEPLOY_WITH_CLAUDE.md, un runbook conçu pour qu’un agent de déploiement suive les instructions pour déployer ProxMate. Il peut être confié à Claude Code pour qu’il exécute la procédure automatiquement.

Cela ne signifie pas une liberté totale pour l’agent sur le système. Le guide est conçu pour qu’il s’arrête et demande une confirmation à certains moments critiques.

La sécurité, notamment dans un portail multi-utilisateurs

L’efficacité de ProxMate repose en grande partie sur le fait que cette couche additionnelle ne devienne pas une porte d’entrée pour accéder au reste du cluster.

Son architecture maintient les identifiants Proxmox sur le serveur. Le navigateur de l’utilisateur ne reçoit pas directement le token, et toutes les opérations via l’API transitent par le backend authentifié de ProxMate.

Il intègre également TOTP pour une authentification à deux facteurs, des passkeys avec WebAuthn, et la possibilité d’utiliser un fournisseur externe via OpenID Connect (OIDC). Les sessions utilisent des cookies httpOnly et SameSite=Lax, et les opérations modifiant des données sont protégées contre les attaques CSRF.

Cependant, un point crucial doit être vérifié attentivement par tout administrateur avant déploiement :

L’isolation des utilisateurs dépend aussi d’un pare-feu Proxmox configuré et activé correctement.

ProxMate configure les interfaces des VM avec un pare-feu et crée des règles empêchant une VM d’un utilisateur d’accéder aux réseaux privés RFC1918 utilisés par l’infrastructure ou autres VM. Le projet souligne que ces règles par VM ne garantissent pas un isolation effective si le pare-feu du cluster reste désactivé.

Pour des environnements nécessitant une séparation plus poussée, la documentation recommande l’utilisation de bridges ou VLANs dédiés pour chaque locataire, ou encore de recourir aux capacités SDN de Proxmox.

Il faut aussi faire attention au token utilisé pour se connecter à Proxmox.

Il est conseillé de créer un utilisateur spécifique avec un rôle restreint plutôt que d’utiliser root@pam. Certaines opérations sensibles, comme modifier les réglages du pare-feu du datacenter, peuvent demander des privilèges élevés et doivent faire l’objet d’évaluation séparée.

ProxMate chiffre les secrets comme le token Proxmox ou les identifiants SMTP/SSO avec AES-256-GCM via la clé ENCRYPTION_KEY. Celle-ci doit rester stable et hors du serveur, car la perte de la clé et de la machine pourrait rendre ces secrets inutilisables, rendant la restauration impossible.

Plus qu’un simple panneau attrayant pour Proxmox

Le projet commence aussi à intégrer des fonctionnalités dépassant le simple provisioning :

ProxMate IDE, encore en bêta, permet d’exécuter dans une VM un environnement de développement basé sur VS Code / code-server, avec OpenCode comme agent de programmation. L’administrateur contrôle les modèles disponibles, tandis que l’environnement reste dans la machine assignée à l’utilisateur.

Pour la surveillance, on trouve la supervision en temps réel, l’audit, des métriques pour Prometheus, une gestion de maintenance via le drainage des nœuds, ainsi qu’un équilibrage mémoire semblable à un DRS simplifié.

Le système MateStates ajoute des sauvegardes planifiées, des politiques par VM, la rétention et la restauration. ProxMate effectue aussi des sauvegardes nocturnes de sa propre base de données.

Le dépôt inclut également 718 tests backend pour des zones sensibles comme les quotas, permissions, règles de pare-feu, placement de VM, sauvegardes, migrations, cloud-init et protections contre le SSRF. La CI comprend aussi des vérifications du frontend, Playwright, la construction d’images Docker, CodeQL, Trivy, et la génération du Software Bill of Materials (SBOM).

Tout cela fait de ProxMate une solution bien plus qu’un simple tableau de bord alternatif.

L’écosystème Proxmox élargit aussi ses outils d’administration, avec par exemple le Datacenter Manager pour gérer l’infrastructure via une couche supérieure, avec son propre backend et API. ProxMate offre une approche différente : fournir une partie de cette infrastructure directement aux utilisateurs finaux, sans leur donner les clés de l’hyperviseur.

C’est probablement là son principal attrait.

Une entreprise pourrait réserver 8 vCPU, 16 Go de RAM et 200 Go à un développeur ; un laboratoire universitaire partager des ressources entre étudiants ; ou un administrateur de homelab permettre à ses proches de créer des serveurs sans révéler le fonctionnement complet de Proxmox.

Il ne transforme pas automatiquement Proxmox VE en un concurrent direct d’AWS, Azure ou OpenStack, ni ne remplace la gestion en réseau, stockage, sécurité, haute disponibilité ou capacité d’un administrateur.

Ce qu’il propose, c’est une couche d’auto-service très proche de l’expérience d’un petit cloud privé, avec Proxmox en dessous et une infrastructure sous contrôle du propriétaire.

Et cela peut s’avérer particulièrement précieux alors que de plus en plus d’organisations envisagent Proxmox pour des charges traditionnellement hébergées sur d’autres plateformes de virtualisation.

Questions fréquentes

Qu’est-ce que ProxMate ?

ProxMate est un portail web sous hébergement personnel qui s’installe sur un cluster Proxmox VE existant. Il permet de fournir des VM et des conteneurs à différents utilisateurs avec des quotas et permissions séparés, sans leur donner un accès administrateur complet à Proxmox.

ProxMate remplace-t-il Proxmox VE ?

Non. Proxmox continue d’exécuter les VM, conteneurs, réseaux et stockage. ProxMate utilise son API pour offrir une couche supplémentaire de gestion et d’auto-service.

ProxMate est-il gratuit et open source ?

La Community Edition est publiée sous la licence GNU Affero GPL v3 (AGPLv3). Le projet repose sur un modèle open core, avec des éditions EDU et commerciales proposant des fonctionnalités additionnelles.

Est-il sûr d’exposer ProxMate à Internet ?

Le projet intègre plusieurs mesures de sécurité. Cependant, une installation accessible publiquement nécessite une configuration supplémentaire : HTTPS, permissions minimales pour le token Proxmox, pare-feu du cluster, 2FA ou SSO, et éviter d’exposer directement l’interface d’administration de Proxmox. La documentation recommande vivement de suivre ces bonnes pratiques pour limiter tout risque éventuel.