Skip to main content
reactor model deploy is the normal way to ship a workspace. It registers the model when needed, publishes the release, applies the current model settings, and routes client sessions to it.

​
Deploy from a workspace

Run it from your workspace and it reads the model name and release tag from reactor.yaml:
The command builds and pushes the image when the release is not published yet. When the release needs a new weights bundle, publish it with the bundle before deploying:
When the release already has an image, deploy skips the build and push. You can still use reactor model publish separately for CI or staging. When a workspace deploy builds the release, you can pass --build-env and --build-secret to that build. See reactor model deploy. When you have a prebuilt image, pass --source and the deploy publishes it instead of building one. The flag works on a workspace deploy only. See reactor model deploy.

​
Roll back

To roll back, name an earlier published release explicitly. This form does not rebuild the release or apply settings from reactor.yaml. A local deployment.yaml still controls the regional instance plan.
The previously active release stops receiving new sessions; in-flight sessions continue against the version they connected on.

​
Choose a rollout strategy

By default a deploy replaces instances one at a time, so the model keeps serving during the rollout. Pass --strategy replace-all to cut the whole fleet over at once. An idle fleet turns over in seconds. A busy one serves at reduced capacity until the new instances finish loading.
Sessions already in flight keep their full grace period under either strategy.

​
Cut over immediately

--immediate disconnects the model’s live sessions after the rollout starts, so the new release serves in seconds instead of minutes. It implies --strategy replace-all, and the CLI asks you to confirm unless you pass --yes.
--immediate ends every session that is live when it runs. Use it to take a bad release out of service now. Do not use it for a routine deploy.

​
Set the deployment plan

The deployment plan lists which regions to run in and how many instances to run in each. New workspaces use the deployment: block in reactor.yaml. reactor init requests one instance in us-west. The reactor.yaml reference documents every key in that block. Your account needs capacity there before this plan can succeed:
reactor.yaml
If the workspace also has a deployment.yaml, that file takes precedence over the deployment: block. The CLI warns when both declare a plan. Read the command’s Using deployment plan from ... output to check which one applies. Changing the ignored block does not change the deployment. Edit the instances: list to scale out or add regions. Each entry is a region and a count of instances to run there. The GPU is a model attribute you set once in model.resources.gpu, not per entry. To list the names you can use in the region field, run reactor regions. Add --json to get the list as a JSON array for a script.
A deploy with no plan provisions nothing. Your reactor.yaml declares no instances when the instances: list is empty, or the deployment: block is missing. In that case reactor model deploy warns and leaves your per-region capacity unchanged. Set at least one region and count to place the model.
A plan that exceeds your allocated capacity is rejected with a conflict error. Reduce the per-region counts or contact Reactor to raise your allocation. An unknown region or invalid count fails validation; check the names with reactor regions. To check your config before you deploy, run reactor validate. It checks the schema and structure of each file. It does not contact the server, so it does not catch an unknown region or a capacity problem.

​
Weights at deploy time

If the release being deployed has no weights of its own, the deploy reuses the most recently deployed release’s bundle server-side and prints a notice naming the source. When neither the release nor any previously deployed release has weights, the deploy still succeeds and warns you to upload them with reactor weights upload. When a workspace deploy publishes the release, it runs the same weights step as publish. Pass --weights <path>, or an hf://org/repo[@rev] reference, to publish a different source for this release. --no-weights skips the step even when reactor.yaml declares runtime.weights_path. See reactor model deploy.

​
Next

Check status

Confirm the release is live and inspect deployment state.

Quick iteration

The develop, test, ship loop for every release after the first.