Cave : des environnements isolés pour faire tourner des agents de code sur son serveur

https://withcave.ai/docs/get-started/what-is-cave

📌 Cave sert à exécuter des agents IA de dev dans des environnements isolés, sur une machine que l’on contrôle, tout en gardant une interface web et des accès pratiques (mobile, SSH, terminal).

Lancer un agent directement sur un laptop, c’est souvent le plus rapide… jusqu’au moment où il faut lui donner accès à tout le système, où la session s’arrête dès que l’ordinateur se met en veille, ou où l’on hésite à laisser tourner des tâches longues en arrière-plan. À l’inverse, confier ces agents à une plateforme partagée soulève tout de suite des questions de confidentialité et de contrôle, surtout dès qu’il s’agit de dépôts privés, de clés, de secrets ou de données de test.

Cave se positionne comme une troisième voie : des « sandboxes » isolées, hébergées sur un serveur à soi, dans lesquelles les agents continuent de travailler même quand l’ordinateur client est fermé. L’idée centrale n’est pas seulement d’“avoir un shell à distance”, mais d’avoir un environnement reproductible, dédié à un repo, avec des capacités orientées agent (exécuter, installer, tester, démarrer des services) et des points de contrôle pour repartir vite.

Dans la pratique, un Cave correspond à un environnement isolé associé à un dépôt. On lance une session, l’agent agit dans ce périmètre, et l’on se connecte comme on veut : depuis un tableau de bord web sur desktop, depuis un téléphone pour “checker” l’avancement, ou directement en SSH/terminal quand il faut reprendre la main. Ce modèle est particulièrement utile pour les tâches qui durent (indexations, migrations, grosses suites de tests, builds) ou pour les itérations agent où l’on veut garder un état stable sans reconfigurer sa machine.

Points clés

• 🧱 Environnements isolés par projet, exécutés sur un serveur contrôlé
• ⏱️ Sessions qui persistent et continuent sans laptop allumé
• 🧪 Un agent peut installer, lancer des tests et démarrer des services dans le bac à sable
• 🧭 Accès multi‑interfaces : web (desktop/mobile) + SSH + terminal
• 📦 Checkpoints : capturer un environnement prêt, puis relancer en quelques secondes
• 🐳 Support Docker dans les Caves pour docker-compose et services annexes
• 🔌 Tunnel de ports automatique pour accéder à un dev server localement
• 🛡️ Contrôle réseau (beta) via allowlist et demandes d’autorisation en temps réel

Un point important est l’outillage “agent-first” dans l’interface. Cave embarque un harness d’agent intégré, basé sur OpenCode, un agent de code open source accessible depuis l’UI web. Concrètement, cela évite de bricoler un empilement hétérogène (un terminal pour lancer l’agent, une autre fenêtre pour suivre les logs, un client SSH pour corriger à la main) : l’interaction avec l’agent et la supervision de plusieurs environnements se fait dans une UI unifiée.

La notion de “plusieurs Caves en parallèle” est aussi un bénéfice concret. Plutôt que de lancer des agents qui se partagent un même filesystem ou une même configuration locale, chaque session garde son contexte. Ouvrir plusieurs Caves en volets (split panes) permet d’avancer sur des chantiers différents sans mélanger les dépendances, sans casser une branche par effet de bord, et sans perdre l’état quand on passe à autre chose. C’est un pattern simple mais très efficace dès que l’on itère sur plusieurs PR, ou que l’on veut comparer deux approches (refactor vs patch minimal) en parallèle.

Les checkpoints jouent un rôle de “boîte noire reproductible”. Quand un environnement est enfin prêt (dépendances installées, services configurés, variables en place), l’enregistrer comme checkpoint évite de retomber dans la phase d’amorçage à la création suivante. Avec l’auto-build, un nouveau checkpoint peut être produit automatiquement quand des commits arrivent dans le dépôt, ce qui rend l’ouverture d’un Cave plus proche d’un “clic pour obtenir un environnement prêt” que d’un setup manuel.

Cave prévoit aussi une voie de provisioning personnalisée : ajouter un script provision.sh au dépôt pour installer des dépendances, configurer des outils, initialiser une base de données, ou préparer un jeu de données minimal. L’intérêt n’est pas seulement l’automatisation : c’est la standardisation. Deux personnes (ou deux sessions agent) peuvent obtenir le même environnement sans divergence de versions, sans dépendre d’un état local non documenté.

Côté exécution d’applications, le tunneling de ports vise à réduire les frictions. Si un agent démarre un serveur web de dev dans un Cave, le CLI peut détecter le port et le rendre accessible localement via un tunnel. On ouvre ensuite le navigateur comme si l’app tournait sur la machine, tout en gardant l’exécution isolée côté serveur. Pour du debug de front/back, des outils internes, ou des previews temporaires, c’est souvent le détail qui fait gagner du temps.

La question confidentialité/maîtrise se traite aussi par le réseau. Le contrôle réseau (annoncé en beta) repose sur une allowlist configurable : si l’agent tente de joindre un hôte non autorisé, une notification apparaît et l’autorisation peut être donnée au cas par cas depuis l’interface. L’objectif est double : limiter l’exfiltration involontaire et rendre visibles les accès sortants, sans passer par des fichiers de config opaques ou des redémarrages.

Démarrer avec Cave repose sur l’installation d’un serveur Cave sur sa propre infrastructure. Les docs mettent en avant une mise en route guidée via la CLI : un “single command” qui propose deux modes, soit une configuration publique avec un domaine, soit une configuration privée via un réseau Tailscale. Une fois le serveur en place, on crée un Cave à partir d’un dépôt, l’environnement est préparé, puis on ouvre une session agent dans l’interface.

À retenir : Cave vise surtout les workflows où l’on veut des agents utiles et actionnables, mais enfermés dans un périmètre clair, persistant, et reproductible. Quand il faut laisser un agent travailler longtemps, en parallèle de plusieurs chantiers, tout en conservant la maîtrise de l’infrastructure et de la surface réseau, ce modèle “sandboxes sur serveur contrôlé” devient une option très pragmatique.