ngrok vs. sish (Le Serveo auto-hébergé) : Comment créer votre propre ngrok privé avec sish et un VPS à 5$

Dans le développement logiciel moderne, exposer votre environnement de développement local à Internet est une nécessité quotidienne. Que vous testiez des webhooks, présentiez un travail en cours à un client, ou déboguiez une intégration API complexe, vous avez besoin d’un tunnel fiable. Pendant des années, les développeurs utilisaient des outils tiers comme ngrok ou Serveo. Cependant, à mesure que la taille des équipes augmente et que les exigences de sécurité se renforcent, s’appuyer sur des services de tunneling gérés peut entraîner des goulots d’étranglement, des coûts et des problèmes de conformité sécuritaire.

Si les limites de la version gratuite de ngrok, la limitation de débit, ou l’imprévisibilité de la disponibilité des alternatives gratuites comme Serveo vous ont frustré, il est peut-être temps de prendre le contrôle de votre infrastructure. Découvrez sish, une alternative open-source, activement maintenue, qui vous permet de créer votre propre version privée de localhost.run ou Serveo — ou, depuis cette année, d’utiliser simplement son service géré officiel au lieu de l’auto-hébergement.

Dans ce guide, nous passerons en revue l’état actuel du tunneling SSH, comparerons ngrok et sish de manière précise en nous basant sur la documentation de chaque projet, et fournirons un tutoriel étape par étape pour déployer votre propre ngrok privé avec sish et un VPS à 5$.

---

L’évolution du tunneling localhost

La domination de ngrok

Lorsque les développeurs pensent au tunneling localhost, ngrok est généralement le premier nom qui vient à l’esprit. Il a révolutionné la façon dont nous exposons des serveurs locaux. En exécutant une simple commande (ngrok http 8080), vous recevez instantanément une URL HTTPS publique redirigeant le trafic vers votre machine locale.

Le plan gratuit de ngrok est réellement limité, mais pas de la manière décrite dans la plupart des articles de comparaison. Selon la documentation officielle de ngrok sur les limites et tarifs, le plan gratuit inclut :

• Un crédit d’utilisation unique de 5$
• Jusqu’à 3 points de terminaison en ligne et 3 agents simultanés
• 1 Go de transfert de données par mois
• 20 000 requêtes HTTP/S par mois, plafonnées à environ 4 000 requêtes/minute
• 5 000 connexions TCP/TLS par mois
• Un “domaine de développement” attribué automatiquement (ex. your-name.ngrok-free.app)
• Une page d’avertissement affichée aux visiteurs du navigateur sur les points de terminaison HTTP/S gratuits (pouvant être contournée en envoyant un en-tête ngrok-skip-browser-warning ou un User-Agent non par défaut — aucune mise à niveau requise)

Une idée reçue à corriger : beaucoup de blogs marketing prétendent que le plan gratuit de ngrok impose désormais un timeout de session de 2 heures. La documentation officielle de ngrok contredit directement cela — les points de terminaison du plan gratuit n’ont pas de timeout et peuvent fonctionner indéfiniment en tant que service en arrière-plan. Les contraintes réelles sont les plafonds mensuels de données, requêtes et connexions mentionnés ci-dessus, ainsi que l’impossibilité de réserver un domaine personnalisé et la page d’interstitiel. Méfiez-vous de tout article évoquant une “limite de 2 heures”.

Les plans payants ont également été restructurés. La gamme actuelle (d’après la page de tarification et limites de ngrok) est :

Plan	Prix	Transfert de données	Requêtes	Points de terminaison
Gratuit	0$	1 Go/mois	20k/mois	3
Hobbyiste	8$/mois (annuel) ou 10$/mois	5 Go/mois	100k/mois	3
Pay-as-you-go	20$/mois de base (inclut 20$ de crédit d’utilisation)	Facturé selon usage (0,10$/Go)	Facturé selon usage (1/100k)	Illimité
Entreprise	Sur devis	Sur devis	Sur devis	Sur devis

Au-delà du coût, certains réseaux d’entreprise restreignent ou signalent le trafic ngrok par défaut, car ses domaines partagés ont été abusés pour du phishing et des commandes de malware — un problème de sécurité indépendant des prix.

La montée et la chute de Serveo

