Skip to main content
reactor model deploy publishes a workspace automatically. Use reactor model publish separately when you want to stage a release before activation or pass publish-specific options. Run it from inside your workspace:
In one command it:
1

Builds and pushes the image

Builds your model into a container image defined by the build: block in your reactor.yaml and pushes it to Reactor. Two optional alternatives:
When the build needs a credential, pass it with --build-secret:
2

Uploads weights when a source is set

Publish uploads weights from --weights <path>, or from runtime.weights_path when reactor.yaml declares one. With no source, the deploy reuses the previous release’s bundle.
3

Stages the release

Sessions start reaching the release after you deploy it.
The model name and release tag come from your reactor.yaml, so you never type them.

​
Weights

The image carries your code and dependencies; Reactor mounts the weights into the container at runtime. Publish uploads them when you pass an explicit path:
Without --weights, publish uses runtime.weights_path when your reactor.yaml declares one. When neither is set, publish skips the weights step and the deploy carries the previously deployed release’s bundle over server-side (see Carry over weights from a previous release). --no-weights skips the step even when reactor.yaml declares a path. Use it on a machine that holds no weights, such as a CI agent that publishes the image alone. --weights also takes an hf://org/repo[@rev] reference. Publish resolves it to a commit sha and pins that on the release, with no upload. The weights come from Hugging Face at startup instead. The pinned sha keeps the release on the same weights even if the repo moves later. See reactor model publish. To ship weights separately (training still running at publish time, or a checkpoint update for an existing release), use reactor weights upload. Both arguments are optional inside a workspace: the identity comes from reactor.yaml, and the path defaults to runtime.weights_path from the same file (else ./weights/):
reactor.yaml
reactor weights upload walks a directory tree, computes a SHA-256 manifest, uploads every file, and sends the manifest to the server. The server writes it as the bundle-complete sentinel. Large files go up as multipart transfers with parallel per-file uploads (--workers tunes the parallelism); transient failures are retried with backoff, and an interrupted upload resumes where it left off on the next run. When a previous bundle with identical content already exists, the upload is short-circuited; pass --force to re-upload unconditionally. Upload also takes an hf://org/repo[@rev] source, as the path, as --weights, or from runtime.weights_path. The CLI pins the commit and records a manifest of the hub files. No weight bytes leave your machine, because the platform downloads the files from Hugging Face. See reactor weights upload.
See Weights for how the same files resolve locally and in production.

​
Carry over weights from a previous release

When a new release ships the same weights as a previous one (a code-only change, a config tweak, a rebuilt image with no checkpoint update), the bundle does not need to be on disk at all. When you deploy without new weights, Reactor reuses the most recently deployed release’s bundle server-side. Nothing is read or uploaded from your machine. The deploy prints a notice that names the source release. When the source you want is a different release, carry it over explicitly with --from on reactor weights upload:
This is the right form for CI machines that lack the checkpoints. The carry-over happens entirely server-side, so --from cannot be combined with a local <path>, --weights, or --force. The source release must belong to the same model, carry a different tag from the target, and pass the same semver validation as the target tag.

​
Inspect uploaded weights

Two read-only commands help verify what landed:
weights list takes a model, not a release. It prints one row per bundle version: the release, the file count, the total size, and a shortened digest. weights show takes one release and adds a table of size, digest, and path for every file in the bundle. Use it when a partner needs the exact content hash a release is pinned to. It also accepts a bare tag such as v1.0.0, or a canonical name such as acme/my-model:v1.0.0. Both commands take --json for full digests.

​
Release tag

The release tag comes from your reactor.yaml. It must be a full semver value such as v1.0.0, v1.2.3, or v1.2.3-rc1. The CLI rejects partial values like v1 or 1.2 before anything is built, so bump it to a fresh, increasing value for each release.

​
Success output

​
Specifying the release explicitly

To target a release other than the one in your reactor.yaml, pass it on the command line. The positional argument always wins over the workspace value:
The same goes for the build source and weights path:

​
What publish does

Under the hood, a single publish runs these steps:
  1. Registers the release tag against the model (idempotent).
  2. Mints short-lived ECR push credentials for the partner namespace.
  3. Builds the container image defined by the build: block in reactor.yaml, or from a hand-edited ./Dockerfile when the workspace has one. --source supplies a pre-built image instead.
  4. Pushes the image to the Reactor ECR slot.
  5. Records the digested image ref on the release.
  6. Uploads the weights (parallel per-file uploads + SHA-256 manifest) when --weights <path> or runtime.weights_path gives a local path.
The image stays in your account’s ECR namespace. Weights stream directly to object storage without transiting the Reactor backend.

​
Next

Deploy the release

Activate a published release (or roll back to a previous one).

Check status

See whether the image and weights are in place.