Skip to main content
The rig CLI (and its rigbox alias — the same binary) is the primary way to deploy and operate Rigbox from a terminal. It is pre-installed in every workspace VM, and you can install it on your local machine too. This page is the command reference. It is organised as:

Install & authenticate

Get the binary and log in.

Global flags

Output formats, JMESPath queries, scripted input, and rig api.

Deploy & rig.yaml

rig deploy, .env loading, and the full manifest schema.

Command groups

workspace, app, snapshot, volume, build/release/rollback, and more.

Install

Inside a workspace

The CLI is already installed in every Rigbox workspace. Open a terminal and run:
Inside a workspace, rig automatically switches into workspace-scoped mode (see Runtime modes). You do not need to log in, and account-wide commands are intentionally hidden.

On your local machine

Install the latest release with one command:
The installer detects your OS and CPU, downloads the latest release, and installs both rig and rigbox to $HOME/.local/bin. Confirm with rig --version.

Pin a version or change the install directory

For CI or reproducibility, the installer honours two environment variables:
The env vars must sit on the bash that runs the script — not on the curl. In a pipeline, RIG_VERSION=… curl … | bash would set them on curl and the installer would still see the defaults.

Shell completions

To remove the local install entirely, use rig uninstall (add --purge-config to also drop saved credentials).

Authentication

Log in (local machine)

This opens your browser for OAuth and stores the token locally. Two non-interactive variants exist for headless environments:
rig logout removes saved credentials (--purge also clears legacy config paths). rig whoami prints the current user and workspace.
External CLI configuration is stored in ~/.rigbox/config.json, including your auth token and persisted defaults.

API keys

API keys (rb_…) are full-account credentials, shown once at creation and stored hash-only:

Runtime modes

The CLI behaves differently depending on where it runs: Inside a workspace, rig detects /etc/rigbox/workspace.json and talks to the VM-local bridge at http://172.16.0.1:9090/rig/v1. No bearer token is sent — the bridge resolves your workspace from the VM’s source IP, so editing local config cannot switch identity. Account-wide commands (login, most workspace subcommands, template, recipe, ssh) are hidden in this mode; deploy, app, snapshot, volume, tools, and proxy helpers remain available.

Global flags

Every command accepts these global flags (they work before or after the subcommand):

Persisted defaults

Raw API access

rig api sends an authenticated request to any Rigbox API path, reusing your stored credentials:

Deploy

rig deploy is the core workflow. It reads a rig.yaml in the project directory, rsyncs your source into a workspace VM, runs the install/build steps, and brings the app up as a managed systemd unit reachable at <slug>.rigbox.dev.
When --workspace is unset, deploy reuses the workspace bound in .rig.lock, or spawns a fresh one. rig deploy --prune-stale drops .rig.lock bindings to workspaces that no longer exist, then exits without deploying.
rig.yaml is the source of truth. A redeploy re-applies everything declared in it — including visibility, limits, and volumes — so transient CLI/UI edits get overwritten on the next deploy.

Loading .env files

Deploy auto-loads dotenv files from the project directory and merges them into the environment used to resolve secrets: and env:. Disable with --no-env-file.
With --stage <name> (or $RIG_ENV), deploy loads stage-specific files. Precedence, highest to lowest:
  1. real shell environment
  2. .env.<stage>.local
  3. .env.local
  4. .env.<stage>
  5. .env

Blue-green and promote

Stage a change, verify it, then swap production traffic atomically — two flavors:
--promote requires --bluegreen. Use preview for production service hosts (zero-downtime, swaps to a new VM, same ports); use <suffix> for a workspace people actively work in (same VM, so SSH sessions and state survive). See Blue-green deploys and promotion for the full flow, the boundary, and rollback.

Scaffold a manifest


The rig.yaml manifest

rig.yaml describes the app(s) to deploy. Multi-word fields use camelCase primarily, with snake_case accepted as an alias. There are two surface forms.

Single-app form

Three fields are required: name, port, and start (with install needed in practice for anything with dependencies).
secrets: values are read from your local shell at deploy time. Deploy fails fast (before anything ships) if a non-optional secret is unset, so you can export them all in one go.

Field reference

Each params: entry accepts: key (required), label, description, type (string default, number, boolean, secret, select, email, url, textarea), default, required, sensitive, options (for select: {value, label}), group, order, helpUrl, validationPattern, and envVar (surface the value as this env var on the unit — without it the value lands in metadata but the process can’t see it).

Multi-app form

A top-level apps: map switches to project form: an optional workspace: envelope plus a name-keyed map of apps. Each app is either a local build context (path:) or a published recipe (ref:).
workspace.volumes is an authoring convenience: deploy expands each app reference into the existing per-app run volume payload. Apps must still opt in explicitly; declaring a workspace volume alone does not mount it everywhere. Every entry under apps: accepts the same inline fields as the single-app form (minus name, which is the map key). dependsOn is topo-sorted across siblings. Mixing single-app keys (start/port at the top level) with apps: is rejected.

Command reference

Placeholders use <WORKSPACE> (a name or ws-… id) and <APP> (a name or app-… id). Most lifecycle commands accept either form.

Account

workspace

Manage workspace lifecycle and configuration.
rig workspace rm permanently destroys the VM and its disk. Back up anything important first.

app

Manage apps inside a workspace. Inside a VM these are always scoped to the current workspace.
rig app new --kind is service (long-lived server at a subdomain) or cli (interactive binary over SSH, no Caddy route). See Catalog Apps.

snapshot

See the Snapshots guide for the full model.

volume

Manage persistent volumes that survive across deploys and reboots.
You can also declare volumes in rig.yaml under workspace.volumes and opt apps in with volumes: [data] so a deploy provisions and mounts them automatically. Full app-local volumes: specs remain supported for one-off cases.
volume commands back the PersistentVolumes server feature. They may be unavailable until that feature flag is enabled for your account.

build, release, rollback

Reproducible deploys separate build (produce an immutable image artifact) from run (activate a release that pins an image digest).
build, release, and rollback back the ReproducibleBuilds server feature. They may be unavailable until that feature flag is enabled for your account.

ssh

Manage SSH public keys for your account.
A handy one-liner combines ssh-info with your SSH client:
See the SSH Access guide for the full connection model.

tools

Launch and manage interactive workspace tools (architecture explorer, virtual browser, …).

template

recipe

Publish and install community recipes. There are two kinds: app recipes (install into an existing workspace) and composition recipes (deploy a whole workspace).
Registry refs use the required -r/--ref flag (install, versions, delete, yank, deprecate). Positional arguments are for local file paths only (lint, info).

publish

Publish a rig.yaml (or a rendered manifest) to the community registry:
The publish: block in rig.yaml supplies default vendor/slug/version/metadata; flags override it.

setup-script & service-spec

Reusable first-boot configuration attached to workspaces at creation time.
See Setup Scripts and Service Specs.

proxy (workspace-only)

Inside a workspace VM, the managed AI proxy helpers wire your shell to the credit-metered proxy:
on/off/env accept an optional route alias (openrouter, openai, v1). See Managed AI Proxy.

API reference

The CLI wraps the Rigbox REST API. For programmatic access, see: Or hit any endpoint directly with rig api GET /v1/workspaces.