En alternative à l’agent propriétaire de ngrok, les développeurs se sont tournés vers Serveo. Serveo était notable car il ne nécessitait aucune installation — il exploitait le client SSH standard déjà installé sur presque toutes les machines de développeurs. En exécutant ssh -R 80:localhost:8080 serveo.net, il renvoyait instantanément une URL publique.

Serveo est devenu une solution privilégiée pour le tunneling SSH gratuit, mais sa nature ouverte et non authentifiée en faisait une cible pour le phishing et l’abus de malware. Cela a conduit à des listes noires récurrentes et à des interruptions. La disponibilité de Serveo aujourd’hui reste incohérente — les moniteurs de disponibilité tiers montrent qu’il oscille entre “en ligne” et “hors ligne” selon la région et le moment, ce qui correspond à un service gratuit peu maintenu plutôt qu’à une solution fiable. Il reste accessible de façon intermittente, mais il ne faut pas en dépendre pour des environnements de production ou proches.

Entrée de sish : le successeur open-source

sish, créé par le développeur Antonio Mika, est la réponse de la communauté open-source à la lacune laissée par Serveo. C’est un projet activement maintenu — actuellement en version v2.23.0 (juin 2026), avec environ 4,6k étoiles GitHub, 329 forks, et 64 versions taguées — et il est désormais sponsorisé par pico.sh, le projet d’outils pour développeurs basé sur SSH que Mika maintient également.

Contrairement à Serveo, qui n’était qu’un service public, sish est explicitement conçu pour être auto-hébergé sur votre propre infrastructure. Il fonctionne comme un serveur SSH qui redirige le trafic vers les clients connectés.

Une mise à jour importante depuis ses débuts : vous n’avez plus besoin de l’auto-héberger si vous ne souhaitez pas. Le projet propose désormais un service géré officiel à tuns.sh, maintenu par la même équipe, pour tester sish rapidement sans VPS :

ssh -R 80:localhost:8080 tuns.sh

Cela crée instantanément une URL publique pour une application tournant sur le port local 8080 — sans inscription, sans installation client. L’auto-hébergement reste préférable pour les équipes nécessitant des domaines personnalisés, des tunnels privés ou un contrôle total sur la résidence des données, ce que couvre le reste de ce guide.

La superpuissance de sish

Qu’est-ce qui distingue sish dans le domaine saturé des outils de tunneling ?

1. Support des protocoles : sish gère HTTP, HTTPS, TCP, WS (WebSockets), et WSS, ainsi que le routage TLS basé sur SNI sans terminer la connexion TLS.
2. Pas d’installation client : comme Serveo, sish utilise le client SSH natif (ssh -R). Votre équipe n’a pas besoin d’outils CLI propriétaires ou d’agents.
3. Certificats TLS : sish peut servir du HTTPS avec des certificats fournis par vous-même, ou en en demandant automatiquement via Let’s Encrypt (--https-ondemand-certificate), ou — si vous utilisez le déploiement Docker officiel — avec des certificats wildcard automatisés via DNS-01 grâce au conteneur dnsrobocert intégré.
4. Multiplexage : sish supporte les sous-domaines génériques, permettant à plusieurs développeurs de demander leurs propres sous-domaines à la volée (ex. dev1.votredomaine.com, api-test.votredomaine.com).
5. Sécurité et authentification, activées par défaut : à partir de la version courante, sish nécessite une authentification SSH (clé publique ou mot de passe) — ce n’est plus un outil “ouvert par défaut, à sécuriser plus tard”. Vous configurez qui peut accéder avant d’ouvrir un tunnel.
6. Alias TCP privés et équilibrage de charge : au-delà des tunnels publics, sish supporte des alias TCP internes (accessibles uniquement via un saut SSH authentifié), ainsi que des modes d’équilibrage de charge pour que plusieurs clients partagent le même point de terminaison HTTP, TCP ou SNI.
7. Inspection du trafic : une console d’administration optionnelle et un service de console par tunnel vous permettent d’inspecter les requêtes redirigées — réduisant l’écart avec l’inspecteur de trafic ngrok, sans faire transiter votre trafic par un tiers.

---

ngrok vs. sish : lequel choisir ?

