Déployer une stack depuis un repo git

Une stack se déploie depuis un dépôt git : la plateforme récupère le docker-compose.yaml du dépôt, le valide, puis construit les services depuis le code du repo (les images sont buildées, pas seulement téléchargées). C’est l’équivalent multi-conteneurs du déploiement d’un service depuis git — et c’est le seul chemin : coller un compose n’est pas proposé.

Pourquoi le dépôt, et pas un copier-coller

	Depuis un repo git
Source du compose	récupérée dans votre dépôt, à chaque déploiement
Clé `build:`	autorisée — les services sont buildés depuis le repo
Mise à jour	pousser sur la branche puis redéployer
Rollback	redéploiement d’un commit — déterministe

Un compose collé serait une copie figée, sans commit auquel revenir et sans code à construire. Le dépôt donne les trois d’un coup.

Déployer

La création vit dans le formulaire « Nouveau service » de votre projet, onglet Dépôt Git : c’est le même dépôt, la même branche, seule la façon de le déployer change.

Renseignez le dépôt (owner/repo, ou l’URL complète — HTTPS ou SSH) et la branche.
Basculez « Déployer » sur « Une stack ».
Vérifiez le chemin du compose : il est prérempli si un docker-compose.yaml a été trouvé à la racine, sinon saisissez-le.
L’analyse se déclenche seule : la plateforme récupère le compose, le valide côté serveur et affiche le récapitulatif (conteneurs, images, volumes, conteneur exposé) ainsi que la jauge de plan. Aucun bouton « Analyser », aucune étape intermédiaire.
Renseignez les variables que le compose laisse à votre charge, puis Déployer la stack : la plateforme clone le dépôt, construit les services build: et démarre l’ensemble.

Un service qui utilise build: (par ex. build: ./api) est construit depuis le contexte du dépôt ; un service qui utilise image: est simplement téléchargé. Les deux cohabitent dans le même compose.

Ce qui se passe à chaque redéploiement

Le compose de votre dépôt peut changer entre deux déploiements. À chaque déploiement, la plateforme :

fige le commit de la branche suivie, puis relit et revalide le compose à ce commit — ce qui est validé est donc exactement ce qui est construit ;
recompte les ressources de la stack d’après ce compose (conteneurs et deploy.resources.limits) et les confronte au plafond de votre plan.

Deux conséquences concrètes :

un commit qui introduit une clause refusée (montage de l’hôte, privileged, labels réservés cassiope.*…) fait échouer le déploiement, avec l’erreur correspondante — il ne part pas ;
un commit qui ajoute des conteneurs ou relève les limites au-delà de ce que votre plan autorise fait également échouer le déploiement. Passez à un plan supérieur, ou réduisez les ressources demandées dans le compose.

L’exposition (le conteneur publié et son port) reste celle retenue à la création, d’après le compose d’alors : un conteneur ajouté par un commit ultérieur n’est jamais exposé automatiquement.

Stacks du catalogue

L’onglet Modèle du dialogue « Nouveau service » peut proposer des stacks prêtes à l’emploi (dépôt officiel, version épinglée). Les choisir ne crée rien : l’onglet Git se remplit (dépôt, tag, chemin du compose) en mode stack, et vous validez comme pour n’importe quel dépôt — mêmes contrôles, mêmes valeurs générées.

Stacks protégées par un identifiant (Supabase)

Pour Supabase, le lien public de la stack ouvre Studio, que Supabase protège par une authentification HTTP : à la première visite, c’est votre navigateur qui affiche une petite fenêtre de connexion (elle n’a ni l’apparence de Supabase ni celle de Cassiope — c’est normal).

