title: Wiredoor created: 2026-06-07 updated: 2026-06-07 type: app tags: [catalogue, vpn, wireguard, tunneling, reverse-proxy, go, letsencrypt] confidence: high contested: false sources: [https://selfh.st/apps/?tag=VPN, https://github.com/wiredoor/wiredoor]

🔐 Wiredoor

Le tunnel sécurisé auto-hébergé pour exposer des services internes sur Internet sans ouvrir de port. Alternative self-hosted à Cloudflare Tunnel, Ngrok et FRP, basé sur WireGuard.

📋 Informations Générales

Champ	Valeur
Site web	(GitHub)
GitHub	wiredoor/wiredoor
License	AGPL-3.0
Langage	Go
Étoiles GitHub	1,6k ⭐
Dernière MAJ	2026-05
Catégorie	[[cat-vpn

📝 Description

Wiredoor est une plateforme de tunneling sécurisé écrite en Go qui permet d'exposer des services s'exécutant sur des réseaux privés ou locaux (homelab, intranet, IoT) vers Internet sans ouvrir de port entrant sur le pare-feu. Le canal de transport est un tunnel WireGuard chiffré bout-en-bout, et la terminaison HTTPS est gérée automatiquement avec Let's Encrypt.

L'idée est la même que Cloudflare Tunnel ou Ngrok : un client léger (le « wiredoor client ») tourne à côté du service à exposer, initie une connexion sortante vers le serveur Wiredoor, et tout le trafic est ensuite proxifié via ce tunnel. Le serveur publie le service sur un sous-domaine en HTTPS, gère le routage, l'authentification et les certificats.

Wiredoor se distingue des autres par son orientation multi-tenant et sa capacité à gérer simultanément plusieurs clients (services), avec une UI web pour les administrateurs. C'est un excellent choix pour les freelances, MSP, ou homelabs qui veulent exposer plusieurs sites/apps sans IP publique ni configuration DNS complexe.

Public cible : admins qui doivent exposer des services internes derrière un NAT ou un pare-feu restrictif, sans Cloudflare, sans Ngrok, et avec un chiffrement fort.

✅ Tunnel WireGuard : transport chiffré, latence minimale
✅ HTTPS automatique : certificats Let's Encrypt gérés par le serveur
✅ Multi-tenant : plusieurs clients / services depuis une seule instance
✅ Reverse proxy intégré : routage par sous-domaine
✅ Auth basique : Basic Auth, headers personnalisés par service
✅ TCP et HTTP : supporte aussi bien HTTP(S) que TCP brut
✅ Binaire unique Go : léger, rapide, peu de dépendances
✅ Docker ready + binaire standalone
✅ Dashboard web de gestion des services
✅ API pour automatisation

🚀 Installation

Docker Compose (serveur + client)

# docker-compose.yml — serveur Wiredoor
version: '3.8'
services:
  wiredoor-server:
    image: ghcr.io/wiredoor/wiredoor-server:latest
    container_name: wiredoor-server
    restart: unless-stopped
    ports:
      - "80:80"     # HTTP (challenge ACME)
      - "443:443"   # HTTPS (terminaison)
      - "51820:51820/udp"  # WireGuard (transport tunnel)
    environment:
      - WDOOR_HOST=wire.example.com
      - WDOOR_LISTEN_HOST=0.0.0.0
      - WDOOR_DOMAIN=wire.example.com
      - WDOOR_DB_DRIVER=sqlite
      - WDOOR_DB_DSN=/data/wiredoor.db
    volumes:
      - wiredoor-data:/data
    labels:
      - "traefik.enable=false"  # Wiredoor gère lui-même le HTTPS

  # Exemple : client (sur la même machine, ou un autre hôte du LAN)
  wiredoor-client:
    image: ghcr.io/wiredoor/wiredoor-client:latest
    container_name: wiredoor-client
    restart: unless-stopped
    network_mode: host  # Accès au service à exposer
    cap_add:
      - NET_ADMIN
    environment:
      - WDOOR_SERVER_URL=https://wire.example.com
      - WDOOR_CLIENT_DOMAIN=app.example.com
      - WDOOR_CLIENT_TYPE=http
      - WDOOR_CLIENT_SERVICE_URL=http://127.0.0.1:8080

volumes:
  wiredoor-data:

Important

: le port UDP 51820 (ou autre choisi) doit être ouvert sur le pare-feu du serveur pour permettre l'arrivée des tunnels WireGuard. Les services HTTP/HTTPS sont ensuite servis par Wiredoor lui-même — pas besoin de app-traefik en frontal, sauf si on veut ajouter un WAF.

⚙️ Configuration Initiale

Définir le domaine public pointant vers le serveur (DNS A ou AAAA sur wire.example.com)
Démarrer le serveur et créer le compte admin au premier lancement
Ouvrir les ports : 80/TCP (ACME), 443/TCP (HTTPS), 51820/UDP (WireGuard)
Enregistrer un client : Dashboard > Clients > New > générer un token
Déployer le client sur l'hôte du service à exposer, avec le token + l'URL du service backend
Vérifier que le sous-domaine app.example.com répond et que le certificat est émis automatiquement

🔄 Alternatives

Open Source

app-wireguard — Le moteur de tunneling, sans la surcouche proxy
frp (Fatedier) — Tunneling rapide, sans WireGuard (TCP direct)
inlets — Tunnel TCP/HTTP avec tunnel cloud optionnel
rathole — Tunneling moderne écrit en Rust
bore — Tunnel TCP minimaliste en Rust
self-hosted-gateway — Passerelle reverse proxy + tunnels

Comparaison Wiredoor vs alternatives de tunneling

Critère	Wiredoor	Cloudflare Tunnel	frp	Ngrok	inlets
Self-hosted	✅	❌ (SaaS)	✅	❌ (freemium)	✅
Transport chiffré	WireGuard	WireGuard-like (QUIC)	TCP/TLS	TCP	TCP/WSS
HTTPS auto	✅ (LE)	✅ (CF)	❌ (manuel)	✅ (freemium)	❌ (manuel)
Multi-tenant natif	✅	✅	❌	✅	❌
Licence	AGPL-3.0	Propriétaire	Apache-2.0	Propriétaire	MIT
Coût	Gratuit	Freemium	Gratuit	Freemium	Freemium

Verdict : Wiredoor est l'une des rares solutions entièrement open source, multi-tenant et avec HTTPS automatique. Excellent choix si vous voulez éviter la dépendance Cloudflare et garder un tunnel basé sur WireGuard. Pour des besoins très simples (1 service, 1 machine), frp ou inlets suffisent.

Propriétaires (ce que Wiredoor remplace)

Cloudflare Tunnel (gratuit avec limitations, lié à CF)
Ngrok (gratuit très limité, sinon 8$/mois)
Loophole (freemium)
Tailscale Funnel (gratuit, mais lié à Tailscale)
Cloudflare Access (payant en entreprise)

🔐 Sécurité

Cryptographie : tout le transport s'effectue dans un tunnel WireGuard — ChaCha20-Poly1305, Curve25519, BLAKE2s. Le tunnel est authentifié par les paires de clés WireGuard générées à l'enregistrement du client.
Clés privées : stockées sur le serveur et le client dans des volumes Docker chiffrés. Les clés privées ne transitent jamais sur le réseau en clair.
Auth service : support de Basic Auth et de headers personnalisés injectés dans la requête vers le backend. Possibilité d'ajouter un middleware par service.
HTTPS de bout en bout : le navigateur parle HTTPS au serveur Wiredoor, qui déchiffre puis re-chiffre en HTTP (ou HTTPS si le backend le supporte) via le tunnel WireGuard. Le trafic ne traverse jamais Internet en clair.
Authentification admin : comptes stockés en base (SQLite par défaut, PostgreSQL supporté), mots de passe hashés (bcrypt). Activer 2FA si disponible.
Audit log : journalisation des connexions tunnels, des requêtes, et des actions d'administration.
Isolation réseau : ne JAMAIS exposer le port 51820/UDP en accès public sans pare-feu, limiter aux IPs attendues ou coupler avec un fail2ban.
Renouvellement Let's Encrypt : vérifier que le défi HTTP-01 fonctionne (port 80 accessible publiquement) et que le cron de renouvellement est en place.

📚 Ressources

Pages Liées

cat-vpn — Catégorie VPN
app-wireguard — Le transport chiffré
app-tailscale — Alternative mesh VPN
app-headscale — Controller Tailscale self-hosted
app-traefik — Pour ajouter WAF / auth en amont
securisation-home-lab — Bonnes pratiques sécurité

8.3 KiB Raw Blame History