Variables d'environnement

Les variables d'environnement configurent vos applications sans mettre de secrets dans le code. Elles se définissent par application ou se partagent à l'échelle d'un stack, sont stockées chiffrées et injectées dans le conteneur au déploiement suivant.

Ajouter des variables

Une clé s'écrit en lettres majuscules, chiffres et tirets bas, et commence par une lettre ou un tiret bas (DATABASE_URL, _INTERNAL). Une clé en minuscules est refusée en 422.

Depuis le tableau de bord

1. Ouvrez l'application (Stacks, puis le stack, puis l'application) et son onglet Environnement.
2. En mode Clé-Valeur, saisissez la clé et la valeur. Cochez Build si la valeur ne sert qu'à la construction de l'image.
3. Cliquez sur Ajouter une variable. Les valeurs s'affichent masquées ; Révéler les montre et demande au moins le rôle Developer sur l'application.

Depuis la CLI

sh0 env <app> set prend une paire CLÉ=VALEUR et --build pour une variable de build ; list n'affiche jamais les valeurs.

$ sh0 env my-api set LOG_LEVEL=info
[ok] Set LOG_LEVEL for 'my-api'
$ sh0 env my-api set GREETING_BUILD=hello --build
[ok] Set GREETING_BUILD for 'my-api'
$ sh0 env my-api list
  KEY             VALUE    BUILD  CREATED
  --------------  -------  -----  -------
  LOG_LEVEL       *******  no     0s ago
  GREETING_BUILD  *******  yes    0s ago

Depuis l'API

Les routes sont /api/v1/apps/:id/env-vars (GET, POST) et /api/v1/apps/:id/env-vars/:env_id (PATCH, DELETE). Les réponses masquent toujours la valeur ; ajoutez ?reveal=true au GET pour la lire.

$ curl -s -X POST https://panel.example.com/api/v1/apps/e17d4314-ff61-485a-a509-58b3974c1eee/env-vars \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"key":"DATABASE_URL","value":"postgres://app:[email protected]:5432/appdb"}'
{"data":{"app_id":"e17d4314-ff61-485a-a509-58b3974c1eee","created_at":"2026-10-02T02:49:26.463374291+00:00","id":"68ddf6a1-d9e0-49e4-9893-c320eaa58b62","is_build":false,"key":"DATABASE_URL","value":"*****"}}

$ curl -s -X PATCH https://panel.example.com/api/v1/apps/e17d4314-ff61-485a-a509-58b3974c1eee/env-vars/68ddf6a1-d9e0-49e4-9893-c320eaa58b62 \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"value":"postgres://app:[email protected]:5432/appdb"}'
{"data":{"app_id":"e17d4314-ff61-485a-a509-58b3974c1eee","created_at":"2026-10-02 02:49:26","id":"68ddf6a1-d9e0-49e4-9893-c320eaa58b62","is_build":false,"key":"DATABASE_URL","value":"*****"}}

Quand les changements s'appliquent

Enregistrer une variable ne redémarre rien. Le conteneur en cours garde son ancien environnement jusqu'au déploiement suivant, depuis le tableau de bord ou avec sh0 deploy <app>.

Les variables de build sont passées à docker build en --build-arg ; le Dockerfile doit les déclarer avec ARG. Elles sont absentes du conteneur en cours. Pour une application déployée par envoi d'archive (sh0 push), un redéploiement réutilise la dernière image : les variables d'exécution changent, mais une nouvelle valeur de build ne prend effet qu'au sh0 push suivant.

Relevé sur une application de test après redéploiement (la variable de build GREETING_BUILD a atteint l'image, pas l'environnement) :

$ docker exec <container> env | grep -E '^(LOG_LEVEL|REGION|GREETING_BUILD)='
REGION=eu-central
LOG_LEVEL=info
$ docker exec <container> cat /build-arg.txt
hello

Édition en bloc (.env)

L'onglet Environnement accepte des lignes CLÉ=VALEUR, une par ligne ; les commentaires (#) et les lignes vides sont ignorés. Les deux voies se comportent différemment :

• Coller .env puis Analyser et ajouter ajoute chaque ligne comme nouvelle variable et laisse les autres intactes (une clé existante est dupliquée, voir plus haut).
• L'Éditeur .env puis Tout enregistrer remplace toutes les variables de l'application par le contenu de l'éditeur. L'équivalent API est PUT /api/v1/apps/:id/env-vars/bulk avec un tableau entries : toute clé absente du tableau est supprimée.

Variables de stack

Une variable posée sur un stack est lue par toutes les applications de ce stack. Ouvrez le stack et utilisez Variables partagées dans le panneau Réseau interne et réglages partagés, ou l'API /api/v1/projects/:id/env-vars (un stack est un projet dans l'API). Envoyer une clé existante la met à jour. Les valeurs de stack ne sont jamais renvoyées, pas même à un administrateur.

$ curl -s -X POST https://panel.example.com/api/v1/projects/5aee8eea-9f77-4d10-ac21-2fe4a565e666/env-vars \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"key":"REGION","value":"eu-central"}'
{"data":{"created_at":"2026-10-02 02:49:26","id":"e89e5915-e5dd-4878-b1b6-b6df150df54d","is_build":false,"key":"REGION","project_id":"5aee8eea-9f77-4d10-ac21-2fe4a565e666","updated_at":"2026-10-02 02:49:26"}}

Quand la même clé existe aux deux niveaux, l'application l'emporte, et le journal de déploiement liste les variables de stack écrasées. Dans l'exemple ci-dessous, le stack définit LOG_LEVEL=debug et REGION=eu-central, et l'application LOG_LEVEL=info :

Chiffrement au repos

Chaque valeur est chiffrée en AES-256-GCM avant d'être écrite dans la base de sh0. La clé est la clé maîtresse de l'instance, conservée dans master.key et protégée par master.passphrase (PBKDF2), tous deux dans le répertoire de données de sh0 (/var/lib/sh0 sur une installation Linux standard).

Joindre les autres services

sh0 ne résout pas les références : une valeur comme $OTHER_VAR arrive telle quelle dans le conteneur. Écrivez la valeur complète, avec les noms d'hôte internes : une application joint une autre application du même stack à <nom-app> ou <nom-app>.internal, et tout serveur de bases de données à <nom-serveur>.internal.

Ce que sh0 n'injecte pas

• Aucune variable système. sh0 n'ajoute aucune variable SH0_* (nom d'application, domaine, commit) à vos conteneurs. Seule exception : une application Laravel ou Lumen sans APP_KEY en reçoit une, générée au premier déploiement et enregistrée comme variable de l'application.
• Variables dans les tâches planifiées. Une tâche rattachée à une application reçoit les variables d'exécution de l'application et du projet, dans un conteneur jetable issu de l'image de l'application : voir Tâches planifiées.