Skip to main content
A model reaches live traffic in three phases. You register it once, publish a release whenever the code or weights change, and deploy a release to start serving it.

​
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 you pass --weights (otherwise the deploy reuses the most recently deployed release’s bundle). 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. An optional deployment.yaml pins per-region instance counts. See Deploy a release.

​
The workspace

A workspace is any directory tree rooted at a reactor.yaml file. reactor init scaffolds one for you:
At the root is reactor.yaml, the single file that declares everything Reactor needs to know about your model (see the quickstart).
reactor.yaml
Inside a workspace, the CLI already knows which model you mean. Every reactor model and reactor weights command finds the nearest reactor.yaml and takes the model name and release tag from it, so day-to-day you just run reactor model publish or 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

With a workspace in place, the full first-release flow is four commands:
Publish builds the image for you. To check that the image builds and boots before publishing, run reactor build first. 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:
To see what’s actually running right now, as a list of the instances currently serving the model:
To read the recent runtime output of a session or an instance (machine id), pass -f/--follow to keep tailing live:

​
Change or remove a model

A registered model is not frozen: you can edit reactor.yaml and reapply it, or toggle status/visibility flags directly. When you no longer need a model, delete it.
See Manage a model for the full mode list and examples.

​
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.