À la création, le formulaire présente une section « Identifiants de Studio » : l’identifiant est prérempli (supabase), le mot de passe est généré si vous le laissez vide.
Après le déploiement, la page de la stack porte une carte « Connexion à Studio » : Afficher les identifiants les montre, prêts à copier (propriétaire ou administrateur de l’organisation ; chaque affichage est journalisé).
Ils vivent dans les variables DASHBOARD_USERNAME / DASHBOARD_PASSWORD de l’onglet Variables : pour les changer, modifiez-les puis redéployez la stack.

Mettre à jour une stack

Dans l’onglet Déploiements, la carte Mise à jour montre la version déployée, la branche suivie et, pour un dépôt GitHub, les tags les plus récents. Choisissez un tag, une branche ou un commit, puis Mettre à jour :

les volumes attachés sont sauvegardés (si l’option est cochée) — si une sauvegarde échoue, la mise à jour est annulée et la stack reste inchangée ;
le commit visé est déployé ;
la plateforme vérifie que les conteneurs sont sains ; sinon, elle redéploie la version précédente automatiquement.

Limites à connaître :

seul le code revient en arrière : les données ne sont jamais restaurées automatiquement (une migration a pu s’appliquer en partie). Les sauvegardes restent disponibles dans l’onglet Stockage ;
seuls les volumes bloc attachés sont sauvegardés ;
la liste des tags n’est disponible que pour GitHub (ailleurs, saisissez la référence) ;
les stacks à images (sans dépôt) n’ont pas de mise à jour guidée.

Capacités et stockage depuis la page d’un conteneur

Les capacités (vCPU, RAM, disque) et les volumes se règlent au niveau de la stack : le redéploiement est unique et coupe brièvement toute la stack. Chaque page de conteneur porte les raccourcis Redimensionner et Stockage vers ces réglages, tant que la stack est en cours d’exécution.

La carte Disque de la même page montre l’espace occupé par le conteneur (image et données écrites dans le conteneur) face à sa capacité, puis chaque volume qu’il monte avec son occupation. Un volume sur le disque du serveur n’est pas mesuré : il affiche « — » et sa capacité. Cette mesure est indicative ; la facturation repose sur la capacité réservée.

Stockage : disque local, puis volume dédié

Chaque volume de données d’une stack démarre sur le disque du serveur (2 Go par défaut) : c’est suffisant pour la plupart des conteneurs, et c’est inclus dans l’offre gratuite. Quand une base a besoin de plus, l’onglet Stockage de la stack propose « Passer sur volume dédié » (10, 50, 100 Go ou 1 To, offres payantes) :

la migration n’est proposée que sur une stack en cours d’exécution ;
la stack entière est arrêtée pendant la copie (la plateforme ne sait pas en arrêter une partie), puis redéployée ;
les données sont copiées et vérifiées avant que l’ancien volume ne soit supprimé ; en cas d’échec, elles sont restaurées et la version précédente redémarre ;
le passage est irréversible, et le volume dédié est facturé tant qu’il existe.

Limites actuelles : réveiller une stack mise en veille ne remonte pas encore un volume dédié, et seules les sauvegardes des volumes dédiés sont prises en charge.

Dépôts supportés

Dépôts publics : GitHub, GitLab, Bitbucket (indiquez owner/repo ou l’URL). Le choix « URL Git » convient aussi : c’est l’URL qui désigne la forge, pas l’étiquette du menu.
Dépôts privés GitHub : supportés si vous avez connecté votre compte GitHub (page Connexions). Indiquez l’URL SSH du dépôt (git@github.com:owner/repo.git) :
- le compose est lu via votre connexion GitHub (pour le valider) ;
- une clé de déploiement en lecture seule est générée et ajoutée automatiquement à votre dépôt, pour que la plateforme puisse le cloner et le construire.
Les dépôts privés GitLab/Bitbucket et les forges auto-hébergées ne sont pas encore supportés à la création : le compose ne peut pas y être récupéré pour validation, et Cassiope ne confie jamais au moteur de build un compose qu’elle n’a pas lu. Le mode stack reste proposé — le refus est explicite, au moment de l’analyse, plutôt que masqué derrière une option grisée.

