Aller au contenu

Créer un Pod personnalisé

Un Pod personnalisé est l'environnement propre à votre organisation — vos dépôts, vos chaînes d'outils de langages, vos clients de bases de données et vos outils — que vos membres lancent comme n'importe quel autre Pod. Les Pods personnalisés ne sont disponibles qu'au sein de votre organisation et peuvent être limités à des groupes spécifiques.

Il existe deux façons d'en créer un. La plupart des équipes commencent par l'Option A ; utilisez l'Option B lorsque vous devez intégrer votre propre image logicielle.

Info

Les Pods personnalisés sont créés et gérés par les administrateurs/propriétaires de l'organisation dans Centre de Contrôle → Pods. Les membres ne voient que les Pods que vous activez pour eux.

Option A — Partir d'une base SkyDeck (aucune image à construire)

Idéal lorsque vous souhaitez simplement le Pod de codage standard pointant vers votre dépôt.

  1. Allez dans Centre de Contrôle → Pods et cliquez sur Nouveau Pod.
  2. Choisissez une image de base SkyDeck — par exemple la base de codage Claude Code (Ubuntu + gh + Claude Code + tailscale + un terminal fonctionnel).
  3. Renseignez :
  4. Nom et, éventuellement, une description / une icône.
  5. Agent — l'agent à préinstaller : Claude Code, OpenClaw, Hermes, JupyterLab, ou Aucun pour utiliser le vôtre. (Un agent géré ajoute un léger surcoût horaire — le prix affiché sur le Pod l'inclut.)
  6. Dépôt (facultatif) — une URL git à cloner dans /workspace (le volume durable) au premier lancement.
  7. Commande de démarrage (facultatif) — une commande à exécuter au démarrage du Pod (par exemple, installer les dépendances).
  8. Ports exposés (facultatif) — les ports de tout service web exécuté par votre Pod ; le volet navigateur de l'espace de travail ne peut atteindre que les ports listés ici.
  9. Taille — le niveau de vCPU / mémoire.
  10. Volet par défaut — ouvrir sur le terminal ou le navigateur.
  11. Cliquez sur Enregistrer. Le Pod est créé pour votre organisation et démarre activé.

Option B — Utiliser votre propre image (avancé)

Idéal lorsque votre environnement nécessite des logiciels intégrés (versions précises d'exécution, paquets système, outils préinstallés, données en cache).

  1. Construisez une image par-dessus la base SkyDeck afin que votre Pod hérite d'un terminal fonctionnel et de l'agent IA. Dans votre Dockerfile :
FROM <skydeck-coding-base-image>     # ask your SkyDeck contact for the reference
# add your repos, language toolchains, DB clients, project tools…
RUN apt-get update && apt-get install -y --no-install-recommends <your-packages>

!!! warning

Conservez le shell et `tmux` de la base (construire `FROM` la base SkyDeck en hérite —
   c'est ce qui donne un terminal fonctionnel). Mettez les environnements d'exécution,
   les clients de bases de données et les outils dans l'image ; **n'y mettez pas de
   secrets** — ils sont injectés au lancement, pas intégrés à l'image.

  1. Testez-la localement avec Docker, puis poussez-la vers le registre de conteneurs depuis lequel SkyDeck extrait les images (demandez le registre et les identifiants à votre contact SkyDeck ; ajoutez un secret de pull s'il est privé). Étiquetez avec une version ou un digest explicite — :latest n'est pas accepté ; une étiquette ou un digest @sha256:… est obligatoire.

  2. Dans Centre de Contrôle → Pods → Nouveau Pod, choisissez Avancé : image personnalisée et collez la référence d'image complète (registre/dépôt:étiquette ou registre/dépôt@sha256:…). Définissez l'agent, les ports exposés, la taille et le volet par défaut comme dans l'Option A, puis cliquez sur Enregistrer.

Le rendre disponible pour vos membres

Un nouveau Pod personnalisé démarre activé mais n'est visible par personne tant que vous n'avez pas défini qui peut le lancer. Sur la ligne du Pod dans Centre de Contrôle → Pods :

  • Disponible pour tout le monde — chaque membre de votre organisation peut le lancer.
  • Par groupe — attribuez un ou plusieurs groupes/tags pour que seuls les membres de ces groupes voient le Pod (le même modèle que Gérer les Outils). Un membre voit un Pod s'il appartient à l'un des groupes attribués.

Les membres lancent le Pod depuis l'Espace de travail GenStudio lors de leur prochaine ouverture du catalogue de Pods.

Info

Contrôle des coûts. Les Pods génèrent un coût de calcul tant qu'ils sont en cours d'exécution. Définissez un budget d'organisation et des plafonds de dépenses par utilisateur ou par groupe dans les paramètres de dépenses des Pods, ainsi qu'une mise en veille automatique en cas d'inactivité pour que les Pods oubliés ne continuent pas à facturer.

Conseils

  • Épinglez la version de la base que votre image étend afin qu'une mise à jour de la base ne modifie jamais silencieusement votre Pod ; faites-le évoluer délibérément.
  • Espace de travail persistant — uniquement /workspace. Le /workspace d'un Pod est un volume durable et constitue le seul stockage qui survit à la mise en veille/reprise et aux reconnexions ; le dépôt configuré y est cloné. Tout le reste dans le Pod (le répertoire personnel, le reste du système de fichiers) est réinitialisé à partir de l'image lors de la reprise — indiquez aux membres de conserver tout ce qu'ils souhaitent garder sous /workspace.
  • Mettre à jour un Pod personnalisé. Poussez une nouvelle étiquette d'image et modifiez la référence d'image du Pod ; les membres récupèrent la nouvelle image à leur prochain lancement.