> ## Documentation Index > Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The catalog of every model — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it. > Fastest path to a working app: `npx create-reactor-app my-app --model=` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/; Python uses the base reactor-sdk package. > Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code. > Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp. # Publish a release > Build the image, push it, and optionally upload weights for a release in one command. Publishing prepares a release. Run it from inside your workspace: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model publish ``` In one command it: Builds your model into a container image defined by the `build:` block in your `reactor.yaml` and pushes it to Reactor. Two optional alternatives: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} # Skip the build and use a prebuilt image reactor model publish --source my-image:tag # Or build a hand-edited Dockerfile instead (see [Build the image](/deploy/platform/build#hand-edited-dockerfile)) reactor model publish -f path/to/Dockerfile ``` When the build needs a credential, pass it with [`--build-secret`](/deploy/platform/build#build-secrets): ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model publish --build-secret id=github_token,env=GITHUB_TOKEN ``` Without `--weights `, 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. Sessions start reaching the release after you [deploy](/deploy/platform/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: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model publish --weights ./checkpoints/ ``` 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](#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/`): ```yaml reactor.yaml theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} runtime: import: model:MyModel weights_path: ./weights ``` ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} # Inside the workspace: identity + path inferred from reactor.yaml. reactor weights upload # Or be explicit when you're outside the workspace: reactor weights upload my-awesome-model:v1.0.0 ./weights/ ``` `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](https://docs.reactor.inc/deploy/development/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`: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor weights upload my-model:v1.1.0 --from v1.0.0 ``` 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 `` 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: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor weights list # human-readable listing for the workspace release reactor weights list my-model:v1.0.0 --json | jq .files reactor weights show # bundle manifest summary (requires the bundle to be complete) ``` `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 ``` ✓ Published Model: my-awesome-model Release: v1.0.0 ``` ## 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: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model publish my-awesome-model:v1.0.0 ``` The same goes for the build source and weights path: | Flag | Description | | ---------------------------- | ------------------------------------------------------------------------------- | | `--source ` | Use an existing local or remote image ref instead of building | | `-f` / `--dockerfile ` | Build a hand-edited Dockerfile instead of the `build:` block | | `--no-dockerfile` | Build from `reactor.yaml` when a Dockerfile sits in the workspace | | `--build-secret ` | Forward a build secret to the image build (repeatable, ignored with `--source`) | | `--weights ` | Upload weights from this file or directory (omit to skip the step) | | `--force` | Re-upload weights even when the server already has a matching bundle | | `--workers ` | Parallel workers for bundle hashing and per-file uploads | | `--dry-run` | Print the resolved plan; no side effects | ## 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 ` is passed. The image stays in your account's ECR namespace. Weights stream directly to object storage without transiting the Reactor backend. ## Next Activate a published release (or roll back to a previous one). See whether the image and weights are in place.