Skip to main content
Publishing prepares a release. 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 you pass --weights

Without --weights <path>, publish skips the weights step and the deploy reuses the previously deployed release’s bundle. Weights change less often than code, so this is the common path.
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 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). 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 finally writes the manifest 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. 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. The common path is automatic: publish without --weights and, at deploy time, Reactor reuses the most recently deployed release’s bundle server-side. Nothing is read or uploaded from your machine, and the deploy prints a notice naming the source release so a forgotten upload is easy to spot. 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> or with --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 prints one row per artifact (size, last-modified, path), plus a trailer summarising the total size and whether the bundle is complete. weights show summarises the SHA-256 manifest itself and is useful when a partner needs to confirm exactly which content hash a release is pinned to.

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