On October 9, 2026, Mistral added Managed Deployments in public preview. The service runs Workflows on Mistral Cloud infrastructure and requires a paid plan. The announcement lists management through Studio or the API, service-account authentication, logs, and the ability to block outbound networking during build and runtime.
What is actually managed
The technical guide describes building a Docker image from a GitHub repository and running the container according to its ENTRYPOINT or CMD. The worker receives an automatically rotating service-account token. Support requires Workflows SDK 3.10 or later. The documented region is nl-north-1 in the Netherlands.
Our editorial interpretation is that the service transfers infrastructure tasks without removing responsibility for the application. A team still defines what its workflow does, which data it uses, and what an acceptable result looks like. A successfully started container and a correctly completed task represent different levels of verification.
For a hypothetical assistant processing incoming enquiries, that means separating message receipt, data extraction, response drafting, and permission to send. The managed worker provides the execution environment; the team must define the boundaries between those steps.
Limits belong in the architecture
The quota page lists three concurrently running managed deployments for Pay-as-you-go and ten for Enterprise; the free plan has none. The platform selects worker size. Separate per-deployment CPU and memory metrics are not yet exposed. Preview limits may change.
Those figures do not automatically establish how many customer tasks can be handled. Deployment count and workload inside a deployment are different quantities. A useful local evaluation would track completion time, failures, and accumulated queue length using representative tasks. SIExpo has not conducted that experiment and makes no capacity promise.
Who can register a workflow
The hardened-deployment guide restricts registration to authorized users and service accounts. New managed deployments created through Studio are hardened by default, with an opt-out. Other clients can have different initial behavior. Ownership of a deployment does not itself authorize worker registration.
The distinction has practical value. In our example, two processes should not accidentally present themselves as the same production workflow without the team knowing which implementation will receive execution. Identity management needs a separate review rather than an assumption based on a project's name.
Secrets have their own lifecycle
The secrets documentation describes binding a secret from the same workspace to an environment variable. Changing its value does not automatically restart the worker. It also warns that Docker build arguments can remain in image history and layers. A sensitive value should therefore not be considered protected merely because it was supplied during a build.
This raises a concrete operational question: which workers already use the new value, and which still use the old one? A team's change plan should include observation of actual execution. That lesson follows from the documented behavior without assuming an additional capability for automatically rotating third-party credentials.
Observability follows the task's path
The separate observability guide describes OpenTelemetry logs, traces, and metrics. Traces contain timings and errors, while logs can be examined for a specific execution. Export to a team's own system is possible; redirected signals will not appear in Studio if they are no longer sent to Mistral's platform.
This gives readers a reason to seek a coherent record: when a task began, which step stopped, and what result was saved. A green container status alone cannot tell that story. The public preview offers a concrete new deployment option, but its value should be assessed through an actual workflow rather than a promise of automation without human organization.
