Passer du développement local à la production : Piko, une alternative open-source à ngrok pour Kubernetes

Chaque développeur se souvient de la première fois qu’il a utilisé ngrok : une commande, et un serveur local sur localhost devient accessible depuis Internet public. Pour tester des webhooks, partager une version en cours de développement ou réaliser une intégration rapide, c’est très pratique.

Mais ce même modèle de tunneling inversé fonctionne différemment en production, notamment dans un cluster Kubernetes. Les exigences changent — tolérance aux pannes, scalabilité horizontale, et contrôle total sur votre plan de données, idéalement sans facturation SaaS qui augmente avec l’usage.

C’est là que Piko intervient : un système open-source, basé en Go, de reverse proxy et de tunneling, sous licence MIT, créé par Andy Dunstall et hébergé sur github.com/andydunstall/piko. Sa documentation le décrit simplement comme “une alternative open-source à Ngrok, conçue pour gérer le trafic de production et facile à héberger (notamment sur Kubernetes).”

Fonctionnement du reverse tunneling, et ses limites à grande échelle

L’ingress traditionnel nécessite d’ouvrir un port entrant — vous faites un trou dans votre périmètre pour que l’internet puisse atteindre votre service.

Le reverse tunneling inverse ce processus : votre service interne établit une connexion sortante vers un serveur edge externe, qui redirige ensuite le trafic public via ce tunnel déjà établi. Les connexions sortantes sont presque toujours autorisées par les pare-feux d’entreprise, ce qui évite la configuration NAT, le transfert de ports, et les cycles de revue de sécurité.

Le problème apparaît quand vous utilisez un outil conçu pour un seul développeur sur son ordinateur portable, en le déployant en infrastructure de production dans un cluster :

• Point unique de défaillance — un client tunnel autonome qui plante coupe le trafic jusqu’à ce qu’il redémarre.
• Limites de scalabilité horizontale — équilibrer la charge entre plusieurs clients tunnel connectés simultanément n’est pas prévu pour tous les outils de développement local.
• Résidence des données — sauf si vous utilisez une offre auto-hébergée ou entreprise, le trafic passe par un SaaS tiers, ce qui peut poser problème pour certaines exigences de conformité.
• Coût à grande échelle — la tarification SaaS basée sur la bande passante ou les points d’extrémité augmente linéairement avec votre empreinte.

Ce que fait Piko différemment

Piko n’est pas conçu pour fonctionner en tant que binaire unique sur un laptop — il est pensé pour fonctionner en cluster de nœuds, et sa documentation précise que c’est le but : “conçu pour gérer le trafic de production en tant que cluster de nœuds pour la tolérance aux pannes, la scalabilité horizontale et les déploiements sans interruption.”

Le principe : votre service en amont (ou l’agent Piko qui l’accompagne) ouvre une connexion sortante vers un nœud serveur Piko et enregistre le point de terminaison qu’il écoute. Piko n’ouvre jamais de connexion vers votre service — il ne fait que transférer le trafic via la connexion qu’il a reçue. Cela permet au service de fonctionner n’importe où, sans port exposé ni route publique, tant qu’il peut atteindre le serveur Piko.

Haute disponibilité via gossip

Les pods étant éphémères, Piko est conçu pour fonctionner avec plusieurs nœuds serveurs qui découvrent et partagent l’état du cluster. Si un upstream est connecté au nœud A mais qu’une requête arrive sur le nœud B, ce dernier recherche quel nœud détient la connexion et la transfère en interne.

Pour maintenir la cohérence de la vue “quelle endpoint est connecté où”, Piko utilise un mécanisme anti-entropy basé sur le gossip. Lorsqu’un upstream se connecte ou se déconnecte, cet état se propage dans le cluster — généralement en moins d’une seconde, selon la documentation de Piko, et pas instantanément. Si un nœud échoue ou est déprovisionné, l’upstream concerné se reconnecte à un nœud survivant, et le nouvel état de routage est propagé de la même façon. C’est ce qui permet de faire fonctionner Piko en tant que StatefulSet Kubernetes derrière un load balancer HTTP(S).

Une contrainte opérationnelle importante : la documentation recommande de déployer un seul cluster dans une seule région, réparti sur plusieurs zones de disponibilité — ce qui limite la haute disponibilité multi-régions. Si “haute disponibilité” est un critère clé, cela doit être pris en compte.

Quatre ports, pas un

