reactor model deploy performs these phases for you.
The three phases
1
Register
Creates the model record on Reactor. You do this once per model. It reserves the canonical
<org>/<name> and stores metadata like the accelerator type and any CPU/memory overrides.2
Publish
Prepares a single versioned release: builds and pushes the container image, and uploads the
weights when
--weights or reactor.yaml’s runtime.weights_path names one. When neither is
set, the deploy reuses the bundle from the most recently deployed release.
It stages everything the release needs but does not serve traffic on its own.3
Deploy
Activates a published release so client sessions route to it. Deploying a different release is
also how you roll back. The
deployment: block in reactor.yaml sets which regions to run in
and how many instances to run in each. See
Deploy a release.The workspace
A workspace is any directory tree rooted at areactor.yaml file. reactor init scaffolds one
for you:
reactor.yaml always names the model as <org>/<name>. A bare name takes the org
slug of your current credential, read live from the Reactor API. reactor init acme/my-model
writes the full name instead. See reactor init.
At the root is reactor.yaml, the single file that declares everything Reactor needs to know about
your model (see the quickstart).
The reactor.yaml reference documents every key the file accepts.
In this example, replace <runtime-version> with the value that reactor init generated in your workspace.
reactor.yaml
reactor model and
reactor weights command finds the nearest reactor.yaml and takes the model name and release tag
from it. For the usual deployment flow, run reactor model deploy with no arguments.
You only spell out <model>:<release> in two situations: to target a release other than the one on
disk (rolling back to a previous version, for example), or when you’re outside a workspace. An
explicit argument always takes precedence. When it names a different model than the surrounding
reactor.yaml, the CLI stops with an error, so a typo cannot touch the wrong model.
The end-to-end flow
Before deployment, check your account access and the deployment plan. The plan needs available capacity in the selected regions. Local development works without deployment access. Reviewmodel.resources.gpu in reactor.yaml too. The scaffold requests one NVIDIA_B200 for
deployment, even though its sample model runs locally on a CPU. Choose resources your model needs
and your account can use. Run reactor gpu ls to list supported GPU types.
From the workspace, authenticate and deploy:
reactor build, then reactor run. Connect a client and verify media and
commands as described in the quickstart.
When a release needs a new weights bundle, run reactor model publish --weights <path> before
deploying it.
model.version is the release tag. It must be a full semver value such as v1.0.0 or v1.2.3-rc1.
Bump it for each new release so every publish lands on a fresh tag.
Inspect a release
To check whether each component of the release is in place (registered, image pushed, weights uploaded, deployed) and what to run next when something is missing:reactor.yaml, run
reactor logs. Narrow it to a single session or instance with
--session or --instance. Pass -f/--follow to keep the stream open:
org/name and authentication. Omit
the client’s local option. Confirm that the deployed model sends media and responds to a command.
Publishing an image alone does not prove that an instance loaded the model or can serve a session.
Change or remove a model
A registered model is not frozen. You can editreactor.yaml and reapply it. You can also change
its status or visibility. Only Reactor staff can make a private model public. When you no longer
need a model, delete it.
Next
Install the CLI
Get the
reactor binary on macOS, Linux, or a CI runner.Register a model
Create the model record so you can publish releases against it.