> ## 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. # Deploying models > How a model goes from your workspace to live traffic on Reactor. 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 Creates the model record on Reactor. You do this once per model. It reserves the canonical `/` and stores metadata like the accelerator type and any CPU/memory overrides. 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. 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](/deploy/platform/deploy). ## The workspace A **workspace** is any directory tree rooted at a `reactor.yaml` file. `reactor init` scaffolds one for you: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor init my-model ``` At the root is `reactor.yaml`, the single file that declares everything Reactor needs to know about your model (see the [quickstart](/deploy/development/quickstart)). ```yaml reactor.yaml theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} model: name: my-model # registered model (short slug or canonical org/name) version: v1.0.0 # release tag for publish and deploy # ...resource overrides, accelerator, description, etc. runtime: import: model:MyModel config: config.yaml build: runtime_version: "3.2.5" # the reactor-runtime release the image installs ``` 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 `:` 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: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} cd my-model reactor auth login # once per machine reactor model register # once per model reactor model publish --weights ./weights # image + weights (a first release has none to reuse) reactor model deploy # activates that release for traffic ``` Publish builds the image for you. To check that the image builds and boots before publishing, run [`reactor build`](/deploy/platform/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: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model status ``` To see what's actually running right now, as a list of the instances currently serving the model: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model instances ``` To read the recent runtime output of a session or an instance (machine id), pass `-f`/`--follow` to keep tailing live: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor logs ``` ## 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. ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model update # reapply reactor.yaml to the registered model reactor model update --status DEPRECATED # targeted server-side change reactor model delete # destructive, with a typed-name confirmation ``` See [Manage a model](/deploy/platform/manage) for the full mode list and examples. ## Next Get the `reactor` binary on macOS, Linux, or a CI runner. Create the model record so you can publish releases against it.