Deploy apps with managed deployments

mistral deploy builds an app from a pushed Git commit and runs it on Mistral's managed infrastructure. The platform clones the commit and builds the modules declared in mistral.json. This page describes how a managed app deployment works. For the step-by-step procedure, see Deploy an app.

• Sign in with mistral login. Without a login session, mistral deploy uses MISTRAL_API_KEY, as Deploy with an API key describes.
• Configure a GitHub repository as a Git remote named origin, and commit and push the app. The working tree must be clean, including untracked files.
• Connect GitHub to your Mistral account, and install the Mistral GitHub app on the repository. The platform clones the commit through this app, public repositories included. The CLI checks both before it creates anything. On a terminal, it offers to open the GitHub page that sets them up, and continues after you finish there. Elsewhere, it stops and prints the page's link.
• Commit each module's Dockerfile at the build path configured in mistral.json. The CLI checks that these files exist in the commit being deployed.

If the commit was pushed from another machine, run git fetch origin so the CLI can see a remote branch containing it. To deploy code that isn't on GitHub, use mistral deploy --from-disk, as Deploy from disk describes.

On a terminal, the CLI prompts for the organization and workspace, starting on the ones mistral login selected. It skips a prompt when you have only one choice. --organization and --workspace take an ID or a name.

A new app must belong to a workspace. If you omit --workspace, the CLI uses your only available workspace or prompts you to choose when several are available. Use --name my-app to choose the name for a new app: 1 to 63 lowercase letters, digits, and hyphens. Otherwise, the CLI derives the name from the project directory.

Before it creates or builds anything, the CLI prints the organization and workspace it's deploying to. It warns when a target saved in mistral.json isn't the organization and workspace you're signed in to. The command creates the app and any missing modules, builds and deploys each app module in the production environment, and waits for the deployment runs to finish. No flag selects another environment.

When it finishes, it prints the app's URL, any MCP server URLs, the organization and workspace, and a link to the app in Studio, which switches Studio to that organization and workspace.

The first deployment writes a deployment block to mistral.json with the organization, optional workspace, and app IDs, so other clones and CI deploy to the same app. On a terminal, the CLI offers to commit mistral.json and push it to your branch, then builds that commit. --yes does this without asking, for example from CI or an agent. Without a terminal or --yes, commit and push it yourself: the next deployment refuses a checkout with uncommitted changes.

The binding is saved as soon as the app is created, even if a later build fails. Keep it when you fix and retry that deployment.

Later deployments reuse the saved target. Organization or workspace flags that conflict with it are rejected. To create a separate app, remove the deployment block, commit and push that change, then deploy to the new destination.

mistral deploy also deploys the worker the workflows capability adds, as a managed workflows deployment, and points the API at it. An app can have one worker. The worker deploys at the same time as the other modules, so a worker that fails doesn't stop them going out, but the command still exits with an error.

The first deploy creates the workflows deployment hardened, so only its own managed worker can register on it and its workflows can act on behalf of the user who runs them. A deployment created by an earlier version of the CLI stays unhardened. To harden it, stop it in Studio, harden it from its settings, then deploy again.

--json disables interactive prompts and writes a single JSON report to stdout, with progress on stderr:

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

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

With a mistral login session and no saved deployment target, --organization is required when running without a terminal or with --json. Pass --workspace too if the organization has more than one workspace available to you. A saved target can be reused without these flags.

Without a login session, the command uses an API key, as Deploy with an API key describes.

The report includes the commit, the organization and workspace IDs and names, the app's URL, its MCP server URLs, a studioUrl linking to the app in Studio, and each module's outcome. A failure can occur after other modules have deployed; inspect the reported outcomes before retrying.

Without a mistral login session, mistral deploy uses the API key in MISTRAL_API_KEY, or one saved with mistral login --api-key. A key belongs to one workspace, so the command deploys there and needs neither --organization nor --workspace. It fails when a flag or the target saved in mistral.json names another organization or workspace. When you're signed in, the CLI uses your session even if MISTRAL_API_KEY is set.

To deploy from CI:

1. Deploy once from your machine, then commit and push mistral.json. The job deploys to the target saved there.
2. Use a key created by a user in the app's workspace. The platform refuses a key that doesn't belong to a user, such as a service account key.
3. Give the key Private and shared connectors access. The platform clones the repository with the GitHub connection of the user who created the key, and the CLI checks that connection through the key.
4. Store the key as a CI secret, expose it to the job as MISTRAL_API_KEY, and run mistral deploy --yes.

mistral apps publish and mistral apps unpublish don't accept an API key. Run them after mistral login.

Your organization's plan sets how many apps it can have:

Apps in every workspace of the organization count toward the limit; deleted apps don't. On a plan with a limit of 0, creating an app fails with Your plan does not include Apps. To turn on pay-as-you-go, see Subscriptions. After the organization reaches its limit, delete an app to free a slot.

Each app can have up to three frontends and backends in total. Workers don't count toward this limit.

• An app can have one managed database, Postgres 17. The first deploy creates it, and every service gets its connection settings.
• Container modules are rejected because this command builds from Git. Deploy those through CI.
• Existing modules get their port, routes, and lifecycle commands updated from mistral.json, but not their type. If the type differs, the CLI warns and the platform's type still applies. Configure environment variables and secrets separately on the platform.

For the complete command and flag list, see the CLI reference.