Fonctionnalité	ngrok (SaaS)	sish (auto-hébergé ou géré)
Architecture	Service tiers géré	Auto-hébergé sur votre infrastructure, ou utilisez le service géré tuns.sh
Logiciel client	Nécessite l’agent CLI ngrok	Utilise SSH natif (ssh)
Domaines personnalisés	Nécessite le plan Hobbyiste ou supérieur	Gratuit en auto-hébergement ; apportez votre propre domaine
Coût	Gratuit (limité) jusqu’à 20$/mois + usage	VPS à ~5$/mois + domaine, ou gratuit via tuns.sh pour tests rapides
Confidentialité des données	Trafic via le cloud ngrok	Trafic via votre propre VPS (auto-hébergé)
Limites de débit	1Go/20k requêtes (gratuit), 5Go/100k (Hobbyiste), facturation au-delà	Aucune limite inhérente à sish, dépend uniquement de votre bande passante VPS
Timeout de l’endpoint	Aucun (une idée reçue dit le contraire)	Aucun
Authentification par défaut	Compte (SaaS)	Auth SSH (clé ou mot de passe) requise par défaut depuis les dernières versions
Temps de configuration	Instantané	Instantané via tuns.sh ; environ 15–30 minutes pour auto-héberger un VPS
Maintenance	Aucune (gérée pour vous)	Minimale (mises à jour OS et conteneurs) pour auto-hébergé ; aucune pour tuns.sh

Quand choisir ngrok : vous souhaitez une expérience complète, gérée, avec inspection du trafic intégrée, et vous ne craignez pas les plafonds de données/requêtes du plan gratuit, ou vous avez besoin de fonctionnalités d’entreprise comme SSO et logs d’audit.

Quand choisir sish : vous avez une équipe qui veut des sous-domaines persistants sans frais SaaS, vous gérez des données qui ne doivent pas transiter par un tiers, ou vous souhaitez une bande passante illimitée limitée uniquement par votre VPS.

---

Comment créer votre propre ngrok privé avec sish et un VPS à 5$ ?

Prérequis

1. Un VPS cloud : une instance basique à 5$/mois chez DigitalOcean, Linode, Vultr ou Hetzner suffit. Choisissez Ubuntu 22.04 LTS ou 24.04 LTS.
2. Un nom de domaine (ex. my-tunnels.com) pour router le trafic vers votre VPS.
3. Connaissances de base en terminal, SSH et ligne de commande.
4. Votre clé SSH publique locale (habituellement ~/.ssh/id_ed25519.pub) — vous en aurez besoin dès le départ, car sish requiert maintenant une authentification dès le début.

Étape 1 : Configurer vos enregistrements DNS

Pour que sish route dynamiquement le trafic vers différents sous-domaines, créez un enregistrement DNS générique. Dans le panneau DNS de votre registrar, créez deux enregistrements A pointant vers l’IP publique de votre VPS :

1. Enregistrement principal : Host my-tunnels.com (ou @) → IP de votre VPS
2. Enregistrement générique : Host *.my-tunnels.com → IP de votre VPS

La propagation DNS peut prendre de quelques minutes à plusieurs heures.

Étape 2 : Préparer votre VPS (installer Docker)

Connectez-vous en SSH à votre VPS :

ssh root@votre_ip_vps

Mettez à jour les paquets :

sudo apt update && sudo apt upgrade -y

Installez Docker via le script officiel :

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
docker --version

Étape 3 : Déployer sish, sécurisé dès le départ

Les guides plus anciens proposaient de déployer avec l’authentification désactivée puis de la sécuriser plus tard. Ce n’est plus recommandé — les versions récentes de sish requièrent une authentification SSH par défaut, donc la configuration sécurisée et la configuration de base sont désormais identiques.

Créez les répertoires nécessaires et copiez votre clé publique avant de lancer le conteneur :

mkdir -p ~/sish/ssl ~/sish/keys ~/sish/pubkeys
cp ~/.ssh/id_ed25519.pub ~/sish/pubkeys/

Tirez la dernière image et lancez-la, en remplaçant votre domaine :

docker pull antoniomika/sish:latest

docker run -itd --name sish \
  --restart always \
  -v ~/sish/ssl:/ssl \
  -v ~/sish/keys:/keys \
  -v ~/sish/pubkeys:/pubkeys \
  --net=host antoniomika/sish:latest \
  --ssh-address=:2222 \
  --http-address=:80 \
  --https-address=:443 \
  --https=true \
  --https-certificate-directory=/ssl \
  --authentication-keys-directory=/pubkeys \
  --private-keys-directory=/keys \
  --bind-random-ports=false \
  --domain=my-tunnels.com

