1. Contexte & Objectif
L'objectif de départ était simple : héberger mes propres services et ceux d'amis sans payer de VPS externe, tout en apprenant concrètement la gestion de conteneurs et d'infrastructure. Ce qui a commencé comme un serveur Minecraft s'est transformé en une plateforme stable hébergeant aujourd'hui une dizaine de services actifs.
Contrainte principale dès le départ : mon opérateur utilise du CGNAT (Carrier-Grade NAT), ce qui rend l'ouverture de ports classique impossible depuis l'extérieur. La solution adoptée — Cloudflare Tunnels — a résolu ce problème et s'est révélée plus propre que l'ouverture de ports : zéro port exposé sur la box, SSL automatique, et les services restent accessibles même si l'IP change.
2. Services en Production
Trois domaines exposés publiquement, chacun routé via Cloudflare vers le bon service en interne. Portainer est utilisé pour l'administration graphique des conteneurs.
3. Stack Technique
- Hyperviseur : Proxmox VE — les services tournent dans des VM et conteneurs LXC dédiés.
- Conteneurisation : Docker & Docker Compose pour l'isolation et la gestion des services.
- Administration : Portainer pour la supervision graphique des conteneurs.
- Reverse Proxy : Nginx Proxy Manager — gestion des certificats SSL et routage des domaines.
- Exposition : Cloudflare Tunnels — pas de port ouvert sur la box, tunnel sortant uniquement.
- Jeux : Pterodactyl Panel pour gérer les serveurs Minecraft via une interface web.
4. Configuration — Reverse Proxy
Déploiement de Nginx Proxy Manager via docker-compose.yml :
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
- '80:80' # HTTP
- '81:81' # Admin Panel
- '443:443' # HTTPS
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt5. Ce que j'ai appris
La partie technique — Docker, Nginx, SSL — est finalement la plus simple à mettre en place. Le vrai défi c'est l'opérationnel : comprendre pourquoi un service est down, gérer les conflits de ports entre conteneurs, ou réaliser qu'un Nextcloud qui rame c'est souvent un problème de base de données et pas de CPU.
J'ai monté cette infra avec beaucoup d'aide de la documentation et de la communauté. Ce qui m'a réellement formé c'est de ne pas me contenter de copier les commandes, mais de chercher pourquoi chaque solution fonctionnait — et surtout pourquoi elle ne fonctionnait pas quand ça partait en erreur.
La contrainte CGNAT, que je voyais au départ comme un problème, s'est transformée en une meilleure pratique : les Cloudflare Tunnels sont aujourd'hui la solution que je recommanderais à n'importe qui dans la même situation.