Un nœud serveur Piko expose quatre ports distincts, chacun avec une fonction spécifique (avec les valeurs par défaut de l’exemple de déploiement Kubernetes de Piko) :

Port	Par défaut	Fonction
Proxy	8000	Reçoit le trafic HTTP(S) des clients en aval et le route vers le bon upstream. Selon votre déploiement, il peut être accessible publiquement ou seulement depuis le même réseau — par exemple, dans une configuration BYOC où le client est votre propre plan de contrôle.
Upstream	8001	Où les services en amont (agents ou SDK Go) se connectent pour enregistrer un endpoint et maintenir leur tunnel sortant ouvert.
Admin	8002	Fournit l’API de statut, les vérifications de santé du cluster/nœud, et un endpoint /metrics pour Prometheus. La documentation précise que ce port ne doit pas être exposé à Internet ; si nécessaire, activer TLS et authentification.
Gossip	8003	Exclusivement entre nœuds. Transporte le protocole gossip pour la découverte de services et la propagation de l’état de routage.

Le port admin exporte nativement des métriques Prometheus, ce qui facilite la création de dashboards Grafana pour la santé et le débit du tunnel, sans instrumentation supplémentaire.

Routage sans DNS wildcard

Lorsqu’une requête arrive sur le port proxy, Piko identifie le endpoint cible via l’en-tête Host (en utilisant le premier segment de sous-domaine — par exemple, foo.piko.example.com vers l’endpoint foo) ou via un en-tête personnalisé x-piko-endpoint, permettant d’éviter la configuration DNS wildcard.

Le trafic TCP ne porte pas d’en-tête, donc pour les tunnels TCP, il faut utiliser piko forward (qui mappe un port TCP local vers un endpoint cible) ou le SDK Go, plutôt que de se connecter directement au serveur.

Authentification

Piko authentifie les clients via un JWT fourni par votre application. Il supporte la signature HMAC, RSA, et ECDSA (HS256/384/512, RS256/384/512, et ES256/384/512), et chaque port — proxy, upstream, admin — peut être configuré avec des paramètres d’authentification indépendants. Un JWT peut contenir une revendication piko pour limiter l’accès à certains endpoints ; si cette revendication est absente, le token donne accès à tous. Piko supporte aussi le mutual TLS, ajouté dans la version v0.6.4, et la vérification de clés JWKS, dans la version v0.8.0, ainsi que l’authentification multi-tenant pour les upstreams.

Bring-Your-Own-Cloud (BYOC)

C’est le cas d’usage que les mainteneurs de Piko mettent en avant explicitement, aux côtés de “exposer des services dans un réseau client” et “connecter des appareils utilisateur.” Il répond à un problème d’entreprise courant : un fournisseur doit gérer et surveiller un logiciel tournant dans le VPC d’un client, sans que la sécurité du client n’ouvre de ports entrants pour une plateforme tierce.

Avec Piko, le fournisseur déploie un cluster Piko central, et un agent léger dans l’environnement du client, qui ouvre une connexion sortante vers le cluster du fournisseur — qui apparaît comme du trafic web sortant ordinaire. Une fois le tunnel établi, le contrôle du fournisseur peut router des requêtes, déclencher des déploiements ou collecter des métriques, sans VPN, peering VPC ou NAT personnalisé par client. (L’exemple “50 clients, 50 revues de sécurité” est illustratif, pas une citation directe.)

Déploiement de Piko

Piko propose un chart Helm dans operations/helm du dépôt, qui crée un Service sans cluster IP et un StatefulSet. La seule exigence pour votre load balancer est la prise en charge de la mise à niveau WebSocket, essentielle pour maintenir les connexions persistantes des agents.

Enregistrer un upstream se fait en une seule commande. L’agent se lie au port local de votre service et ouvre le tunnel :

# Connecte un service local sur le port 4000 au cluster Piko
# sous le nom d'endpoint "my-endpoint"
piko agent http my-endpoint 4000

Le binaire piko gère à la fois le rôle de serveur (piko server) et d’agent (piko agent http|tcp) pour enregistrer un upstream, ainsi que piko forward pour les clients TCP. Les images Docker sont publiées sur ghcr.io/andydunstall/piko.

État actuel du projet

