Mistral will run workflow workers from GitHub. The egress switch matters

THE SIGNAL IN ONE SENTENCE

A managed worker is still your code wearing somebody else's pager. Mistral released Managed Deployments in public preview on October 9. Point the service at a GitHub repository and Mistral Cloud will clone the code, build a Docker image, start the workflow worker, scale it and manage its lifecycle. Teams can create, update, stop, start, restart, redeploy and delete deployments from AI Studio or the API. That removes a fine pile of infrastructure chores. It does not remove the production questions. It moves them. The repository becomes the build source. The Dockerfile becomes the operating contract. The managed service account becomes the worker's identity. Workspace secrets become the bridge to external systems. Network egress becomes the line between a useful automation and a container that can phone half the internet. Mistral includes a control to create deployments with network egress blocked during both build and runtime. That may be the most important switch in the release. An AI workflow worker is not merely a model call. It is software that can receive an execution, read inputs, call APIs, reach databases or connectors, transform data and produce an external effect. Put that worker on managed infrastructure and the old security rule remains undefeated: capability follows connectivity and credentials. Blocking egress narrows the blast radius. A worker without arbitrary outbound network access cannot casually send data to an unapproved destination, pull a surprise dependency at runtime or call a service nobody included in the design review. A build without egress cannot fetch packages from the public internet unless the platform provides an approved path or the artifacts are already available. That is both the value and the inconvenience. Many builds expect to download dependencies. Many workflows exist precisely to call external systems. Turning egress off can break the thing you wanted to deploy. Leaving it on can make the worker far more powerful than its product description suggests. The useful decision is not simply on or off. It is an explicit inventory. Which destinations does the build need? Which destinations does the running worker need? Which methods and ports? Which data leaves? Which response comes back? What happens if a destination is unavailable or compromised? Can the workflow complete with no public internet at all? If the answer is one package registry and two business APIs, the network policy should look like one package registry and two business APIs. A universal green light is not a design. Mistral's public documentation currently makes the broad binary control clear in the release note. It does not publish a destination-level egress allowlist in the managed-deployment guide we reviewed. Teams should verify the exact enforcement model in their account before treating the switch as fine-grained network policy. The source path deserves the same precision. Managed Deployments supports repositories hosted on github.com, including public and private repositories. The documentation calls this public GitHub, meaning the hosted GitHub service, not only publicly visible code. GitLab and GitHub Enterprise are not yet supported. Private repository access flows through the Mistral GitHub App. An organization owner installs the app and chooses the repositories it may access. The deployment creator also connects GitHub in Studio. Only repositories where the app is installed and the user has access should appear in the deployment dialog. That is a better shape than handing a general personal access token to a build system. It still needs review. Keep the app's repository selection narrow. Confirm who can change the installed-repository list. Review the app's permissions when Mistral changes them. Remove access when a repository stops being deployed. Treat a private repository as sensitive even when its application code looks ordinary, because build files and history often reveal internal packages, service names and operating assumptions. The build contract is direct. Mistral Cloud reads the Dockerfile, builds an image and runs that image as-is. The Dockerfile's entry point or command must start the workflow worker. If the worker lives in a subdirectory, the configured build directory has to contain everything the Dockerfile copies. The absence of platform magic is welcome. It is also unforgiving. A floating base image, unpinned package or mutable branch can change the artifact without changing the team's intention. Mistral's getting-started guide shows a branch such as main as the revision. When a team pushes changes and redeploys, the service resolves the branch to its latest commit, rebuilds the image and restarts the worker. For a demonstration, that is delightfully simple. For production, record the exact source commit, Dockerfile hash, base-image digest, dependency lockfile and resulting image digest for every deployment. A branch name explains where the build looked. It does not prove what it found. The same receipt should survive rollback. The reviewed getting-started guide describes pushing to the deployed branch and redeploying the latest commit. It does not document a complete rollback procedure. Before moving a consequential workflow, test how to restore a known image or commit, how long the recovery takes and what happens to executions already in flight. Do not wait for a Friday evening dependency surprise to discover the answer. Worker authentication is cleaner than putting a workspace API key in the repository. Each managed deployment runs under its own service account. Mistral mounts a rotating service-account token into the container as a file and sets MISTRAL_SA_TOKEN_PATH. The Workflows SDK reads the token and picks up rotations. The container must use mistralai-workflows version 3.10 or later. Earlier versions cannot read the service-account token and will not authenticate. This is useful workload identity, not universal least privilege. The service account establishes who the worker is to Mistral. It does not decide what every external secret may access. A workflow that needs another system can bind a workspace secret to an environment variable. Mistral makes the binding available when the worker boots. The sharp edge appears at build time. Mistral also lets a secret binding reach the Docker build as a build argument. Its documentation warns that build arguments are stored in image history and layers, where someone with image access can recover them. It recommends rotatable credentials and avoiding high-value secrets during builds. That warning belongs on the deployment form, not in the footnotes. Use build-time credentials only when necessary. Prefer short-lived, narrowly scoped access to a private package registry. Never assume an environment variable becomes secret merely because its name contains TOKEN. Inspect the built image history. Rotate the credential after a test. Confirm which people and services can access the image. Runtime secret rotation has another operational catch. Changing a secret's value does not automatically restart the worker. The running worker keeps the value it read at boot. Mistral says teams must restart the deployment manually for now. That means secret rotation is a two-part procedure: change the value, then restart and verify every worker. A dashboard that shows only the new secret record can create false confidence while old processes keep using the old credential. Registration hardening is a separate control from network egress. Mistral's release note uses the phrase hardened deployments for the option to block egress. The detailed workflow documentation also uses hardening to mean restricting which users and service accounts may register workflow definitions under a deployment name. Those are different jobs. Network restriction limits where a worker can connect. Registration hardening limits who can place a worker behind a deployment identity. The second control matters because multiple implementations registered under the same workflow name can make execution routing unpredictable. Mistral says new managed deployments created in Studio default to registration hardening and automatically pin the managed runtime's service account, with an explicit opt-out. Managed deployments created through other clients currently default to unhardened unless hardening is requested. That client difference is easy to miss. A team can believe managed deployments are hardened by default because Studio behaves that way, then create one through another client and get a different result. Make the expected state part of the deployment test. Confirm the deployment owner, hardening flag, authorized pins, runtime service account and registered workflow definitions after creation. Do not infer control state from the path used last time. Hardening is not code review. Mistral explicitly says it limits registration to authorized principals but does not validate the code they submit or replace protection of their credentials. A properly pinned service account can still run a bad image. The managed-service limits are equally concrete. Public preview requires a paid plan. Mistral documents a concurrent cap of three managed deployments for pay-as-you-go organizations and ten for Enterprise, with higher caps available through support. The Free plan gets none. Mistral chooses the instance size. Every managed worker currently gets the same size, and per-deployment CPU and memory metrics are not exposed. That is a meaningful gap for capacity planning and incident diagnosis. A worker can look healthy while approaching a resource ceiling the operator cannot see directly. Teams should load-test representative inputs, record latency and failure behavior, inspect build and worker logs, and define a fallback before production traffic arrives. The worker region is also fixed in the current documentation. Managed workers run in nl-north-1 in the Netherlands. Organizations with residency, latency or sector-specific requirements should verify whether that location fits the workload and every dataset it touches. None of these limits makes the preview useless. The product solves a real problem. A small team can move a workflow from a laptop to an operated worker without first becoming a Kubernetes department. The managed service account is better than a copied API key. Visible build and worker logs are better than a black box. Start, stop and redeploy controls make ordinary operations approachable. The feature becomes trustworthy when convenience travels with receipts. Before launch, capture the exact source commit, image digest, Dockerfile, dependency locks, GitHub App access, service-account identity, registration pins, secret bindings, egress state, region, quota and expected resource envelope. Run the image locally. Test failure during build, startup, secret rotation and external API loss. Verify that stopping a worker actually removes it from execution routing. Prove the rollback path. Then watch the boring numbers: successful executions, retries, cold starts, queue time, external calls, rejected registrations, secret age, deployment restarts and changes in source or image identity. The plain signal is not that Mistral made infrastructure disappear. It turned infrastructure into a managed boundary. The repository supplies the worker. The Dockerfile shapes it. The service account names it. Secrets empower it. Egress decides how far it can reach. Logs show part of what happened. Your receipts still have to explain the rest.