A suite of small, recognizable products — each a different stack, each with a
minimal UI in one shared design language, each demonstrating one Rigbox
capability with the proper platform primitive. Every example is described by a
single root rig.yaml and deploys in one command from a fresh clone:
cd <example> && rig deploy| Example | Stack | Capability it shows |
|---|---|---|
quickstart/ |
TypeScript (Hono) | the canonical single-app rig.yaml, and both deploy sources — local rsync vs source: { kind: git } |
ai-chat/ |
Python · FastAPI | the managed AI proxy (ai: managed: true) + a portable model alias as a validated select param |
todo-app/ |
Next.js (React/TS) + TS API | multi-app loopback service discovery (dependsOn) + public/private visibility + volume-backed SQLite |
bluegreen-blog/ |
Ruby · Sinatra | bluegreen + promote, and theme selection via a server-validated select param (not a raw env var) |
webhook-receiver/ |
Python · Flask | secrets: + a server-generated credentials: + a select param for the signing algorithm |
scheduled-digest/ |
TypeScript | a background worker loop + /healthz + a number param for the schedule |
url-shortener/ |
Python · Django | the full validated param set (url/string/number/boolean/select/email/secret/textarea) + SQLite migrations |
markdown-notes/ |
Python · Flask | persistent app data + Markdown rendering |
Every example deploys with rig deploy. The manifest's explicit workspace.deployment.strategy selects incremental app releases or the advanced image replacement path. Incremental releases preserve the workspace and SSH sessions; only affected services restart.
n8n uses release-local dependencies. Code-server and Gitea retain explicit image mode until their system-level installers are migrated. Review the strategy before connecting an existing development workspace.
| Example | Product | What it shows |
|---|---|---|
code-server/ |
code-server (VS Code) | run an established product via a reproducible install:; settings/extensions persist under $DATA_DIR |
gitea/ |
Gitea (Git hosting) | a headless single-binary service (install wizard locked) with SQLite + repos under $DATA_DIR |
n8n/ |
n8n (workflow automation) | install pinned dependencies into app releases; workflows persist under $RIGBOX_APP_DATA_DIR |
Standalone reproductions of every app in the Rigbox catalog, kept in catalog-apps/ so they don't crowd the curated example suite. Each is a regular rig deploy-able example you can fork, modify, and run on its own — see catalog-apps/README.md for the full index.
catalog-apps/service/— 12 examples that expose a port + health probe (jupyter, marimo, streamlit, pgweb, excalidraw, filebrowser, openterminal, firecrawl, hermes-agent, t3code, open-webui, openclaw-gateway).catalog-apps/cli/— 6 SSH-first CLI examples (claude, codex, opencode, junie, kilocode, pi). Each declareskind: cliso there's no port, start, or health probe — the value is the CLI on SSH.
Single-app examples use the top-level name/port/start/install/health
shape. Multi-app examples use a workspace: block + an apps: map, where each app
carries its spec inline (port, start, install, env, health, params,
dependsOn, visibility) plus a path: ./dir pointing at its code. rig deploy
rsyncs and installs each app's path and brings them up in dependsOn order;
rig deploy --app <name> redeploys just one.
All of them look like one product family. That comes entirely from
design/:
design/tokens.css— the design tokens (iris accent, light + dark,rb-*utility classes: card / btn / input / select / pill / header / footer / badge). Every app ships a byte-identical copy and wires it up per stack (Next imports it globally; Django/Flask/Sinatra<link>it; the TS apps serve it static).design/STYLE.md— the page skeleton + component rules.design/CONTRACT.md— the technical contract every example follows (base-image runtime, the0.0.0.0+/healthzhealth gate, the rig.yaml schema, params/secrets/credentials,DATA_DIRpersistence).
The point of the suite is to model the right primitive for each job:
- Validated config is a
paramwith a fixed option set (type: select), not a free-form env var — the server validates it and it's live-editable withrig app param set <key>=<value>. Fixed infra (paths, base URLs) stays inenv:. - Persistence for incremental releases uses the managed
RIGBOX_APP_DATA_DIRoutside release directories. Image examples use their declared data paths and volume contract. Neither mode promises database rollback or automatic cross-workspace data transfer. - Visibility is declared in
rig.yaml(visibility: public/private/{ emails: [...] }) so a redeploy keeps it — only an app's front door is public; siblings reach private apps over loopback viadependsOn.
Incremental: quickstart, ai-chat, todo-app, webhook-receiver, scheduled-digest, url-shortener, markdown-notes, n8n, multi-app, mixed-app, and catalog Codex use managed app releases. Source, dependencies, and service configuration are staged separately from development files. Activation briefly restarts services on the same ports. Retained releases support app rollback; persistent data and database migrations are not rolled back.
Image: bluegreen-blog, code-server, Gitea, and the remaining catalog examples explicitly retain workspace.deployment.strategy: image. They install OS packages or write global tool configuration. Connecting one to an existing workspace requires replacement review; do not assume arbitrary root files survive. These examples are not silently converted to app releases.
First installations still take time for upstream downloads and builds. Resource requirements apply to the target workspace for incremental installation and to the isolated builder for image mode. Installing a dependency is distinct from building a workspace image.
Existing image connections retain their strategy. Changing the manifest does not automatically adopt apps or migrate data; ownership and data handoff require explicit review. Blue-green remains an independent advanced workflow, not a stage in ordinary app deployment.
Each directory is self-contained:
single-app-example/
├── rig.yaml # the whole deploy spec, top to bottom
├── <source files>
└── README.md # what it is + what to look at after deploy
multi-app-example/
├── rig.yaml # workspace: block + apps: map (every app spec inline)
├── <app-name>/ # one dir per app — code only, no per-app manifest
└── README.md
rig.yaml's install: provisions whatever runtime the example needs at deploy
time. The base VM ships python3, node, sqlite3, and build-essential; Ruby
is apt-installed by the blog. Each example's own README.md covers what it
demonstrates, the deploy command, what to look at afterward, and any required env.
The browser deploy button uses Rigbox's managed deployment client. Local incremental deployments require the 0.13 release line; 0.12 does not understand the app-release strategy. Until 0.13 is promoted to stable, select the published release candidate:
rig update --version v0.13.0-rc.3
rig --versionExisting forks and deployment branches keep their current manifests. Merge these example changes into the branch you deploy when ready. Switching an existing image deployment to app releases requires reviewing ownership and persistent data; changing the example does not automatically migrate an existing workspace.
Fork an example, connect your Rigbox account, and choose a new or existing workspace. Configure it or deploy with defaults. Each target uses a dedicated deployment branch; pushing to that branch redeploys only its workspace. Existing-workspace deployment requires explicit root-filesystem replacement confirmation and retains persistent volumes.
See the deploy-button guide for forks, runtime secrets, configuration, and retries.