Introduction

A self-hosted deployment runs your code on infrastructure you operate (virtual machines, Kubernetes, your private cloud). You start the workloads yourself, and Mistral orchestrates them: execution routing, durability, and scaling stay with the platform.

Local development and self-hosting run the same code the same way. The difference is where the workload runs:

• Local development: the workload runs on your machine, for iterating. It registers against the platform like any other deployment, so you can trigger and observe it in Studio. It stops when you close your laptop.
• Self-hosted: the workload runs on infrastructure you operate, continuously. This is the production form of running your own code.

The same deployment name, the same code, and the same commands work in both. To move a deployment from your laptop to your infrastructure, start the same workload there. You do not change the code.

Self-hosting is a decision you make for running in production. While you build (typically with a coding agent on your machine), you run a local deployment for testing and iterating. Local and self-hosted run the same code the same way; the self-hosted page of each system covers what changes when you move to production infrastructure.

Self-host when you need control over where your code runs:

• Data residency: keep execution inside a region or a network you control.
• Private connectivity: reach internal APIs and databases that Mistral Cloud cannot.
• Existing compute: use Kubernetes clusters, GPUs, or capacity you already pay for.
• Cost control: run steady workloads on infrastructure you own.

If none of these apply, use managed deployments instead: the deployment concepts, routing, and observability are the same, and there is nothing to operate.

Apps run on Mistral Cloud only: there is no self-hosted path for apps. Deploy an app with managed deployments for apps.

Your workloads connect to Mistral over the API, and the platform keeps:

• Routing: work goes to the deployment that owns it.
• Durability: state survives workload crashes and restarts.
• Scaling: run more workloads under the same deployment to increase throughput; the platform load-balances tasks across them.
• Observability: executions, logs, and traces are visible in Studio.

Your workloads authenticate with a workspace API key, or with a service account, including through workload identity federation. Workload identity lets a workload in your cluster authenticate without a long-lived key.

Configure environment variables in the workload's environment. For credentials, use the workspace Secrets Manager and resolve references at startup, so no secret value is hardcoded in your code.

Hardened deployments restrict which users and service accounts can register workflows on a deployment. Hardening is required for on-behalf-of workflows, which act with the triggering user's permissions.