Skip to main content
Once a model is registered, shipping a change is a short loop: edit, test locally, bump the version, publish, deploy. You register a model only once; from then on you publish and deploy releases.

​
The loop

1

Edit

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

Test locally

Build and run the workspace, then connect from the Reactor Sandbox. This is the fastest feedback loop, before anything ships.
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.
reactor.yaml
4

Publish and deploy

Both commands read the tag from reactor.yaml. Publish ships the image. Pass --weights <path> only when the checkpoint changed; otherwise the deploy reuses the previous release’s bundle 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. Publish without --weights and 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: a description tweak, a CPU/memory bump, or a visibility flip. Edit reactor.yaml and reapply it with reactor model update:
Update is spec-driven by default: the entire mutable surface (description, resources, extra-args) is rebuilt from reactor.yaml. Anything you remove from the file is cleared on the server. public is the exception: leave it out and the model keeps the visibility it already has. For status- or visibility-only changes that should ignore the spec entirely, use the targeted flags:
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

Publish a release

What publish builds, pushes, and uploads.

Check status

Confirm where each release stands.