Quelques notes sur ces options : * --net=host lie directement le conteneur aux interfaces réseau de l’hôte pour une journalisation précise des IP clients. * --ssh-address=:2222 évite de conflit avec le daemon SSH du VPS sur le port 22. * --authentication-keys-directory=/pubkeys indique à sish où surveiller les clés autorisées ; il recharge automatiquement quand vous ajoutez ou retirez des fichiers, sans redémarrage. * --bind-random-ports=false permet aux clients de demander des ports TCP spécifiques plutôt que d’en recevoir un aléatoire. * Ce déploiement de base suppose que vous avez déjà des certificats dans /ssl (par exemple via certbot). Si vous souhaitez que sish récupère ses certificats Let’s Encrypt à la demande, ajoutez --https-ondemand-certificate --https-ondemand-certificate-accept-terms. Pour des certificats wildcard entièrement automatisés via DNS-01, utilisez le déploiement Docker Compose officiel de sish, qui inclut le conteneur dnsrobocert pour cela.

Vérifiez les logs pour confirmer un démarrage correct :

docker logs -f sish

Étape 4 : Tester votre nouveau ngrok privé

Depuis votre machine locale — pas le VPS — avec un serveur local tournant sur le port 3000 :

ssh -p 2222 -R 80:localhost:3000 my-tunnels.com

Étant donné que votre clé publique est déjà approuvée, la connexion est immédiate et retourne une URL HTTPS comme :

Appuyez sur Ctrl-C pour fermer la session.
Redirection vers :
https://randomstring.my-tunnels.com

Demander un sous-domaine personnalisé

ssh -p 2222 -R custom-name:80:localhost:3000 my-tunnels.com

Cela tente de lier https://custom-name.my-tunnels.com, tant que ce sous-domaine n’est pas déjà pris par un autre utilisateur sur votre serveur.

Gérer l’accès des développeurs

Comme le répertoire pubkeys est surveillé en continu, ajouter ou retirer l’accès d’un collègue se fait simplement par une opération sur un fichier — pas besoin de redémarrer :

nano ~/sish/pubkeys/nouveau_membre.pub
# collez leur clé publique, sauvegardez

Une méthode pratique pour l’intégration via des clés hébergées sur GitHub :

curl https://github.com/leur-utilisateur-github.keys  ~/sish/pubkeys/leur-utilisateur-github

---

Cas d’usage avancés de sish

1. Contourner les pare-feux avec des tunnels TCP

sish ne se limite pas à HTTP/HTTPS. Pour exposer une instance locale de MySQL (port 3306) à un client distant :

ssh -p 2222 -R 3306:localhost:3306 my-tunnels.com

Votre client distant se connecte à my-tunnels.com:3306 et le trafic est routé en toute sécurité vers votre base locale.

2. Alias TCP privés (aucune exposition publique)

Pour des accès qui ne doivent pas être exposés à Internet même derrière une authentification, sish supporte des alias TCP accessibles uniquement via un saut SSH authentifié — rien n’est lié publiquement :

ssh -p 2222 -R mylaptop:22:localhost:22 my-tunnels.com

Un collègue avec accès peut alors y accéder via :

ssh -J my-tunnels.com mylaptop

3. Intégration à l’échelle de l’équipe

Standardisez la commande de tunnel dans le package.json ou le Makefile de votre équipe :

"scripts": {
  "start": "react-scripts start",
  "tunnel": "ssh -p 2222 -R $(whoami)-dev:80:localhost:3000 my-tunnels.com"
}

Quand Alice exécute npm run tunnel, elle obtient alice-dev.my-tunnels.com ; Bob obtient bob-dev.my-tunnels.com.

4. Tests CI/CD

Puisque sish ne nécessite qu’un client SSH standard, il est simple à intégrer dans GitHub Actions ou GitLab CI — déployez une instance temporaire, tunnellez-la via votre serveur sish, et exécutez des tests de bout en bout avant de la détruire.

5. Équilibrage de charge et routage SNI

