Vous avez un VPS hébergeant cinq ou six services Docker : Nextcloud, Uptime Kuma, un blog Ghost, peut-être un Vaultwarden. Une seule IP publique. Et vous voulez que chacun ait son propre sous-domaine avec HTTPS, sans éditer à la main des fichiers de configuration Nginx à chaque ajout de conteneur. C'est exactement le problème que Nginx Proxy Manager existe pour résoudre.
Voici à la fois un test et une installation VPS complète de Nginx Proxy Manager, en un seul guide. Nginx Proxy Manager (NPM) est une application Docker qui enveloppe Nginx dans une interface web : vous faites pointer des sous-domaines vers des conteneurs backend et demandez des certificats Let's Encrypt via un tableau de bord au lieu d'écrire des directives à la main. Ce guide s'adresse aux adeptes de l'auto-hébergement et aux administrateurs système qui utilisent déjà Docker et ont désormais besoin d'un reverse proxy qui n'oblige pas à toucher à nginx.conf.
À la fin, vous saurez si NPM convient à votre cas, vous l'aurez en fonctionnement avec HTTPS sur votre VPS, et vous connaîtrez les critères pour basculer vers Caddy ou Traefik lorsque NPM cesse d'être le bon outil.
La version courte
- Ce qu'est NPM : une application Docker qui pose une interface web par-dessus Nginx pour gérer les proxy hosts et le HTTPS automatique via Let's Encrypt. Elle convient aux personnes qui veulent une interface graphique et exécutent une petite stack de services assez statique.
- Les compromis : la configuration réside dans une base de données SQLite, elle n'est donc ni versionnable ni comparable comme un fichier de configuration. Au 12 juillet 2026, la dernière version taguée est affectée par CVE-2026-40519, les nouveaux déploiements devraient donc attendre une version taguée contenant le correctif. Son panneau d'administration sur le port 81 est le principal élément à verrouiller.
- Dimensionnement : NPM lui-même consomme au repos environ 50 MB de RAM. Un VPS de 1 GB constitue la base pratique ; 2 GB sont confortables une fois que vous ajoutez les services placés derrière.
- Quand changer : restez sur NPM pour une petite stack majoritairement statique où une interface graphique compte. Utilisez Caddy lorsque vous voulez une configuration sous forme de code et une empreinte plus légère. Utilisez Traefik lorsque des changements fréquents de conteneurs rendent la découverte automatique Docker plus utile que l'enregistrement manuel des hôtes.
Ce que ce guide ne couvre pas
Ceci est un guide de déploiement sur VPS, pas un manuel de référence. Pour rester ciblé, les éléments suivants sont hors périmètre :
- La personnalisation poussée des directives Nginx (blocs location personnalisés au-delà de ce que l'interface de NPM expose).
- L'architecture de répartition de charge à grande échelle.
- La comparaison des ingress Kubernetes.
- NPM sur Windows.
- La méthode Cloudflare Tunnel pour les configurations sans IP statique.
Ce que fait Nginx Proxy Manager (et où il vous piège)
Nginx Proxy Manager est une application Docker qui exécute Nginx en sous-jacent et y ajoute un tableau de bord web. Vous créez des proxy hosts (sous-domaine vers conteneur backend et port) et demandez des certificats Let's Encrypt via des formulaires plutôt que via des fichiers de configuration. Elle convient à une petite stack assez statique d'applications auto-hébergées sur un seul VPS.
Au-delà des fonctions de base, le tableau de bord gère aussi les listes d'accès et le transfert brut de flux TCP/UDP. Pour une stack d'applications sur un seul VPS, c'est une vraie commodité : vous ajoutez un conteneur, ouvrez le tableau de bord, faites pointer un sous-domaine vers lui, cliquez pour émettre un certificat. Terminé.
Le principal compromis est que la configuration de référence de NPM réside par défaut dans une base de données SQLite. NPM génère bien des fichiers Nginx lisibles sous /data/nginx/proxy_host/, mais ces fichiers sont des artefacts générés plutôt que la configuration déclarative que vous éditez et versionnez. Vous pouvez les inspecter, mais ils ne remplacent pas proprement un Caddyfile ou des labels Traefik, et la manière fiable de reproduire le déploiement consiste à restaurer les volumes de données et de certificats de NPM. Pour une petite stack statique, cela peut convenir. Pour un workflow d'infrastructure piloté par Git, c'est une vraie limitation.
Au 12 juillet 2026, la dernière version taguée est la v2.15.1, publiée le 3 juin 2026. Le projet reste actif et sous licence MIT, mais sa situation de sécurité actuelle appelle une réserve importante : le NVD répertorie les versions 2.9.14 à 2.15.1 comme affectées par CVE-2026-40519, une vulnérabilité d'injection de commandes authentifiée corrigée dans le commit a5db5ed mais pas encore incluse dans une version taguée plus récente. Avant de déployer, consultez la page des versions et utilisez la première version taguée contenant ce correctif. NPM est maintenu, mais la v2.15.1 ne devrait pas être décrite actuellement comme entièrement corrigée.
Côté empreinte, NPM consomme au repos environ 50 MB de RAM d'après la comparaison de reverse proxy de byte-guard. C'est suffisamment léger pour que NPM ne soit presque jamais ce qui met votre VPS à rude épreuve. Ce sont les services placés derrière lui qui le font.
Mon avis : NPM est un choix raisonnable en 2026 si vous voulez une interface graphique et exécutez une petite stack Docker. Si vous vivez dans le contrôle de version et voulez votre configuration de proxy dans Git, penchez plutôt pour Caddy. La configuration adossée à SQLite est le facteur décisif, et non un quelconque défaut du proxy lui-même.
NPM échange la portabilité de la configuration contre une interface graphique. Ce compromis convient à une petite stack statique et devient gênant pour un workflow piloté par Git.
NPM vs Caddy vs Traefik : quel reverse proxy convient à votre VPS
Les trois outils se distinguent selon quatre axes qui déterminent le choix : comment vous les configurez, comment ils gèrent HTTPS, comment ils évoluent avec le nombre de services, et combien de RAM ils consomment au repos. Voici la comparaison.
| Attribut | Gestionnaire de Proxy Nginx | Caddy | Traefik |
|---|---|---|---|
| Modèle de configuration | Interface web, stockée dans SQLite | Caddyfile (texte, versionnable) | Labels Docker / YAML |
| HTTPS automatique | Oui, demande par hôte dans l'interface | Oui, par défaut, sans configuration | Oui, nécessite la configuration d'un résolveur ACME |
| Découverte automatique Docker | No | No | Oui, via les labels de conteneur |
| RAM au repos | ~50 MB | ~30 MB | ~80 MB |
| Cas d'usage idéal | Utilisateurs d'interface graphique, petites stacks statiques | Configuration sous forme de code, empreinte la plus légère | Stacks Docker dynamiques avec des changements fréquents de conteneurs |
Les chiffres de RAM au repos sont des observations approximatives issues d'une comparaison de 2026, et non des exigences fixes. L'utilisation réelle varie selon la version de l'image, les fonctionnalités activées, le trafic et la journalisation.
Les critères de bascule découlent directement de ce tableau. Si vous voulez un tableau de bord et exécutez une poignée de services qui changent peu, NPM est le bon outil. Si vous préférez la configuration sous forme de code, voulez l'empreinte la plus légère, ou appréciez le provisionnement et renouvellement HTTPS automatiques de Caddy sans aucune configuration ACME, utilisez Caddy. J'opte moi-même pour Caddy sur les déploiements à site unique car la gestion SSL est automatique et le Caddyfile est court. Si vous ajoutez, supprimez ou redéployez fréquemment des conteneurs, la découverte automatique basée sur les labels de Traefik vous évite d'enregistrer à la main chaque nouvel hôte.
Il y a aussi Nginx brut avec Certbot, que certains administrateurs préfèrent pour un contrôle précis ou des déploiements non-Docker. Certbot peut automatiser le renouvellement des certificats, mais vous gérez tout de même vous-même le routage des hôtes virtuels et la configuration Nginx. Si votre principale raison d'envisager NPM est d'éviter la configuration manuelle du proxy, Nginx brut a peu de chances d'être le meilleur choix.
Une remarque sur le choix : la comparaison de byte-guard désigne Caddy comme l'option la plus légère de cette comparaison, et pour une nouvelle installation à hôte unique en 2026, c'est un choix raisonnable. Caddy l'emporte en étant plus léger que NPM, mais si vous voulez précisément une interface graphique, ce n'est pas votre meilleure option.
Pour une comparaison plus approfondie des moteurs sous-jacents, consultez la comparaison Caddy vs Nginx sur un VPS.
Prérequis : ce dont vous aurez besoin
Avant de déployer, préparez ces éléments. La liste est courte, mais si vous en omettez un, l'étape du certificat échouera plus tard.
- Un VPS avec Docker et Docker Compose installés (Ubuntu 22.04 LTS ou Debian 12 conviennent).
- Un nom de domaine, avec un enregistrement DNS A (et AAAA si vous utilisez IPv6) pointant vers l'IP publique de votre VPS.
- Un accès SSH au VPS.
- Les ports 80 et 443 ouverts sur Internet dans votre pare-feu.
- Le port 81 accessible par vous seul, non ouvert au public (traité dans la section sécurité).
Installer Nginx Proxy Manager sur votre VPS avec Docker Compose
Cette section déploie NPM à l'aide de Docker Compose. Une fois que vos enregistrements DNS résolvent vers le VPS, la mise en place du conteneur elle-même est rapide, même si la propagation DNS et l'émission du certificat peuvent prendre plus de temps.
L'installation utilise un seul fichier Docker Compose et une commande unique pour créer un réseau Docker partagé. Créez un répertoire, créez le réseau, ajoutez le docker-compose.yml fichier ci-dessous, et démarrez le conteneur.
D'abord, créez le réseau Docker partagé :
docker network create proxyCréez ensuite le docker-compose.yml :
# docker-compose.yml
services:
npm:
image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
restart: unless-stopped
ports:
- '80:80' # public HTTP
- '443:443' # public HTTPS
- '127.0.0.1:81:81' # admin UI, reachable only from the VPS itself
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
networks:
- proxy
networks:
proxy:
external: trueRattachez chaque conteneur backend que NPM doit atteindre par nom de service au même réseau externe proxy . Cela permet à NPM de résoudre le conteneur par son nom de service sans publier le port de l'application backend sur le VPS.
Sauvegardez les deux ./data et ./letsencrypt avant toute mise à niveau. Le répertoire de données contient la base de données et la configuration générée de NPM, tandis que le répertoire Let's Encrypt contient son matériel de certificat.
Quelques points sur ce fichier. L'image utilise par défaut une base de données SQLite stockée dans le volume ./data . C'est le backend par défaut et il convient à la plupart des déploiements sur un seul VPS. Si vous avez besoin d'une base de données externe, NPM prend en charge MariaDB/MySQL et PostgreSQL, ce qui implique d'ajouter un service de base de données et les variables d'environnement correspondantes. Pour un seul VPS, SQLite reste l'option par défaut la plus simple, sauf raison claire de sortir la base de données du volume de données. La restart: unless-stopped politique fait que NPM redémarre si le VPS redémarre, ce qui est souhaitable pour un service placé devant tout le reste.
Démarrez-le et confirmez qu'il fonctionne :
docker compose up -d
docker compose psSortie attendue : le npm conteneur avec l'état Up, les ports 80 et 443 mappés publiquement, et le port 81 lié uniquement à 127.0.0.1. Le premier démarrage prend quelques minutes pendant que NPM génère une clé JWT, initialise la base de données et crée l'utilisateur admin par défaut. Les docs d'installation officielles décrivent cette séquence de premier démarrage.
Créez un tunnel SSH depuis votre ordinateur local avant d'ouvrir l'interface d'administration :
ssh -L 8181:127.0.0.1:81 user@your-vpsOuvrez ensuite http://127.0.0.1:8181 dans votre navigateur. Sur une installation neuve, connectez-vous avec [email protected] et changeme, puis remplacez immédiatement l'e-mail et le mot de passe par défaut. Ne rendez pas le tableau de bord accessible publiquement tant que les identifiants par défaut sont actifs.
Une fois les identifiants admin modifiés, ajoutez votre premier proxy host :
- Dans le tableau de bord, allez à Hosts, puis Proxy Hosts, puis Add Proxy Host.
- Définissez le Domain Name vers votre sous-domaine (par exemple
cloud.example.com). - Définir Forward Hostname / IP vers le nom ou l'IP du conteneur backend, et Forward Port vers le port sur lequel il écoute.
- Enregistrez. Le proxy host apparaît dans la liste, et le trafic vers ce sous-domaine atteint désormais votre conteneur.
Si vous exécutez une interface de gestion Docker en parallèle, le même schéma s'applique : faites pointer un sous-domaine vers l'outil de gestion de conteneurs de la même façon, et faites de même pour un pile de supervision Prometheus et Grafana que vous voulez placer derrière le proxy.
Configurer le HTTPS automatique pour un sous-domaine
Cette section vous procure un certificat Let's Encrypt valide et à renouvellement automatique pour votre sous-domaine. Le prérequis est celui qui piège beaucoup de monde : l'enregistrement DNS A de ce sous-domaine doit déjà pointer vers votre VPS, et le port 80 doit être accessible depuis Internet, car Let's Encrypt vérifie le domaine en s'y reconnectant.
Une fois le proxy host créé, demandez le certificat :
- Modifiez le proxy host, ouvrez l'onglet SSL .
- Sous Certificat SSL, choisissez Request a new SSL Certificate.
- Activer le Force SSL et HTTP/2 Support. N'activez HSTS qu'après avoir confirmé que HTTPS fonctionne correctement, car les navigateurs peuvent mettre la politique en cache et rendre plus difficile la récupération après une erreur de certificat ou de configuration du proxy.
- Acceptez les conditions de Let's Encrypt et enregistrez.
Par défaut, NPM utilise le challenge HTTP-01 pour les noms non génériques, validant chaque nom d'hôte demandé via le port 80. Un certificat peut contenir plusieurs noms non génériques, mais HTTP-01 ne peut pas émettre de certificats génériques. Les noms génériques tels que *.example.com nécessitent le challenge DNS-01 avec un fournisseur DNS pris en charge. Pour une configuration classique à un sous-domaine par service, HTTP-01 suffit, et les renouvellements sont automatiques.
Si la demande de certificat échoue, vérifiez d'abord le port 80. Les causes courantes incluent un port 80 inaccessible, une règle de pare-feu cloud ou de groupe de sécurité incorrecte, et un DNS dont la propagation n'est pas terminée. Let's Encrypt ne peut pas valider un domaine qu'il ne peut pas atteindre.
Sécuriser le panneau d'administration de NPM sur un VPS
L'interface d'administration sur le port 81 est la principale exposition d'un déploiement NPM, et cette section la verrouille. Il s'agit de durcissement opérationnel, pas d'un audit de sécurité : trois actions, faites une seule fois, et le profil de risque baisse fortement.
D'abord, et c'est le plus important, gardez le port 81 lié à 127.0.0.1 comme indiqué dans le fichier Docker Compose. Accédez au tableau de bord via le tunnel SSH décrit plus haut. Si vous avez besoin d'un accès distant permanent, rendez l'interface d'administration accessible uniquement via un VPN privé. Ne publiez pas le port 81 sur l'IP publique du VPS.
Deuxièmement, activez l'authentification à deux facteurs TOTP sur votre compte admin. NPM a ajouté la 2FA basée sur TOTP dans la version 2.13.6, toute installation à jour en dispose donc. Activez-la.
Troisièmement, gardez NPM à jour et vérifiez la version exacte plutôt que de supposer que le tag latest est sûr. CVE-2026-40519 affecte les versions 2.9.14 à 2.15.1 et peut permettre l'exécution de code à distance authentifiée via des identifiants de fournisseur DNS malveillants. CVE-2026-50892 affecte la v2.14.0 et peut permettre à un attaquant authentifié d'obtenir le matériel de clé privée Let's Encrypt. Un problème antérieur, CVE-2025-50579, affectait la v2.12.3 via une faille CORS pouvant exposer des jetons JWT. La règle pratique est simple : gardez le port 81 privé, activez l'authentification à deux facteurs, épinglez une version corrigée connue, et vérifiez les bulletins de sécurité avant toute mise à niveau.
Le port 81 reste privé et NPM reste à jour. Faites ces deux choses et les principaux risques connus deviennent bien plus faciles à gérer pour une configuration classique à un seul VPS.
Dimensionner votre VPS pour Nginx Proxy Manager
NPM en lui-même est léger ; la question du dimensionnement concerne en réalité NPM plus les services placés derrière lui. L'empreinte du proxy au repos est rarement la contrainte. Une instance Nextcloud ou un blog Ghost consommera plus de ressources que le proxy lui-même.
Voici comment se répartissent les paliers en pratique :
- Base pratique minimale : 1 GB RAM, 1 vCPU et 10 GB de stockage. Un guide de dimensionnement tiers utilise la même base, mais considérez-la comme une indication de planification plutôt que comme une exigence officielle de NPM. Elle suffit pour NPM, le système d'exploitation et quelques services légers, mais laisse peu de marge.
- Confortable : 2 GB RAM, 1 vCPU, 20 GB de stockage. NPM plus trois à cinq services avec de la marge. C'est le point idéal pour la plupart des adeptes de l'auto-hébergement.
- Palier supérieur : 4 GB RAM, 2 vCPU. Pour huit à douze services, ou une configuration avec un trafic conséquent où vous voulez de la marge CPU pour la terminaison TLS.
Le chiffre sur lequel vous dimensionnez est la somme des applications proxifiées, pas NPM. Additionnez les empreintes RAM des services que vous comptez exécuter, ajoutez par-dessus la faible surcharge du proxy au repos, et choisissez le palier au-dessus avec de la marge.
Dimensionner la machine est la partie facile. Mettre NPM en service implique tout de même de provisionner le VPS, d'installer Docker, de récupérer l'image et de parcourir la configuration initiale. Si vous préférez sauter les étapes de provisionnement, le marketplace de Cloudzy propose un déploiement en un clic de Nginx Proxy Manager sur un VPS NVMe. Il met le conteneur en place sur un serveur neuf, vous passez donc directement au tableau de bord et à votre premier proxy host. Dans tous les cas, ce sont les paliers de dimensionnement ci-dessus qui servent de référence pour votre provisionnement.
Foire aux questions
Quelle est la différence entre Nginx et Nginx Proxy Manager ?
Nginx est le serveur web et le moteur de reverse proxy à proprement parler, que vous configurez en éditant des fichiers texte. Nginx Proxy Manager est une application Docker qui exécute Nginx en sous-jacent et y ajoute une interface web, de sorte que vous gérez les proxy hosts et les certificats Let's Encrypt via un tableau de bord plutôt qu'en écrivant des fichiers de configuration. NPM est la couche graphique ; Nginx est le moteur qui fait le travail.
Nginx Proxy Manager vaut-il encore la peine d'être utilisé en 2026 ?
Oui, pour les utilisateurs préférant une interface graphique et exécutant une petite stack Docker, mais seulement après avoir vérifié que l'image que vous déployez inclut les derniers correctifs de sécurité. Au 12 juillet 2026, la v2.15.1 est la dernière version taguée, et le NVD la répertorie comme affectée par CVE-2026-40519. Si vous préférez la configuration sous forme de code, Caddy reste le meilleur choix ; la configuration adossée à SQLite de NPM est sa principale limitation opérationnelle.
Quelle est la RAM minimale pour Nginx Proxy Manager ?
NPM en lui-même consomme au repos environ 50 MB de RAM. Un VPS de 1 GB constitue une base pratique, suffisante pour NPM et deux ou trois services légers. 2 GB sont confortables une fois que vous ajoutez davantage d'applications proxifiées. Le vrai besoin en RAM est déterminé par les services placés derrière NPM, pas par NPM lui-même.
Dois-je exposer le port 81 sur Internet ?
Non. Gardez le port 81 lié à localhost et accédez-y via un tunnel SSH, ou rendez-le accessible uniquement via un VPN privé. Ne publiez pas l'interface d'administration sur l'IP publique du VPS.
Puis-je exécuter Nginx Proxy Manager sans Docker ?
Non. NPM est distribué et conçu comme un conteneur Docker, et il n'existe pas d'installation non-Docker prise en charge. Si vous ne pouvez pas ou ne voulez pas utiliser Docker, utilisez plutôt Nginx brut avec Certbot, ou Caddy en binaire unique.
Nginx Proxy Manager prend-il en charge les certificats génériques ?
Oui, via un challenge DNS-01 avec un fournisseur DNS pris en charge et configuré. Les certificats standard à nom d'hôte unique utilisent le challenge HTTP-01 sur le port 80 ; les certificats génériques (*.example.com) nécessitent DNS-01 car l'autorité de certification valide le contrôle en écrivant un enregistrement DNS plutôt qu'en atteignant un hôte unique.
