Deployments
A deployment is the running instance of what you built: an agent, a workflow, or an app, executing and reachable by its users. Studio offers three ways to run it:
- Local development: you run the worker on your own machine, against the platform. For iterating, not for production.
- Self-hosted: you run the workers on your own infrastructure (virtual machines, Kubernetes, your private cloud), and Mistral orchestrates them.
- Managed: Mistral runs everything. You point Studio at your code, and Mistral Cloud builds, runs, scales, and recovers it. Nothing to host.
Deploying a model is a different decision, covered under Inference > Deployment.
To deploy your first workflow to Mistral Cloud, follow Quickstart: deploy a workflow to Mistral.
What a deployment is
Across agents, workflows, and apps, a deployment answers the same three questions:
- Where does it run? On your machine (local), on infrastructure you operate (self-hosted), or on Mistral Cloud (managed).
- How is it reached? Through the platform: executions, triggers, and webhooks route to the deployment, and Studio observes it.
- Who is it for? The users, services, and schedules that call it.
Every deployment is named. The name is how the platform routes work to the right running instance, and how you find it in the console, the API, and your traces.
Local, self-hosted, managed
| Local development | Self-hosted | Managed | |
|---|---|---|---|
| Where the code runs | Your machine | Your infrastructure | Mistral Cloud |
| Who operates it | You | You | Mistral |
| What the platform provides | Orchestration: routing, durability, observability | Orchestration: routing, durability, scaling across your workloads | Build, run, scale, recover |
| Authentication | Your workspace API key | Workspace API key or service account | A service-account token is injected; no API key in your code |
| Best for | Iterating on a workflow or agent | Data residency, private networks, existing compute, cost control | Shipping fast, with nothing to operate |
Local and self-hosted differ in where the code runs, not how it runs: the same worker code and the same deployment name work in both. Self-hosted and managed differ in who operates the infrastructure.
Start local while you build. Move to self-hosted when you need control over where the code runs. Move to managed when you want nothing to operate. The deployment concepts, the routing, and the observability stay the same.
Self-hosting a deployment is not the same as running the whole Studio platform on your own premises. See the on-premises documentation.
What stays the same
Whichever way you run, the lifecycle is the same:
- Build or start: package your code (managed), or start your workloads (local and self-hosted).
- Deploy: the deployment registers what it can run and becomes active.
- Run: executions, triggers, and webhooks route to it.
- Update: ship a new version; the platform rolls it out.
- Observe: executions, logs, and traces are visible in Studio.
Secrets, environment variables, and permissions behave the same way in all three modes: credentials come from Secrets Manager, and access follows your workspace roles.
Access control
For workflows, you can restrict which users and service accounts can register workers on a deployment. This is called a hardened deployment. Hardening is required for on-behalf-of workflows, which act with the triggering user's permissions. Managed deployments created in Studio are hardened by default.
Starting points
Pick the path that matches what you want to run:
Or go straight to deploying a specific system: