Postgres sur RDS, Redis derrière un bastion, une VM Google Cloud sans adresse publique. Kestro lit votre ~/.ssh/config, devine le reste et ouvre la porte d’un interrupteur. Le soir, « Tout fermer » les referme toutes. Et vous n’avez pas eu un terminal de plus à surveiller.
macOS 11+ · Windows bientôt
Les tunnels
Un bastion devant la base, et la ligne devient illisible : un saut, un port local, une clé par machine. Kestro reprend vos entrées ~/.ssh/config telles qu’elles sont (le rebond, l’utilisateur, la clé) et n’en fait qu’un interrupteur.
Cloud SQL, une VM Google, une instance EC2 par Session Manager : Kestro s’appuie sur vos outils gcloud et aws déjà authentifiés. Il vous liste ce qu’il trouve dans votre projet, vous choisissez la ligne.
Cochez la reconnexion sur un tunnel : un capot refermé, un changement de Wi-Fi ou un VPN qui repart ne le tuent plus. Il revient sur le même port local, et le favori de votre client SQL reste valable. Éteint par défaut : une porte vers la production ne se rouvre pas sans qu’on l’ait demandé.
Chaque tunnel porte son environnement, et la ligne de production un liseré rouge. On voit vers quoi on ouvre avant de cliquer, et le compte des portes ouvertes dit combien sont en production.
kestro with notes-db -- npm run migrate ouvre le tunnel, attend qu’il réponde vraiment, puis lance la commande dans ce terminal-ci. psql "$(kestro url notes-db)" se glisse dans une phrase qu’aucune interface n’écrira à votre place.
Kestro est un serveur MCP : demandez la préprod à Claude ou à Cursor, le tunnel s’ouvre. Un tunnel marqué « prod » reste visible sans son hôte, sans son instance et sans son port, il sait qu’il existe, il n’a rien à ouvrir. Le reste tient dans des interrupteurs, et ce qui est fermé se demande au moment du geste.
Fonctionne avec ce que vous avez déjàSSH · Google Cloud · AWS · Cloudflare · Docker · PostgreSQL · Redis · Git
D’une adresse à une porte ouverte
Il ne remplace ni SSH ni gcloud : il s’en sert. Rien à reconfigurer, rien à recopier dans une base à lui, rien à nettoyer le jour où vous le désinstallez.
Un hôte de votre ~/.ssh/config, une instance Cloud SQL en projet:région:instance, un identifiant EC2. Kestro reconnaît la forme, remplit le port et devine l’environnement à partir du nom.
Le port local est-il libre ? Il le dit pendant que vous remplissez la fiche, pas trois minutes plus tard dans un journal. Un tunnel annoncé « ouvert » est un tunnel où quelque chose a répondu.
Sur les tunnels où vous l’avez demandé : reconnexion au réveil de la machine et au retour du réseau, avec le compte des relances sous les yeux. Ce n’est pas un terminal qu’on découvre mort une heure plus tard.
Aucune porte ne se referme dans votre dos : un tunnel qui disparaît pendant qu’un transfert tourne serait pire que le problème qu’il résout. « Tout fermer » les referme toutes d’un geste, et le compte de ce qui est ouvert reste dans la barre de menus.
Sur votre machine
Vos connexions vont de votre poste à vos serveurs, sans passer par nous.
Rien à créer, aucun mot de passe.
SSH, Google Cloud, AWS : Kestro se sert de vos outils, sur place.
Nous ne savons pas ce que vous ouvrez, ni quand.
La licence se renouvelle chez nous. Rien d’autre ne sort.
Et le reste
Il tient tout ce que vous laissiez tourner dans les autres onglets de terminal. C’est le même panneau, le même raccourci, le même prix.
La branche, ce qui a bougé, ce qui reste à pousser. Et le serveur de dev, ou le compose, lancé depuis la ligne.
Sites, API, ports : vérifiés en continu depuis votre poste. Dès que l’un tombe, l’icône change dans la barre de menus.
npm, make, docker : épinglés, lancés d’un raccourci, avec leur sortie dans le panneau plutôt que dans une fenêtre de plus.
Prix
Un outil qu’on ouvre quarante fois par jour ne devrait pas envoyer une facture tous les mois.
Licence Kestro
1 ordinateur · paiement unique
Ou télécharger gratuitement d’abord →
Remboursé sous 14 jours, sans question posée.
Questions qu’on nous pose
Non, il le lit. Vos hôtes, vos rebonds, vos clés et vos utilisateurs restent là où ils sont et restent la référence : Kestro les emprunte tels quels. Rien n’est recopié dans une base à lui, rien n’est réécrit dans votre fichier, et le jour où vous désinstallez Kestro vous n’avez rien à nettoyer : votre ssh continue de fonctionner exactement comme avant.
C’est le cas courant, pas l’exception. Si votre configuration décrit déjà le rebond, Kestro l’emprunte ; sinon vous désignez la machine de rebond dans la fiche du tunnel et il monte les deux sauts. Le seul port que vous voyez ensuite est le port local, celui que vous donnez à votre client.
Non. Kestro n’en copie aucune et n’en stocke aucune : il lance ssh comme vous le feriez, avec votre agent et vos clés en place. Pour Google Cloud et AWS, il passe par gcloud et aws, déjà authentifiés sur votre poste. Tout s’ouvre directement entre votre machine et vos serveurs : rien ne transite par nos infrastructures, et comme il n’y a aucun compte, nous ne savons même pas que vous ouvrez un tunnel.
Kestro le voit pendant que vous remplissez la fiche et vous le dit à cet instant-là : « libre » ou « déjà pris », sous le champ. Vous en choisissez un autre en une frappe, plutôt que de découvrir une erreur de liaison après coup. Le port retenu s’affiche sur la ligne du tunnel, et c’est celui que kestro url renvoie.
Autant que votre machine en supporte. « Tout ouvrir » les monte d’un geste, chacun avec sa propre connexion et sa propre transition. Le matin, c’est un clic pour la journée. Le bouton se retourne en « Tout fermer » quand il ne reste plus rien à ouvrir, pour qu’il n’y ait jamais deux boutons à départager.
Oui : ce sont des bases derrière un réseau privé, et c’est exactement ce qu’un tunnel traverse. Cloud SQL par son instance, une VM Google par son nom, une EC2 par Session Manager, une base derrière un bastion par le rebond que décrit déjà votre configuration SSH.
Non, et il ne demande pas non plus de compte. Vous téléchargez, vous avez 7 jours complets. Aucune carte n’est demandée avant que vous décidiez d’acheter.