À la date de rédaction, Piko est en version v0.10.0 (sortie le 8 mai 2026), avec un développement actif et progressif depuis deux ans — support mutual TLS (v0.6.4, décembre 2024), rééquilibrage des connexions dans le cluster (v0.7.0, février 2025), JWKS et authentification multi-tenant (v0.8.0, août 2025), arrêt gracieux des clients (v0.9.0, janvier 2026), et gestion configurable de la taille de la fenêtre de flux (v0.10.0, mai 2026).

Deux points importants à considérer avant de faire passer du trafic en production :

• Ce n’est pas encore la version 1.0. La version 0.x n’indique pas une instabilité, mais que l’API n’est pas encore déclarée stable et rétrocompatible.
• Une communauté modeste mais active. À la rédaction, le dépôt compte environ 2 200 étoiles GitHub et 87 forks, et il est listé dans le répertoire communautaire awesome-tunneling — qui, depuis une mise à jour en février 2026, exige au moins 100 étoiles pour l’ajout d’un nouvel outil. Piko dépasse ce seuil, mais reste un projet à mainteneur unique, sans grande équipe.

ngrok vs. Piko : où chacun trouve sa place

ngrok n’est pas obsolète, et rien dans cet article ne suggère qu’il le devrait pour ses cas d’usage cibles. Pour un développeur testant un webhook Stripe en local, partageant une version avec un client, ou souhaitant que le trafic DDoS soit absorbé par un edge tiers, l’expérience managée de ngrok reste imbattable.

La différence se joue dans l’infrastructure Kubernetes en production — notamment pour l’ingress BYOC, les environnements avec contraintes de résidence des données, ou les services internes à fort trafic où un edge tiers n’est pas une option. Pour ces cas, Piko offre la forme opérationnelle d’un tunnel inversé avec une architecture native à un cluster que vous hébergez et contrôlez, au prix de gérer et faire fonctionner ce cluster — et d’utiliser un projet encore en pré-1.0 plutôt qu’un produit mature.

---

Vérification et changelog

Vérifié avec le dépôt officiel GitHub, le wiki, et les notes de version (liens ci-dessous).

• Correction du délai de propagation. La version initiale indiquait une propagation “en millisecondes”. Le wiki de Piko précise que les mises à jour de routage sont “habituellement” propagées “en moins d’une seconde” — correction apportée. (Comment fonctionne Piko)
• Affinement de la mention de failover. La version initiale parlait d’une reconnexion “instantanée” en cas de défaillance d’un nœud. La documentation indique une reconnexion automatique à un nœud survivant sans donner de délai précis — suppression de la mention “instantanée” non supportée.
• Ajout des numéros de ports exacts. La version initiale décrivait quatre ports sans valeurs. Confirmation et ajout des valeurs par défaut (8000/8001/8002/8003) issues de l’exemple de déploiement Kubernetes. (Server Kubernetes)
• Avertissement sur la sécurité du port admin. La documentation précise que le port admin “ne doit pas être exposé à Internet” ; si nécessaire, activer TLS et authentification — cette recommandation spécifique n’était pas dans la version initiale. (Server)
• Vérification et précision du support JWT. Confirmation que Piko supporte la signature JWT HMAC, RSA, et ECDSA avec configuration par port et revendications optionnelles de scope piko, plutôt qu’une mention générique “authentification JWT”. (Authentication)
• Support mTLS confirmé et daté. Ajout du support mutual TLS, introduit dans la version v0.6.4 (décembre 2024). (Releases)
• Vérification du chart Helm. Confirmation que le chart existe dans operations/helm et crée un Service sans cluster IP + StatefulSet. (Server Kubernetes)
• Cas d’usage BYOC confirmé comme officiel. La wiki de Piko liste explicitement “un service BYOC” comme cas d’usage. (What Is Piko?)
• Contexte de maturité du projet. Version actuelle (v0.10.0, mai 2026), versionnement pré-1.0, communauté modeste (~2 200 étoiles, 87 forks), validation par la liste awesome-tunneling (avec seuil de 100 étoiles). (Releases, awesome-tunneling)
• Limite d’une seule région. La documentation recommande un déploiement dans une seule région, ce qui limite la haute disponibilité multi-régions. (Server)
• Clarification du routage TCP. Explicitement indiqué que les tunnels TCP nécessitent piko forward ou le SDK Go, car TCP brut n’a pas d’en-tête pour identifier l’endpoint cible. (What Is Piko?)
• Suppression des artefacts SEO/IA : retrait des superlatifs non vérifiables (“la référence”, “brillant”, “l’industrie pivote”) et de tout métadonnées non pertinentes pour un lectorat technique.