Sécurité : le compose est validé avant construction

Même sourcé depuis votre dépôt, le compose passe le même contrôle de sécurité avant que la plateforme ne le confie au moteur de build. Les vecteurs d’évasion restent refusés : privileged, cap_add, security_opt, devices, sysctls, network_mode/pid/ipc, ainsi que les montages vers docker.sock, les chemins absolus (/…, ~…) et toute remontée .. au-dessus du dépôt.

Deux assouplissements propres au fait que le code est cloné :

la clé build: est autorisée (c’est tout l’intérêt) ;
les volumes relatifs au dépôt (./…, sans ..) sont autorisés (montés depuis le code cloné).

Si le dépôt est introuvable, la branche ou le chemin n’existent pas, ou le compose enfreint une règle, le formulaire affiche l’erreur au moment de l’analyse, avant toute création — et le bouton reste inactif.

Adapter le compose sans le modifier : l’override

Un compose pensé pour le développement publie souvent des ports sur la machine hôte (ports: "5432:5432"). Sur la plateforme, ces ports n’ont pas lieu d’être : l’accès se fait par le domaine de la stack. Plutôt que de vous demander de forker le dépôt, la plateforme dépose un fichier d’override à côté du compose et le fusionne au démarrage.

Par défaut, l’override convertit en volume nommé les binds relatifs inscriptibles qui visent des données (./volumes/db/data:/var/lib/postgresql/data) : le volume devient un stockage géré, au lieu d’un dossier du disque de la machine perdu à la suppression de la stack. Restent des binds : les fichiers (./kong.yml), les montages :ro et les répertoires dont la destination n’est pas un chemin de données (/var/lib, /data, /srv) — typiquement du code suivi par le dépôt.
Par défaut, l’override retire les ports publiés sur l’hôte (ports: !reset []). Il n’apparaît que si votre compose en publie.
Il est visible dans Options avancées · override du compose et modifiable (syntaxe Docker Compose : !reset, !override, seules les clés services, volumes, networks).
Une fois modifié, il est figé à chaque déploiement : un push sur le dépôt ne le change pas. « Revenir à l’override généré » le régénère.
Le contrôle de sécurité s’applique au compose fusionné : l’override ne peut pas réintroduire un vecteur d’évasion.

Secrets et variables préremplis

La plateforme lit le fichier .env.example voisin du compose et propose une valeur pour chaque variable que le compose référence sans la définir :

secret à changer (*_SECRET, *_PASSWORD, *_KEY… vide ou « changeme ») : tiré au hasard à la création si vous laissez le champ vide, affiché « Généré automatiquement » ;
jeton signé (un JWT d’exemple dont la signature se vérifie avec une autre variable) : régénéré à la création avec le secret effectif — celui que vous avez saisi ou celui qui a été tiré ;
valeur d’exemple non secrète : préremplie, modifiable.

Une valeur saisie n’est jamais écrasée. Les secrets de tiers (SMTP, Stripe, OAuth…) ne sont jamais inventés : ils restent à renseigner. Les valeurs tirées sont chiffrées et listées (masquées) dans l’onglet Variables de la stack ; un propriétaire ou un administrateur de l’organisation peut en afficher une avec le bouton œil (chaque affichage est journalisé). C’est ainsi que l’on retrouve un identifiant généré, par exemple le mot de passe de Studio pour Supabase.

Exposition, limites, cycle de vie

Identiques à toute stack : un seul conteneur exposé (domaine automatique), plafonds de plan sur la somme des capacités (vCPU / RAM / stockage), et cycle de vie Déployer / Arrêter / Démarrer / Redéployer / Supprimer. Le statut de déploiement d’une stack git est réel (suivi de la construction et du démarrage), et le rollback réutilise un commit précis — plus fiable qu’un rollback par tag d’image.

Captures d’écran à insérer.