Auto-héberger des workflows

Un déploiement est un groupe de workers identifié par un nom, qui possède un ensemble de définitions de workflows et reçoit toutes les exécutions associées à ces définitions. Pour auto-héberger des workflows, vous exécutez vous-même les workers (sur votre machine pour le développement local, ou sur votre propre infrastructure pour la production) et vous les regroupez sous un nom de déploiement. Cela permet l'isolation des workers dans les espaces de travail partagés et le routage automatique des exécutions, tandis que la plateforme assure la durabilité, la mise à l'échelle et l'observabilité.

Si vous préférez ne pas exécuter de workers du tout, voir déploiements managés pour les workflows : Mistral Cloud construit et exécute le worker pour vous, et les concepts de déploiement restent les mêmes.

DEPLOYMENT_NAME est obligatoire au démarrage du worker. Le worker échoue immédiatement au lancement si cette variable n'est pas définie.

DEPLOYMENT_NAME=invoice-service MISTRAL_API_KEY=your-key uv run python worker.py

DEPLOYMENT_NAME=invoice-service MISTRAL_API_KEY=your-key uv run python worker.py

Caractères valides : alphanumériques, tirets, underscores (128 caractères maximum).

WORKER_NAME identifie le processus de worker individuel et est visible dans la console et l'API. Sa valeur par défaut est socket.gethostname().

Dans un espace de travail partagé, plusieurs développeurs peuvent exécuter des workers simultanément sans se gêner mutuellement. Chaque déploiement ne reçoit que les exécutions des définitions de workflow qu'il a enregistrées.

# Developer A
DEPLOYMENT_NAME=alice MISTRAL_API_KEY=shared-key uv run python worker.py

# Developer B
DEPLOYMENT_NAME=bob MISTRAL_API_KEY=shared-key uv run python worker.py

# Developer A
DEPLOYMENT_NAME=alice MISTRAL_API_KEY=shared-key uv run python worker.py

# Developer B
DEPLOYMENT_NAME=bob MISTRAL_API_KEY=shared-key uv run python worker.py

Les exécutions d'Alice arrivent sur les workers d'Alice. Celles de Bob arrivent sur les workers de Bob.

Lorsqu'un seul déploiement actif possède un workflow, les exécutions sont routées automatiquement, sans configuration supplémentaire :

execution = await client.execute_workflow(
    workflow_identifier="invoice_processor",
    input_data=InputData(invoice_id="INV-001"),
)

execution = await client.execute_workflow(
    workflow_identifier="invoice_processor",
    input_data=InputData(invoice_id="INV-001"),
)

Lorsque deux déploiements actifs enregistrent le même nom de workflow, la plateforme ne peut pas router automatiquement et renvoie une erreur 409 Conflict :

{
  "code": "AMBIGUOUS_WORKFLOW",
  "deployments": ["alice", "bob"]
}

{
  "code": "AMBIGUOUS_WORKFLOW",
  "deployments": ["alice", "bob"]
}

Résolvez le conflit en transmettant explicitement deployment_name :

execution = await client.execute_workflow(
    workflow_identifier="invoice_processor",
    deployment_name="alice",
    input_data=InputData(invoice_id="INV-001"),
)

execution = await client.execute_workflow(
    workflow_identifier="invoice_processor",
    deployment_name="alice",
    input_data=InputData(invoice_id="INV-001"),
)

Lorsqu'un worker enregistre un nom de workflow déjà possédé par un autre déploiement actif, la plateforme émet immédiatement un avertissement. L'enregistrement n'est pas bloqué — l'avertissement est renvoyé dans la réponse d'enregistrement et apparaît dans les logs du worker :

{
  "warnings": [
    "Workflow 'invoice_processor' is also registered by active deployment 'bob'"
  ]
}

{
  "warnings": [
    "Workflow 'invoice_processor' is also registered by active deployment 'bob'"
  ]
}

Le conflit se résout automatiquement lorsque l'un des déploiements devient inactif (ses workers s'arrêtent).

Plusieurs workers dans le même déploiement qui enregistrent les mêmes définitions relèvent du scaling horizontal — aucun avertissement n'est émis.

Un déploiement est actif tant qu'au moins l'un de ses workers a envoyé un heartbeat dans la fenêtre de liveness. Les workers envoient automatiquement un heartbeat toutes les 10 secondes environ. Lorsque tous les workers s'arrêtent, le déploiement devient inactif une fois la fenêtre de liveness expirée (50 secondes en production, configurable).

Les déploiements inactifs ne reçoivent pas d'exécutions et ne sont pas considérés comme en conflit lors de la détection des ambiguïtés.

Exécutez plusieurs workers sous le même DEPLOYMENT_NAME pour augmenter le débit. Les exécutions sont réparties entre tous les workers actifs du déploiement.

En production, déployez les workers sous forme de Deployment ou de StatefulSet Kubernetes avec des réplicas pointant vers le même DEPLOYMENT_NAME. La plateforme répartit automatiquement les tâches.

Listez tous les déploiements actifs de votre espace de travail :

from mistralai.client import Mistral

client = Mistral(api_key="your_api_key")

response = client.workflows.deployments.list_deployments()
for deployment in response.deployments:
    print(deployment.name, deployment.is_active)

from mistralai.client import Mistral

client = Mistral(api_key="your_api_key")

response = client.workflows.deployments.list_deployments()
for deployment in response.deployments:
    print(deployment.name, deployment.is_active)

Transmettez workflow_name pour filtrer par workflow, ou active_only=false pour inclure les déploiements inactifs.

Inspectez un déploiement spécifique et ses workers individuels :

deployment = client.workflows.deployments.get_deployment(name="invoice-service")
print(deployment.name, deployment.is_active)
for worker in deployment.workers:
    print(worker.name, worker.updated_at)

deployment = client.workflows.deployments.get_deployment(name="invoice-service")
print(deployment.name, deployment.is_active)
for worker in deployment.workers:
    print(worker.name, worker.updated_at)

Aller plus loin

• Vue d'ensemble des déploiements auto-hébergés
• Déploiements managés pour les workflows
• Déploiements durcis
• Secrets Manager