Pourquoi j’ai choisi Nginx Proxy Manager Plus plutôt que Traefik (et le NPM classique)

Dans le petit monde du self‑hosting et des homelabs, on croise très vite trois gros noms dès qu’on parle de reverse proxy :

• Nginx Proxy Manager (NPM)
• Nginx Proxy Manager Plus (NPM+)
• Traefik

Après avoir testé, cassé, re‑testé, lu des retours d’expérience et croisé ça avec mes besoins (homelab + projet d’hébergement associatif type HebergHub), j’ai fini par trancher :

je pars sur Nginx Proxy Manager Plus, plutôt que Traefik ou que le NPM “vanilla”.

Voici pourquoi.

---

1. Le contexte : un reverse proxy pour homelab + projets “semi‑sérieux”

Mon besoin, ce n’est pas juste “publier trois containers en HTTPS pour moi tout seul”.
Je veux :

• quelque chose de simple à administrer, même après plusieurs semaines sans y toucher ;
• qui fonctionne bien dans un contexte Docker / Proxmox / homelab ;
• qui s’intègre dans une logique type HebergHub :
  • plusieurs services,
  • plusieurs domaines / sous‑domaines,
  • des utilisateurs non admin système qui peuvent parfois jeter un œil,
  • et à terme, des environnements plus “prod” que “bricolage”.

Je veux un truc :

• assez puissant pour gérer des scénarios un peu avancés,
• mais pas au prix de devoir tout écrire en YAML ou en labels Docker pour la moindre redirection.

---

2. Pourquoi pas “juste” Nginx Proxy Manager classique ?

Le NPM classique est déjà un énorme pas en avant par rapport à configurer Nginx à la main :

• interface web intuitive,
• création de “Proxy Hosts” en quelques clics,
• gestion intégrée des certificats Let’s Encrypt,
• support WebSocket, redirections, basiques de sécurité, etc.

Pour un homelab classique, beaucoup de gens s’arrêtent là — et c’est très bien.

Mais il y a aussi des limites connues du NPM open‑source :

• mise à jour moins fréquente que Nginx “brut” ;
• dépendance forte à un projet maintenu par peu de personnes ;
• quelques features avancées absentes ou pas super bien intégrées (système d’utilisateurs, RBAC, monitoring, backup/restore, etc.) ;
• certaines erreurs de config peuvent impacter l’ensemble du service.

NPM+ (la variante “Plus”, payante/licenciée) cherche justement à combler certains de ces manques avec :

• un support plus sérieux / pro,
• des fonctionnalités additionnelles (gestion multi‑utilisateurs, intégrations, gestion plus fine, etc.),
  tout en gardant le même paradigme de départ : GUI sur du vrai Nginx derrière.

---

3. Pourquoi je n’ai pas retenu Traefik (même si c’est un super outil)

Traefik, sur le papier, a énormément d’arguments, surtout dès qu’on fait beaucoup de conteneurs :

• découverte automatique des services via Docker / Swarm / Kubernetes ;
• configuration déclarative (labels, YAML, CRD K8s) ;
• intégration poussée avec des stacks cloud‑native (Prometheus, Grafana, DataDog, etc.) ;
• middlewares intégrés (auth, rate limiting, headers, etc.).

Vu de loin, c’est extrêmement séduisant.
Dans la pratique, pour mon usage, je me suis retrouvé face à plusieurs constats :

3.1. Courbe d’apprentissage vs temps disponible

Traefik est pensé pour être infrastructure as code.
C’est génial… quand tu es prêt à passer :

• du temps dans les labels,
• du temps à comprendre la logique des routers / middlewares / services,
• du temps à maintenir tes fichiers de config et ton CI autour.

Pour un homelab / projet comme HebergHub où :

• il y a déjà énormément d’autres sujets à gérer (infra, sécurité, docs, pédagogie, relation “clients”),
• d’autres personnes que moi pourraient un jour intervenir sur la stack,

je ne voulais pas que “comprendre Traefik” devienne un prérequis pour toucher au reverse proxy.
Les retours d’autres self‑hosters vont d’ailleurs dans ce sens : Traefik est très puissant, mais pas forcément le bon choix si tu veux surtout un outil simple à piloter au quotidien.

3.2. Manque de GUI d’édition

Le dashboard Traefik est très pratique pour voir ce qui se passe…
mais pas pour configurer. Tout se fait dans les labels / fichiers / providers.

Dans mon contexte, je préfère un outil où :

