Déployer des applications avec des déploiements gérés

mistral deploy construit une application à partir d'un commit Git poussé et l'exécute sur l'infrastructure gérée de Mistral. La plateforme clone le commit et construit les modules déclarés dans mistral.json. Cette page décrit le fonctionnement d'un déploiement géré d'application. Pour la procédure pas à pas, consultez Déployer une app.

• Connectez-vous avec mistral login. Sans session de connexion, mistral deploy utilise MISTRAL_API_KEY, comme l'explique Déployer avec une clé API.
• Configurez un dépôt GitHub comme remote Git nommé origin, puis commitez et poussez l'application. Le répertoire de travail doit être propre, y compris les fichiers non suivis.
• Connectez GitHub à votre compte Mistral et installez l'app GitHub de Mistral sur le dépôt. La plateforme clone le commit via cette app, y compris pour les dépôts publics. La CLI vérifie ces deux points avant de créer quoi que ce soit. Dans un terminal, elle propose d'ouvrir la page GitHub qui permet de les configurer, puis reprend une fois que vous avez terminé. Sinon, elle s'arrête et affiche le lien de cette page.
• Commitez le Dockerfile de chaque module au chemin de build configuré dans mistral.json. La CLI vérifie que ces fichiers existent dans le commit déployé.

Si le commit a été poussé depuis une autre machine, exécutez git fetch origin pour que la CLI voie une branche distante qui le contient. Pour déployer du code qui n'est pas sur GitHub, utilisez mistral deploy --from-disk, comme l'explique Déployer depuis le disque.

Dans un terminal, la CLI demande l'organisation et l'espace de travail, en partant de ceux que mistral login a sélectionnés. Elle saute la question quand vous n'avez qu'un seul choix. --organization et --workspace acceptent un identifiant ou un nom.

Une nouvelle app doit appartenir à un espace de travail. Sans --workspace, la CLI utilise votre seul espace de travail disponible, ou vous demande de choisir quand il y en a plusieurs. Utilisez --name my-app pour nommer une nouvelle app : de 1 à 63 lettres minuscules, chiffres et tirets. Sinon, la CLI déduit le nom du répertoire du projet.

Avant de créer ou de construire quoi que ce soit, la CLI affiche l'organisation et l'espace de travail de destination. Elle vous avertit quand la cible enregistrée dans mistral.json n'est pas l'organisation et l'espace de travail auxquels vous êtes connecté. La commande crée l'app et les modules manquants, construit et déploie chaque module d'app dans l'environnement production, puis attend la fin des exécutions de déploiement. Aucune option ne permet de choisir un autre environnement.

À la fin, elle affiche l'URL de l'app, les URL de ses serveurs MCP, l'organisation et l'espace de travail, ainsi qu'un lien vers l'app dans Studio, qui bascule Studio sur cette organisation et cet espace de travail.

Le premier déploiement écrit un bloc deployment dans mistral.json avec les identifiants de l'organisation, de l'espace de travail (facultatif) et de l'app, pour que les autres clones et la CI déploient vers la même app. Dans un terminal, la CLI propose ensuite de commiter mistral.json et de le pousser sur votre branche, puis construit ce commit. --yes le fait sans demander, par exemple depuis la CI ou un agent. Sans terminal ni --yes, commitez et poussez le fichier vous-même : le déploiement suivant refuse un répertoire avec des modifications non commitées.

La liaison est enregistrée dès la création de l'app, même si un build échoue ensuite. Conservez-la quand vous corrigez puis relancez ce déploiement.

Les déploiements suivants réutilisent la cible enregistrée. Les options d'organisation ou d'espace de travail qui la contredisent sont refusées. Pour créer une app distincte, supprimez le bloc deployment, commitez et poussez cette modification, puis déployez vers la nouvelle destination.

