Skip to main content
Run the v0.13 CLI locally from a directory containing rig.yaml. Ordinary source deployments create managed app releases. For a runnable first project, follow Deploy your first app.

​
Prerequisites

Install the v0.13 CLI, run rig login, and confirm your app has install/start commands, a listening port, and an HTTP health endpoint. Use relative paths and put mutable data outside the managed release directory.

​
1. Create the manifest

Run rig init in your project, then review the generated values. The app name comes from --name or the directory name and is converted to lowercase letters, digits, and dashes, so the deploy accepts it; rig init --name "My App" writes name: my-app. Declare workspace.deployment.strategy: incremental for app releases. Check the canonical manifest reference before deployment.

​
2. Deploy

The CLI prepares a release, installs/builds its code, activates it, and checks affected apps. Keep .rig.lock so later deployments retain project identity and workspace bindings.

​
3. Check the result

Use the actual app name and URL returned by Rigbox. Inspect every app outcome, not just the first URL. Read failed preparation or activation logs with rig app-release logs --workspace my-project --release <RELEASE_ID>.

​
4. Deploy a change

Run rig deploy from the same directory. Incremental activation briefly restarts affected services without replacing the workspace filesystem. Use the development loop, staging, or app rollback.

​
Configure a GitHub repository in the console

Follow Deploy from GitHub. The console retains a reviewed deployment strategy; a manifest strategy must match that selection.

​
How rig deploy resolves a workspace

An explicit --workspace targets a name or ID. Otherwise the CLI reuses the workspace binding in .rig.lock or creates a new workspace. Inspect bindings before reusing a checkout for another environment; specify the target explicitly when uncertain. Inside a workspace, rig deploy deploys into that workspace. It ignores .rig.lock bindings, never creates a workspace, and refuses options that would clone, re-image, or replace the workspace it runs in; see deploying from inside a workspace.

​
The rig.yaml contract

The field reference now lives at rig.yaml. Keep a single canonical manifest per project.

​
Single-app shape

Put name, port, start, and other app fields at the root. See application fields.

​
Multi-app shape

Use a name-keyed apps map with a path for each local app. Do not mix root service fields with apps. Follow multi-app projects.

​
The health contract

Implement a successful HTTP readiness endpoint and declare its path/timeout. See health checks. Incremental service releases currently require HTTP.

​
Deploy modes

Choose explicitly between app releases and workspace images. See deployment strategy.

​
Standard deploy

The v0.13 default source flow is an incremental app release, not a filesystem overlay. See the development loop.

​
Reproducible deploy

reproducible: true selects image deployment when no strategy is explicit. Use reproducible builds.

​
build: is always a command

build: npm run build is valid; Dockerfile/image mapping forms are not. See commands.

​
Local source: freeze dependencies and sync code

This image workflow is described in reproducible builds. Incremental deployment instead prepares code in managed release directories.

​
Git source: deploy the resolved commit

Git source uses the resolved revision; uncommitted local files are not a Git deployment input. See source fields and GitHub Actions.

​
Pre-warm the image with --build-only

Run rig deploy --strategy image --build-only for an image build without deployment. See build caching.

​
When to use which

Use app releases for ordinary code updates and workspace images for a frozen environment.

​
Env, secrets, credentials, params, and visibility

Follow configuration. Generated credentials use a named map; environment metadata remains readable by authorized callers.

​
Blue-green deploys and promotion

See blue-green deployment. Explicit incremental strategy rejects preview/promotion flags.

​
Deploy via the API

Use the native API reference. App releases and workspace image releases are separate APIs; do not use image activation for an app rollback.

​
Next steps

Continue with multi-app projects, configuration, and deployment strategies.