wiki/Catalogue-Self-Hosted/apps/app-self-hosted-gateway.md

---

title: Self-Hosted Gateway created: 2026-06-06 updated: 2026-06-06 type: app tags: [catalogue, reverse-proxy, tunnel, docker, wireguard, nat-traversal] confidence: medium contested: false sources: [https://selfh.st/apps/?tag=Reverse+Proxy, https://github.com/hintjen/selfhosted-gateway]

🌐 Self-Hosted Gateway

Tunnel natif Docker pour exposer des conteneurs locaux sur Internet via WireGuard + proxy inverse. Réputation : alternative légère à Ngrok et Cloudflare Tunnel, sans dépendance à un tiers.

📋 Informations Générales

Champ	Valeur
Site web	github.com/hintjen/selfhosted-gateway
GitHub	hintjen/selfhosted-gateway
License	MIT
Langage	Go, Shell
Étoiles GitHub	1.7k ⭐
Dernière MAJ	2026-03
Catégorie	cat-reverse-proxy, Tunnel, NAT Traversal

📝 Description

Self-Hosted Gateway (par hintjen) est un outil de tunneling auto-hébergé qui résout un cas d'usage très spécifique mais fréquent : exposer un service local à Internet quand on n'a pas la main sur le routeur (CGNAT, réseau d'entreprise, IP dynamique sans DNS).

Le principe : un VPS léger (ou une machine publique) héberge le composant serveur du gateway, et la machine locale (derrière le NAT) fait tourner le client. Entre les deux, un tunnel WireGuard chiffré transporte le trafic. Le serveur gateway termine le TLS (Let's Encrypt) et présente le service au monde extérieur.

L'avantage par rapport à Cloudflare Tunnel : pas de dépendance à un tiers, pas de compte Cloudflare, pas de lock-in, pas de logs côté éditeur. Par rapport à Ngrok : gratuit et illimité (vous payez juste le VPS serveur).

Public cible : développeurs et self-hosters qui veulent un service Ngrok-like maison. Idéal pour exposer temporairement un dev server, partager une démo, ou publier un service perso depuis un réseau contraignant.

🚀 Installation

Architecture en 2 parties

Partie 1 : Serveur gateway (VPS public)

# Sur un VPS (Hetzner, OVH, etc.)
# docker-compose.yml
services:
  gateway-server:
    image: hintjen/selfhosted-gateway-server:latest
    container_name: gateway-server
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "51820:51820/udp"   # WireGuard
    environment:
      - GATEWAY_DOMAIN=tunnel.example.com
      - EMAIL=admin@example.com
    volumes:
      - gateway_certs:/etc/letsencrypt
    networks:
      - gateway-net

networks:
  gateway-net:

volumes:
  gateway_certs:

Partie 2 : Client local (machine derrière le NAT)

# docker-compose.yml (sur votre machine locale)
services:
  app-demo:
    image: nginx:alpine
    container_name: app-demo
    networks:
      - app-net

  gateway-client:
    image: hintjen/selfhosted-gateway-client:latest
    container_name: gateway-client
    restart: unless-stopped
    environment:
      - GATEWAY_SERVER=tunnel.example.com:51820
      - GATEWAY_TOKEN=***
      - GATEWAY_AUTH_KEY=***
      - EXPOSE_TARGET=app-demo:80
      - EXPOSE_DOMAIN=demo.example.com
    networks:
      - app-net
    depends_on:
      - app-demo

networks:
  app-net:

Option 2 : Variante Traefik

Self-Hosted Gateway ne remplace pas Traefik sur la machine locale — il expose le trafic à Internet en amont. Si vous avez déjà Traefik localement, vous pouvez :

# Exposer Traefik lui-même
services:
  gateway-client:
    environment:
      - EXPOSE_TARGET=traefik:80    # pointe vers le proxy local
      - EXPOSE_DOMAIN=proxy.example.com

⚙️ Configuration Initiale

1. Provisionner un VPS (2 GB RAM suffisent) avec un nom de domaine pointant dessus
2. Déployer le serveur gateway sur le VPS
3. Récupérer le GATEWAY_TOKEN et la GATEWAY_AUTH_KEY (clé publique WireGuard du serveur)
4. Configurer le client sur la machine locale avec ces credentials
5. DNS : pointer le sous-domaine d'exposition vers l'IP du VPS
6. Lancer : docker compose up -d
7. HTTPS : le serveur gateway obtient automatiquement un cert Let's Encrypt

# Vérifier le tunnel
docker logs gateway-client
# → doit afficher "Tunnel established" et "Reverse proxy ready"

# Tester depuis l'extérieur
curl -I https://demo.example.com

🔀 Alternatives

Open Source

• app-pangolin — Concurrent plus large (tunnel + auth + reverse proxy complet)
• app-godoxy — Inclut tunnel WireGuard + reverse proxy
• app-cloudflared : la référence, mais avec dépendance Cloudflare
• frp (Fast Reverse Proxy) : alternative chinoise, mature
• bore : alternative minimaliste en Rust

Comparaison Self-Hosted Gateway vs concurrents

Critère	Self-Hosted Gateway	Cloudflare Tunnel	Pangolin	frp
Dépendance tiers	❌ Aucune	⚠️ Cloudflare	❌ Aucune	❌ Aucune
Coût récurrent	VPS	Gratuit (limites)	VPS	VPS
Auth intégrée	❌	✅ Cloudflare Access	✅ Natif	❌
WebUI	❌	✅	✅	⚠️
Multi-tenant	❌	❌	✅	⚠️
Maturité	⚠️ Récent	✅ Très mature	⚠️ Récent	✅ Mature
WireGuard	✅	❌	⚠️	❌

Propriétaires (ce que ça remplace)

• Ngrok (free tier limité à 1 tunnel)
• Tailscale Funnel (gratuit mais avec contraintes)
• Cloudflare Tunnel (alternative sans lock-in)
• Localtunnel / serveo (instables, pas pour la prod)

🔒 Sécurité

• ✅ Chiffrement bout-en-bout via WireGuard (algo ChaCha20)
• ✅ Pas de log côté serveur (par design)
• ✅ HTTPS automatique au niveau du serveur gateway
• ✅ Tokens d'authentification pour enregistrer de nouveaux tunnels
• ⚠️ VPS = SPOF : si le VPS tombe, tous les tunnels tombent
• ⚠️ Pas d'auth sur les services exposés : mettre un WAF / auth en amont
• ⚠️ Clé WireGuard : sensible, rotation régulière
• ⚠️ Pas d'audit formel : projet de taille modeste, revue manuelle recommandée

📚 Ressources

• README GitHub
• Wiki selfh.st
• Documentation WireGuard
• Comparatif tunnels auto-hébergés

🔗 Pages Liées

• cat-reverse-proxy — Catégorie Reverse Proxy
• app-pangolin — Concurrent plus complet
• app-godoxy — Concurrent avec tunnel intégré
• app-traefik — Reverse proxy interne
• app-cloudflared — Concurrent avec dépendance Cloudflare
• comparatif-reverse-proxy — Comparaison détaillée
• securisation-home-lab — Sécurité