• je peux ouvrir une interface web,
• ajouter un nouveau service avec 2–3 champs,
• gérer les certificats et quelques règles sans replonger dans de la config déclarative.

Ça ne veut pas dire que Traefik est “mauvais” — juste qu’il est taillé pour d’autres priorités (micro‑services massifs, infra 100 % IaC, Kubernetes, etc.).

---

4. Pourquoi Nginx Proxy Manager Plus matche mieux mon usage

En gros, NPM+ coche un ensemble de cases qui, ensemble, le rendent plus adapté à mon contexte :

4.1. Une GUI complète, sur du vrai Nginx

NPM/NPM+ reposent sur Nginx natif pour le proxy.
La GUI ne fait “que” générer des configs Nginx, ce qui permet de garder :

• les performances et la robustesse de Nginx,
• la possibilité d’injecter du custom Nginx dans l’onglet “Advanced” quand il faut aller plus loin,
• une architecture que je sais déboguer si besoin (logs, fichiers de conf, etc.).

Et surtout, l’interface :

• permet de créer / modifier / supprimer des “Proxy Hosts” en quelques clics ;
• gère les certificats Let’s Encrypt (HTTP / DNS challenge) sans prise de tête ;
• reste lisible et exploitable même après plusieurs semaines sans y toucher.

4.2. Une meilleure gestion “multi‑clients”

Pour HebergHub et d’autres projets, j’ai envie de pouvoir :

• séparer les environnements (prod / test / perso),
• limiter qui peut faire quoi,
• à terme, avoir une gestion plus fine des utilisateurs que juste “un admin root sur le reverse proxy”.

NPM+ propose justement un certain nombre de features orientées “multi‑tenant / multi‑utilisateurs” (selon l’édition choisie), qui vont dans ce sens, là où le NPM classique reste très “un seul admin qui gère tout”.

4.3. Moins de magie, plus de lisibilité

Traefik brille quand on veut que tout soit dynamique, auto‑découvert, piloté par labels.

De mon côté, je préfère actuellement une approche :

• un peu moins magique,
• un peu plus déclarative via la GUI,
• où chaque service est clairement visible dans une liste, avec son domaine, son backend, son certificat.

Ça colle mieux à :

• un homelab documenté,
• un projet comme HebergHub où je veux pouvoir expliquer facilement ce qu’on a fait,
• des cas où d’autres personnes (pas forcément ingénieurs infra) doivent comprendre “par où ça passe”.

---

5. Ce que je sacrifie (et que j’assume)

Choisir NPM+ plutôt que Traefik, ce n’est pas “gagner sur tous les tableaux”.
Concrètement, j’accepte de perdre :

• l’auto‑découverte dynamique des containers / services Docker,
• la configuration totalement “as code” du reverse proxy,
• certains middlewares avancés intégrés nativement côté Traefik (circuit breaking, rate limiting évolué, etc.).

Mais à ce stade :

• ce n’est pas mon point de douleur principal ;
• mes déploiements restent déjà largement automatisables (via Ansible / scripts / templates Docker Compose) en amont ;
• je préfère investir mon temps sur :
  • la qualité des stacks applicatives,
  • la sécurité,
  • la supervision,
  • la pédagogie autour des services.

En bref : je sacrifie une partie de la “cloud‑nativeness” de Traefik
pour gagner en cohérence d’usage et en simplicité de gestion quotidienne.

---

6. Et pour la suite ?

Ce choix n’est pas gravé dans le marbre.

À moyen/long terme, il est possible que :

• pour certains use cases très spécifiques (Kubernetes, microservices massifs, multi‑clusters),
• ou pour des clients qui exigent une infra 100 % IaC,

je déploie du Traefik à côté, dans un rôle plus ciblé.

Mais pour :

• mon homelab,
• mes projets perso,
• et une grosse partie de ce que je veux construire avec HebergHub,

Nginx Proxy Manager Plus offre aujourd’hui le meilleur compromis entre :

• puissance (Nginx en dessous),
• simplicité (GUI + gestion TLS intégrée),
• maintenabilité (visible, explicable, déboguable par d’autres que moi).

Et surtout, c’est un outil que je peux laisser vivre sans devoir me replonger dans une pile de fichiers YAML à chaque fois que je veux ajouter un sous‑domaine.

---

Si tu hésites toi aussi entre NPM, NPM+ et Traefik, la vraie question à te poser n’est peut‑être pas “quel est le plus puissant”, mais :

De combien de complexité as‑tu besoin aujourd’hui,
et qui devra maintenir ce reverse proxy après toi ?