Skip to main content
After the first deployment, shipping a change is a short loop: edit, bump the version, and deploy. The deploy command publishes each new release before it activates it. Testing the change on your own machine first is optional. The step below is there for when you have a GPU to do it on.

​
The loop

1

Edit

Change your model code or swap the weights in your weights directory.
2

Test locally (optional)

With a local GPU, press Ctrl-C in the terminal running reactor run. Then build and run again.
Connect a local client and check that it receives media. Send a command and confirm its effect. Test locally walks through both a browser client and a Python check. A successful build does not test model startup or streaming.
3

Bump the version

Increment model.version in reactor.yaml (for example v1.0.0 to v1.0.1). This is the release tag publish and deploy use. If that release already has an image, deploy reactivates it without rebuilding your changed code.
reactor.yaml
4

Deploy

Deploy reads the tag from reactor.yaml and publishes the image before activation. When the checkpoint changes, run reactor model publish --weights <path> first. With no weights source in reactor.yaml, deploy reuses the bundle from the previous release automatically.

​
Rolling back

To return to an earlier release, deploy it by name. This is the one case where you pass the tag explicitly, since you’re targeting a release other than the one in reactor.yaml:
In-flight sessions finish on the version they connected to. To disconnect them instead, add --immediate. See Cut over immediately.

​
Reuse the previous bundle for code-only changes

If the weights are unchanged between releases (a code-only tweak, a rebuilt image, a config update) the bundle does not need to be on the machine that runs publish. With no --weights and no runtime.weights_path in reactor.yaml, the deploy reuses the most recently deployed release’s bundle server-side, with no local read or upload:
This is the standard form for CI machines that don’t have the checkpoints checked out. To carry over from a release other than the most recently deployed one, name it explicitly with reactor weights upload <model>:<release> --from <source-release>. See Carry over weights from a previous release for details.

​
Changing the spec without re-publishing

Some changes need no new release, such as a description tweak or a resource update. Edit reactor.yaml and reapply it with reactor model update:
Update is spec-driven by default: the entire mutable surface (description, resources, extra-args, and visibility) is rebuilt from reactor.yaml. Anything you remove from the file is cleared on the server. Visibility is the exception. When you omit public, the model keeps its current visibility. To change only the status or make a public model private, use a targeted flag. These flags ignore the spec:
Only Reactor staff can make a private model public. Contact Reactor if you need public access. See Manage a model for the full mode list.

​
Keep versions moving forward

Bump model.version to a fresh, increasing value before each publish so status and rollbacks stay unambiguous. The version must be full semver (v1.0.0, v1.2.3-rc1); the CLI rejects partial values like v1 before anything ships.

​
Next

Deploy a model

Deploy the current workspace or activate an existing release.

Check status

Confirm where each release stands.