Documentation
Alternative à ngrok : partager un service local, en privé ou en public
ngrok a rendu triviale une opération autrefois pénible : rendre un service local joignable depuis l’extérieur, en une commande, via une URL publique temporaire qui transite par ses serveurs. L’outil est devenu un réflexe de développeur — webhooks, démos, tests. Mais ce réflexe masque une question que l’on ne se pose presque jamais : votre besoin est-il vraiment public ? Montrer une démo à un collègue, tester depuis son téléphone, atteindre son dev server à distance : aucun de ces usages n’exige d’URL ouverte à tout Internet. VIGIL-MESH propose les deux réponses : le mesh privé quand les personnes sont identifiées — zéro exposition — et la publication HTTP ou TCP quand un service tiers doit réellement vous joindre depuis le monde public.
Ce que fait ngrok, et pourquoi il est devenu un réflexe
Le principe de ngrok est simple et efficace : un client tourne sur votre machine, établit une connexion sortante vers les serveurs de ngrok, et ceux-ci vous attribuent une URL publique temporaire. Tout ce qui arrive sur cette URL est acheminé, à travers le tunnel, jusqu’au port local de votre choix. Votre machine n’a aucun port entrant à ouvrir ; le service local devient joignable depuis n’importe où en quelques secondes.
C’est ce qui a fait son succès en développement : recevoir les webhooks d’un service tiers sur son poste de travail, montrer une application en cours de développement sans la déployer, tester une intégration qui exige une adresse joignable depuis Internet. L’outil fait très bien ce qu’il promet, et cette page ne cherche pas à démontrer le contraire.
La bonne question : qui doit joindre votre service ?
Avant de chercher une alternative à ngrok, il vaut la peine de trier les usages. Dans la grande majorité des cas, les personnes qui doivent atteindre votre service local sont identifiées : un collègue, un client en réunion, vous-même depuis un autre appareil. Une URL ouverte au monde entier est alors surdimensionnée : on expose à tout Internet ce que deux personnes doivent voir. Le seul cas qui exige réellement du public, c’est celui où l’appelant est un serveur tiers que vous ne contrôlez pas — un service de paiement, une forge logicielle, une plateforme SaaS qui doit livrer ses webhooks à une adresse joignable depuis Internet.
Montrer une démo à un collègue
Le collègue est connu, identifié, joignable. Il n’a pas besoin d’une URL publique : il a besoin d’atteindre votre machine, et seulement elle. C’est un besoin privé.
Tester depuis son téléphone
Le téléphone est le vôtre. Faire transiter le trafic entre votre poche et votre bureau par une URL mondiale est un détour : il suffit que le téléphone rejoigne le même réseau privé que le poste de dev.
Accéder à son dev server à distance
Retrouver son environnement de développement depuis chez soi ou en déplacement est un besoin d’accès permanent — mais toujours pour la même personne : vous. Encore un besoin privé.
Recevoir le webhook d'un service tiers
Ici, l’appelant est un serveur externe qui ne rejoindra jamais votre réseau. Il lui faut une URL publique. C’est le cas légitime d’exposition — et il mérite d’être traité proprement.
Partager en privé : le mesh remplace l'URL publique
Pour tous les usages privés, VIGIL-MESH remplace le tunnel public par un réseau privé : votre machine et celle du collègue rejoignent le même espace de travail, et se joignent directement, par une session QUIC/TLS 1.3 chiffrée de bout en bout. Le collègue ouvre son navigateur sur le nom de votre machine — un nom MagicDNS stable, suivi du port du dev server — et voit la démo comme s’il était sur votre réseau local. Rien n’est publié, rien n’est joignable depuis Internet : il n’existe tout simplement pas d’URL publique à découvrir.
- Un nom stable, pas une URL jetable — la machine garde son adresse (dans 100.64.0.0/10) et son nom MagicDNS quels que soient les redémarrages et le réseau physique où elle se trouve. Le lien envoyé au collègue hier fonctionne encore demain.
- L’accès suit l’identité, pas le secret de l’URL — les ACL, en refus par défaut, décident qui joint quoi : vous pouvez n’ouvrir au collègue que votre machine, voire un seul service, et rien d’autre de votre réseau.
- Zéro exposition — aucun port entrant nulle part : chaque machine n’établit que des connexions sortantes, un seul flux en 443 UDP. Votre dev server n’apparaît sur aucun scan d’Internet.
- Ça marche derrière n’importe quelle box — NAT domestique, pare-feu d’entreprise, 4G/5G en CGNAT : la connexion s’établit immédiatement via un relais aveugle, puis migre sans coupure vers le chemin direct.
- Révocable à l’instant — la démo terminée, vous suspendez ou révoquez l’appareil invité depuis la console : il perd l’accès immédiatement.
Quand il faut vraiment du public : la publication HTTP et TCP
Reste le cas où l’appelant ne peut pas rejoindre votre réseau : le webhook d’un service tiers, une API consommée par un partenaire externe. Pour cela, VIGIL-MESH offre la publication : un point d’entrée public unique qui pointe vers un seul service interne. Le trafic entrant est reçu par la plateforme, puis relayé jusqu’au service à travers le mesh chiffré. La machine qui héberge le service n’ouvre toujours aucun port entrant — elle peut vivre derrière un NAT domestique ou un lien mobile — et le visiteur n’apprend rien de la topologie ni des services restés privés.
La publication HTTP s’adresse aux services qui parlent le web : la plateforme agit en reverse-proxy, termine la connexion TLS côté public avec un certificat obtenu et renouvelé automatiquement pour votre nom de domaine, puis transporte la requête jusqu’au service interne. Pour tout ce qui n’est pas du web — un protocole métier, un flux brut —, la publication TCP expose un port de transport : le flux est relayé tel quel, sans être interprété et donc sans terminaison TLS par la plateforme.
Besoin réel → bon outil
Le tableau qui suit résume la logique de la page : partir du besoin réel — qui doit joindre le service, pour combien de temps — et en déduire l’outil, plutôt que d’appliquer le réflexe de l’URL publique à tout.
| Besoin réel | Bon outil | Pourquoi |
|---|---|---|
| Démo à un collègue ou un client identifié | Mesh privé (enrôlement + nom MagicDNS) | Accès nominatif, ACL au plus juste, aucune URL publique à protéger ni à faire expirer |
| Tester son application depuis son téléphone | Mesh privé (app Android, QR code) | Le téléphone devient membre du réseau ; le dev server se joint par son nom, de partout |
| Accès permanent à son dev server ou à un service perso | Mesh privé | Nom et adresse stables dans la durée — rien à relancer, rien qui expire |
| Webhook d'un service tiers (paiement, forge, SaaS) | Publication HTTP | URL publique durable sous votre domaine, certificat TLS automatique, service hébergé derrière NAT |
| Service non-web à ouvrir à un partenaire externe | Publication TCP | Port public relayé tel quel ; le protocole assure son propre chiffrement |
| URL jetable, tout de suite, pour un tiers anonyme | ngrok (ou tunnel équivalent) | Une commande, zéro configuration préalable — plus simple quand l'éphémère et l'anonyme sont précisément le besoin |
Pas à pas : la démo privée, sans rien exposer
Scénario : votre application tourne sur votre poste, et un collègue distant doit la voir. Une fois l’espace de travail en place, l’opération se résume à enrôler sa machine — et les démos suivantes ne demanderont plus rien du tout.
- 1Créer un compte et un espace de travailL’espace de travail est le périmètre privé qui contiendra vos machines et celles de vos invités. À ne faire qu’une fois.
- 2Installer le client sur les machines concernéesLe vôtre et celui du collègue — Windows, Linux, Android, selon les cas. Le client n’établit que des connexions sortantes : rien à configurer sur les box.
- 3Enrôler la machine du collèguePage Réseaux → Machines → « Ajouter une machine » : l’assistant remet une clé d’enrôlement à usage unique, à passer au client en commande ou en QR code sur mobile.
- 4Vérifier la connectivitéLa machine apparaît dans la console avec son adresse stable et son nom MagicDNS ; un ping sur le nom confirme que tout est en place.
- 5Partager le lien privéLe collègue ouvre le nom de votre machine suivi du port du dev server dans son navigateur, comme en local. Après la démo, suspendez ou révoquez son appareil depuis la console : l’accès tombe immédiatement.
Pas à pas : publier une URL pour un webhook
Scénario : un service tiers doit livrer ses webhooks à une URL joignable depuis Internet, et le récepteur tourne sur une machine du mesh — votre poste de dev, un serveur chez vous. La publication HTTP crée cette URL sans que la machine n’expose quoi que ce soit elle-même.
- 1Désigner le service interne à publierLa machine du mesh et le port sur lequel écoute le récepteur de webhooks. Le service continue de tourner exactement comme avant, sans modification.
- 2Choisir le nom publicLe domaine ou sous-domaine par lequel le service tiers vous joindra. Sa gestion (propriété, DNS, activation) est décrite dans la documentation des domaines, à /docs/plateforme-domaines.
- 3Laisser la plateforme obtenir le certificatLe certificat TLS est demandé et renouvelé automatiquement pour le nom public — aucun fichier à installer, aucune échéance à surveiller.
- 4Renseigner l'URL chez le service tiersUne fois le nom actif, le reverse-proxy relaie le trafic entrant vers votre récepteur à travers le mesh chiffré. L’URL est durable : elle ne change pas à chaque session de travail, et n’est plus jamais à reconfigurer chez le tiers.