Pods

Les Pods sont des environnements de développement cloud isolés et à la demande que vos membres lancent depuis l'espace de travail — une machine Linux complète avec un véritable terminal, un agent de codage IA (Claude Code) et vos outils préinstallés. Chaque pod s'exécute dans son propre bac à sable sécurisé, reste actif malgré les déconnexions et conserve son espace de travail entre les sessions.

En tant qu'administrateur d'organisation, vous décidez quels pods vos membres peuvent lancer, et vous pouvez ajouter vos propres pods personnalisés adaptés à votre stack.

Agentic Pods dans le Control Center : disponibilité, pods personnalisés, limites de dépenses et déploiements.

Deux types de pods

• Pods système — fournis et maintenus par SkyDeck, disponibles pour toutes les organisations. Le principal est Claude Code : un pod de codage avec la CLI GitHub, Claude Code (claude), tailscale, un volume persistant /workspace et un terminal tmux. Vous choisissez d'exposer ou non les pods système à vos membres, et à qui.
• Pods personnalisés — créés par votre organisation (une image contenant vos propres dépôts, chaînes d'outils et outils, ou une base SkyDeck accompagnée d'un dépôt à cloner). Les pods personnalisés ne sont disponibles qu'au sein de votre organisation et peuvent être limités à des groupes spécifiques.

Ce que contient un pod

Chaque pod de codage part de la base SkyDeck ; il dispose donc toujours d'un terminal fonctionnel :

• Ubuntu Linux avec git, tmux et un shell interactif
• la CLI GitHub (gh)
• Claude Code (claude) — exécutez claude pour démarrer l'agent, claude update pour le mettre à jour
• tailscale pour un réseau sécurisé
• un répertoire persistant /workspace (un volume durable) où résident vos dépôts et votre travail — il survit à la mise en veille/reprise et aux reconnexions

Persistance : /workspace est le volume durable. Le dépôt configuré d'un pod est cloné dans /workspace (et ~/git-local y pointe), et tout ce que vous souhaitez conserver doit y résider. Dans le pod Claude Code, l'état propre de l'agent — ~/.claude, son identifiant de connexion, ses paramètres et sa mémoire — est également conservé sur le volume durable, de sorte que l'agent survit à la mise en veille/reprise. Les autres fichiers (le reste du répertoire personnel, le reste du système de fichiers) sont réinitialisés à partir de l'image lors de la reprise — ne comptez pas sur eux pour le stockage.

Les pods personnalisés ajoutent par-dessus cette base les dépôts de votre projet, les environnements d'exécution de langages, les clients de bases de données et les outils.

Comment les membres utilisent les pods

Depuis l'Espace de travail GenStudio, un membre ouvre le catalogue de pods (les pods que vous avez mis à sa disposition), en lance un et obtient un terminal en direct — ainsi qu'un volet navigateur pour tout service web exécuté par le pod. Le pod reste actif malgré les déconnexions, et son volume d'espace de travail persiste, de sorte que les travaux de longue durée survivent à une reconnexion. Les membres peuvent également partager un pod avec d'autres membres — en lecture-écriture ou en lecture seule — pour piloter une session à plusieurs.

Le guide destiné aux membres est Les Pods dans GenStudio ; pour découvrir ce que les équipes en font, consultez les cas d'utilisation sur l'exécution d'agents en continu, le pilotage d'un agent à plusieurs et le déploiement d'agents dans toute votre équipe.

Qui peut faire quoi

Action	Qui
Sélectionner les pods que les membres peuvent lancer, et pour qui	Administrateurs / propriétaires de l'organisation
Créer des pods personnalisés	Administrateurs / propriétaires de l'organisation
Lancer les pods mis à leur disposition	Membres

Les administrateurs gèrent les pods dans la page Centre de Contrôle → Pods. Pour créer votre propre environnement, voir Créer un Pod personnalisé.

Contrôle des dépenses

Les pods facturent le calcul à l'heure lorsqu'ils sont en cours d'exécution (le tarif dépend de la taille du pod, plus un surcoût pour un agent géré — le prix horaire de chaque pod est affiché sur la page) et uniquement le stockage lorsqu'ils sont en veille. La page Pods porte les garde-fous de l'organisation :

• Budget mensuel — le budget de pods à l'échelle de l'organisation, et le comportement en cas de dépassement lorsqu'il (ou le plafond d'un membre) est atteint : Bloquer les nouveaux lancements, Avertir mais autoriser, ou Autoriser (suivi uniquement). Le dépassement affecte les nouveaux lancements ; les pods déjà en cours d'exécution continuent de tourner.
• Plafond par membre — un plafond mensuel par défaut par membre, avec des plafonds par groupe pour attribuer une limite différente à des groupes spécifiques.
• Pods simultanés par membre — le nombre de pods qu'un membre peut exécuter en même temps.
• Mise en veille automatique en cas d'inactivité — les pods sans activité pendant ce nombre de minutes sont automatiquement mis en veille (par défaut 20 ; l'activité de terminal compte). Augmentez-la — ou réglez-la sur « jamais » — pour les équipes exécutant des agents toujours actifs, et laissez plutôt les budgets et les plafonds borner les dépenses.

Superviser les pods en cours d'exécution

La même page répertorie l'activité des pods de l'organisation — les dépenses depuis le début du mois par rapport au budget et chaque pod de membre — et permet à un administrateur de mettre en veille, d'arrêter ou de supprimer n'importe quel pod de l'organisation (par exemple, un pod laissé actif tout un week-end). Les membres conservent leurs données /workspace lors de la mise en veille, de sorte qu'il est sans risque de mettre en veille un pod oublié.