Si votre cas d’usage dépasse le tunnel d’un seul développeur, les modes d’équilibrage de charge optionnels de sish (--http-load-balancer, --tcp-load-balancer, --sni-load-balancer) permettent à plusieurs clients de partager le même domaine, port ou SNI — pratique pour une tolérance de panne basique sans déployer un load balancer séparé.

---

Résumé

La finition et les outils d’inspection du trafic de ngrok restent très utiles, et son plan gratuit — bien que plafonné en données et requêtes, pas en durée de session — est une bonne option pour tester. Mais pour les équipes qui veulent du contrôle, de la confidentialité des données, et des coûts prévisibles, l’auto-hébergement est devenu plus simple, pas plus compliqué : sish est désormais sécurisé par défaut, propose une option gérée tuns.sh pour tester sans configuration, et a enrichi ses fonctionnalités (alias TCP, proxy SNI, équilibrage, consoles de trafic) pour réduire l’écart avec les plateformes de tunneling commerciales.

En investissant environ 5$ par mois et 20 minutes de configuration, vous pouvez faire fonctionner un serveur de tunneling privé, personnalisé, et contrôlé par votre équipe.

---

Journal des modifications

Cet article a été réécrit à partir d’un brouillon soumis et vérifié le 18 juillet 2026.

Corrections : 1. Suppression complète de l’affirmation selon laquelle le plan gratuit de ngrok impose un timeout de session de 2 heures et ajout d’une correction explicite. La documentation officielle de ngrok indique que les points de terminaison du plan gratuit n’ont pas de timeout et peuvent fonctionner indéfiniment en arrière-plan ; les limites concernent uniquement les plafonds mensuels de données, requêtes et connexions. Source : ngrok.com/docs/pricing-limits/free-plan-limits. 2. Mise à jour de la structure tarifaire de ngrok, qui dans le brouillon initial était décrite de manière générale. Les plans actuels selon la documentation officielle : Gratuit (0$, crédit unique de 5$, 3 points de terminaison, 1Go/20k requêtes), Hobbyiste (8$/mois annuel ou 10$/mois, 5Go/100k requêtes, 3 points de terminaison), Pay-as-you-go (20$/mois de base avec crédit de 20$, endpoints illimités, facturation au-delà), Entreprise (sur devis). Source : ngrok.com/docs/pricing-limits. 3. Correction de la procédure de déploiement Docker de sish. La méthode précédente (déploiement avec --authentication=false puis sécurisation ultérieure) n’est plus recommandée — les versions récentes de sish requièrent une authentification SSH par défaut, donc la configuration sécurisée doit se faire dès le départ. La démarche a été restructurée pour placer la clé publique dans ~/sish/pubkeys avant le premier lancement plutôt que de déployer un relais ouvert. 4. Mise à jour de la commande Docker pour correspondre à l’exemple officiel actuel, ajoutant les flags --private-keys-directory=/keys et --bind-random-ports=false qui n’étaient pas présents dans le brouillon initial. Source : github.com/antoniomika/sish (README) et docs.ssi.sh/getting-started. 5. Correction de la mention d’automatisation Let’s Encrypt. La version déployée via Docker standard ne fournit pas automatiquement des certificats Let’s Encrypt — elle attend que vous ayez déjà des certificats dans /ssl, sauf si vous ajoutez le flag --https-ondemand-certificate ou utilisez le déploiement Docker Compose officiel, qui inclut le conteneur dnsrobocert pour la gestion automatique des certificats wildcard DNS-01. Source : docs.ssi.sh/getting-started.

Ajouts (non présents dans le brouillon initial) : 6. Inclusion du service géré officiel tuns.sh comme option sans VPS pour tester sish rapidement. 7. Statut actuel du projet : version v2.23.0 (juin 2026), environ 4,6k étoiles GitHub, 329 forks, 64 versions, sponsorisé par pico.sh. Source : github.com/antoniomika/sish. 8. Fonctionnalités avancées : alias TCP privé (accès SSH via saut), modes d’équilibrage de charge (--http-load-balancer, --tcp-load-balancer, --sni-load-balancer) pour partage de domaine/port/SNI. 9. Ajout de la console d’administration pour inspection du trafic, en parallèle de ngrok. 10. La disponibilité de Serveo est désormais intermittente selon les moniteurs tiers, plutôt qu’un état de panne constant, reflétant sa maintenance limitée. Source : monitors tiers (isitdownorjustme.net, notopening.com), vérifié en juillet 2026.