Environnements
Chaque projet de plateforme contient un ou plusieurs environnements.
Un environnement est une cible de déploiement isolée avec sa propre URL, ses propres variables d’environnement et son historique de déploiement. Il peut aussi disposer de sa propre base de données hébergée.
Utilisez les environnements pour exécuter des versions production, staging et de prévisualisation de la même base de code au sein d’un seul projet.
Votre premier mastra deploy crée l’environnement production. Créez-en d’autres avec la CLI ou en déployant vers un nom qui n’existe pas encore.
Créer un environnementLien direct vers Créer un environnement
Créez explicitement un environnement :
mastra env create staging
Ou laissez un déploiement le créer, ce qui demande une confirmation :
mastra deploy --env staging
mastra env create utilise par défaut le type staging. Passez --type pour définir explicitement staging ou preview, et --region pour choisir l’emplacement d’exécution de l’environnement :
mastra env create eu-preview --type preview --region eu
Chaque projet possède un unique environnement production, créé lors de votre premier déploiement. La région est fixée à sa création. Les bases de données attachées à un environnement sont automatiquement placées près de sa région, et les données d’Observability sont routées vers la région d’ingestion correspondant à la zone de résidence. Consultez Régions pour connaître les régions prises en charge, le placement des bases de données et la colocalisation d’Observability. Le nombre d’environnements par projet dépend de votre offre.
Lister les environnementsLien direct vers Lister les environnements
mastra env list
La sortie affiche le nom, la région, l’état du déploiement actif de chaque environnement et les variables d’environnement gérées injectées par les bases de données attachées. Passez --json pour obtenir une sortie lisible par une machine en CI.
Toutes les commandes mastra env déterminent leur projet à partir de MASTRA_PROJECT_ID, de l’indicateur --project ou du fichier .mastra-project.json écrit lors de votre premier déploiement, dans cet ordre. Exécutez-les depuis le répertoire de votre projet et vous n’aurez jamais besoin de nommer le projet.
Variables d’environnementLien direct vers Variables d’environnement
Un environnement résout ses variables depuis trois portées :
- Variables gérées : injectées par les bases de données hébergées attachées, par exemple
TURSO_DATABASE_URL. La plateforme les définit et vous ne pouvez pas les modifier. - Variables limitées à l’environnement : stockées sur un environnement via le tableau de bord. Utilisez-les pour les valeurs qui diffèrent entre les environnements, telles que les clés d’API de services de staging et de production.
- Variables limitées au projet : stockées sur le projet et partagées par tous les environnements.
Les variables limitées à l’environnement et celles limitées au projet constituent ensemble les variables stockées décrites sur la page Déployer.
Les variables sont appliquées lorsqu’un déploiement démarre. Pour appliquer des variables modifiées à un service en cours d’exécution sans redéploiement complet :
mastra env restart staging
Pour voir l’ensemble complet utilisé par les déploiements d’un environnement, avec les valeurs limitées à l’environnement et au projet fusionnées et les variables gérées listées par nom, extrayez-les dans un fichier env local :
mastra env vars pull staging --output .env.staging
Les valeurs des variables gérées sont injectées lors du déploiement et ne sont jamais écrites dans le fichier. Elles apparaissent sous forme de commentaires ne contenant que leur nom.
Les variables d’environnement ne remplacent pas les variables de base de données gérées. Pour pointer un environnement vers une autre base de données, attachez plutôt une base de données limitée à l’environnement.
Historique des déploiementsLien direct vers Historique des déploiements
Listez les déploiements de tous les environnements ou filtrez-en un :
mastra env deploys
mastra env deploys staging
Chaque ligne affiche l’état du déploiement, l’environnement, l’horodatage et le déploiement actuellement actif. Un déploiement passe par queued → uploading → building → deploying → running, et la plateforme ne signale running que lorsque la nouvelle version reçoit du trafic.
Isoler les données d’un environnementLien direct vers Isoler les données d’un environnement
Les bases de données hébergées sont par défaut limitées à un seul environnement ; la production et le staging lisent et écrivent donc chacun dans leur propre base de données :
mastra env db create production --kind turso --name my-project-production-db
mastra env db create staging --kind turso --name my-project-staging-db
Si vous préférez partager une base de données entre tous les environnements, attachez-la plutôt avec --shared : mastra env db create --kind turso --shared.
Un environnement ne peut utiliser qu’une base de données par fournisseur. Si le projet possède déjà une base de données partagée (--shared) du même fournisseur, l’attachement d’une base limitée à l’environnement est refusé en raison d’un conflit de nom de variable ; supprimez d’abord la base partagée avec mastra env db delete. La suppression d’une base de données la détruit chez le fournisseur avec toutes ses données ; exportez donc tout ce que vous devez conserver. Consultez Bases de données hébergées pour le modèle complet de portée.
Supprimer un environnementLien direct vers Supprimer un environnement
mastra env delete staging
La CLI demande une confirmation avant la suppression. Supprimer un environnement retire ses déploiements et ses variables stockées.