Variables et secrets

📍 Où trouver ça dans l'UI

• Variables attendues par un service : Infra → onglet Architecture → Services → la ServiceDefinition concernée
• Configuration d'un environnement : Infra → Environments → {env} → Configuration
• Binding service ↔ configuration : Infra → Environments → {env} → Services → la ServiceInstance

La config consommée par un service (URL de la BDD, JWT secret, clé API externe, niveau de log…) circule à travers trois niveaux dans Wakastart : déclaration côté architecture, configuration côté environnement, puis binding dans chaque ServiceInstance.

1. Architecture : déclarer ce que le service attend

Quand tu crées une ServiceDefinition, tu listes les variables que ton service consomme :

textCopier
ServiceDefinition "backend"
├── requires JWT_SECRET
├── requires DATABASE_URL
├── requires S3_BUCKET
└── requires LOG_LEVEL

Seules les variables déclarées ici peuvent être bindées dans les environnements. Si ton service a besoin d'une nouvelle config, il faut d'abord la déclarer dans l'architecture.

2. Configuration d'un environnement

La Configuration d'un environnement est l'inventaire des valeurs disponibles dans cet env, à partir desquelles tes services peuvent se servir. Elle est commune à tous les services de l'environnement.

D'où viennent les entrées de Configuration

Secret vs non-secret

Chaque entrée de configuration peut être marquée secret ou non :

Un secret est stocké chiffré dans le coffre-fort Wakastart. Une fois créé, sa valeur n'est plus consultable dans l'UI — seuls les pods de tes services peuvent la lire au démarrage.

3. Binding : connecter un service à la Configuration

Pour chaque ServiceInstance, tu fais un binding entre une variable attendue par le service (déclarée dans sa ServiceDefinition) et une entrée de la Configuration de l'env.

textCopier
ServiceInstance "backend" en env prod
├── JWT_SECRET     ──bind──>  entrée Configuration "jwt-secret" (secret utilisateur)
├── DATABASE_URL   ──bind──>  entrée Configuration "primary-db-url" (auto, DatabaseInstance)
├── S3_BUCKET      ──bind──>  entrée Configuration "medias-bucket" (auto, StorageBucketInstance)
└── LOG_LEVEL      ──bind──>  entrée Configuration "log-level" (utilisateur)

Au démarrage du pod, chaque env var reçoit la valeur de l'entrée bindée.

Mutualiser : une valeur, plusieurs services

Si plusieurs services ont besoin de la même valeur (ex: STRIPE_API_KEY utilisée par backend et worker), ne crée pas deux entrées identiques. Crée une seule entrée dans la Configuration de l'env et bind-la dans chaque ServiceInstance qui en a besoin.

Avantages :

• Une seule source de vérité — pas de drift entre services
• Mise à jour atomique — changer la valeur = changer un seul endroit, tous les services concernés la récupèrent au prochain redémarrage
• Pas de duplication dans les secrets — un secret est stocké une fois, pas N fois

Les variables plateforme sont dynamiques

Les entrées générées par la plateforme ou par l'environnement (URL de la BDD, URL d'un service interne, hostname public d'un autre service de l'app, credentials S3…) sont dynamiques : si la ressource sous-jacente change (la BDD est migrée vers un nouveau hostname, un service est renommé, un secret S3 est rotaté…), la valeur de l'entrée suit automatiquement.

→ Tu ne casses jamais un binding en faisant évoluer ton infrastructure. Les services redémarrés récupèrent les nouvelles valeurs.