mistral deploy déploie aussi le worker ajouté par la capacité workflows, sous forme de déploiement de workflows géré, et y raccorde l'API. Une app peut avoir un seul worker. Le worker est déployé en même temps que les autres modules : s'il échoue, les autres modules sont tout de même déployés, mais la commande se termine en erreur.

Le premier déploiement crée le déploiement de workflows durci : seul son propre worker géré peut s'y enregistrer, et ses workflows peuvent agir au nom de l'utilisateur qui les exécute. Un déploiement créé par une version antérieure de la CLI reste non durci. Pour le durcir, arrêtez-le dans Studio, durcissez-le depuis ses paramètres, puis redéployez.

--json désactive les questions interactives et écrit un rapport JSON unique sur stdout, la progression allant sur stderr :

mistral deploy --organization "My organization" --workspace "My workspace" --json

mistral deploy --organization "My organization" --workspace "My workspace" --json

Avec une session mistral login et sans cible enregistrée, --organization est obligatoire sans terminal ou avec --json. Ajoutez --workspace si plusieurs espaces de travail vous sont accessibles dans l'organisation. Une cible enregistrée se réutilise sans ces options.

Sans session de connexion, la commande utilise une clé API, comme l'explique Déployer avec une clé API.

Le rapport contient le commit, les identifiants et noms de l'organisation et de l'espace de travail, l'URL de l'app, les URL de ses serveurs MCP, un studioUrl vers l'app dans Studio et le résultat de chaque module. Un échec peut survenir après le déploiement d'autres modules : examinez les résultats avant de relancer.

Sans session mistral login, mistral deploy utilise la clé API de MISTRAL_API_KEY, ou une clé enregistrée avec mistral login --api-key. Une clé appartient à un seul espace de travail : la commande y déploie et n'a besoin ni de --organization ni de --workspace. Elle échoue quand une option ou la cible enregistrée dans mistral.json désigne une autre organisation ou un autre espace de travail. Lorsque vous êtes connecté, la CLI utilise votre session, même si MISTRAL_API_KEY est défini.

Pour déployer depuis la CI :

1. Déployez une première fois depuis votre machine, puis commitez et poussez mistral.json. Le job déploie vers la cible enregistrée.
2. Utilisez une clé créée par un utilisateur dans l'espace de travail de l'app. La plateforme refuse une clé qui n'appartient pas à un utilisateur, comme la clé d'un compte de service.
3. Donnez à la clé l'accès Private and shared connectors. La plateforme clone le dépôt avec la connexion GitHub de l'utilisateur qui a créé la clé, et la CLI vérifie cette connexion via la clé.
4. Enregistrez la clé comme secret de CI, exposez-la au job sous le nom MISTRAL_API_KEY et exécutez mistral deploy --yes.

mistral apps publish et mistral apps unpublish n'acceptent pas de clé API. Exécutez-les après mistral login.

Le plan de votre organisation détermine le nombre d'apps qu'elle peut avoir :

Les apps de tous les espaces de travail de l'organisation comptent dans la limite ; les apps supprimées n'y comptent pas. Avec une limite de 0, la création d'une app échoue avec Your plan does not include Apps. Pour activer le paiement à l'usage, consultez Abonnements. Quand l'organisation atteint sa limite, supprimez une app pour libérer une place.

Chaque app peut avoir au plus trois frontends et backends au total. Les workers ne comptent pas dans cette limite.

• Une app peut avoir une seule base de données gérée, Postgres 17. Le premier déploiement la crée et chaque service reçoit ses paramètres de connexion.
• Les modules conteneur sont refusés, car cette commande construit à partir de Git. Déployez-les via la CI.
• Les modules existants voient leur port, leurs routes et leurs commandes de cycle de vie mis à jour depuis mistral.json, mais pas leur type. Si le type diffère, la CLI vous avertit et le type de la plateforme reste appliqué. Configurez les variables d'environnement et les secrets séparément sur la plateforme.

Pour la liste complète des commandes et des options, consultez la Référence de la CLI.