Déployer vos applications avec Nginx Proxy Manager sur un VPS

Un VPS expose une seule adresse IP publique. Derrière cette IP, vous pouvez faire tourner cinq, dix ou vingt services sur des ports internes différents. Sans reverse proxy, exposer chaque service sur un port public implique d'ouvrir ces ports dans le pare-feu, de gérer manuellement les certificats TLS pour chacun, et d'en informer chaque utilisateur. Un reverse proxy résout ces trois problèmes d'un coup : il reçoit tout le trafic sur les ports 80 et 443, identifie le domaine demandé, et redirige la requête vers le bon conteneur interne. Nginx Proxy Manager ajoute une couche d'interface graphique à cette mécanique : pas de fichier de conf à écrire, pas de reload manuel, et les certificats Let's Encrypt se gèrent en quelques clics. C'est particulièrement adapté aux agences qui hébergent plusieurs applications clientes sur le même serveur, ou aux développeurs indépendants qui font tourner plusieurs projets en parallèle.

NPM ne fait que router du trafic, il est donc léger. Un VPS avec 1 Go de RAM et 1 vCPU suffit si NPM est le seul service notable. Si vous hébergez également les applications derrière lui, dimensionnez selon la somme de leurs besoins. Prévoyez 15 Go de disque SSD (certificats, base SQLite, logs). Logiciel requis : Docker 24+ et le plugin Compose v2 (docker compose, pas l'ancienne commande docker-compose). Réseau : les ports 80 et 443 doivent être libres sur le VPS — NPM en est l'unique occupant. Le port 81 est réservé à l'interface d'administration ; il ne doit jamais être exposé directement sur Internet. DNS : faites pointer vos enregistrements A vers l'IP du VPS avant de demander les certificats. Pour un wildcard *.votre-domaine.com, il faut une clé API auprès de votre fournisseur DNS (Cloudflare, OVH, etc.).

NPM expose dans son interface plusieurs fonctionnalités qui vont au-delà du simple reverse proxy. Les Access Lists permettent de restreindre l'accès à un hôte par plage d'IP, par identifiant HTTP Basic Auth, ou par une combinaison des deux — utile pour protéger un backoffice sans ajouter d'authentification dans l'application elle-même. Les Streams gèrent le proxying TCP/UDP pour les protocoles non-HTTP (MySQL distant, serveur de jeux, MQTT…). La section Redirections crée des règles permanentes (301) ou temporaires (302) d'un domaine ou d'un chemin vers une autre URL, sans qu'un service soit nécessaire derrière. Les onglets Avancé de chaque proxy host permettent d'injecter de la configuration Nginx brute lorsque l'interface ne couvre pas un cas particulier (en-têtes de sécurité personnalisés, proxy_read_timeout étendu pour les longues requêtes d'upload, etc.).

Voici les cinq problèmes les plus fréquents rencontrés après une installation de NPM, avec leur diagnostic direct.

NPM convient parfaitement pour un parc de services stable dont le nombre reste maîtrisé. Dès que vous gérez des déploiements dynamiques — conteneurs qui apparaissent et disparaissent automatiquement, comme en environnement Kubernetes ou avec des pipelines CI/CD qui créent des previews à la volée — Traefik devient plus adapté : sa découverte de services via les labels Docker évite de retourner dans l'interface pour chaque nouveau conteneur. Caddy est une bonne alternative si vous cherchez la simplicité de configuration par fichier avec des certificats automatiques, sans interface web. Dans tous les cas, NPM peut coexister avec Traefik ou Caddy sur le même VPS, chacun gérant une partie du trafic — à condition de ne pas mettre deux proxies sur les mêmes ports 80 et 443. Si votre infrastructure grossit au point où vous gérez plusieurs dizaines de services avec des équipes différentes, un maillage de services (Consul Connect, Linkerd) remplace avantageusement l'empilement de proxies.