opencode

OpenCode — Rigbox example

Runs OpenCode — the open-source, terminal-first AI coding agent — on Rigbox. It's a single static Go binary, ships as a TUI, and routes through Rigbox's managed AI proxy via a provider config written at install time — no API key to set. You SSH in and run opencode.

The single capability: a single-binary OSS agent, zero-key managed AI

The whole point here is running the OSS terminal agent on a persistent VM with no glue code. install: writes an opencode.json that registers a custom OpenAI-compatible provider pointed at the workspace's managed AI proxy, so opencode works on first SSH — nothing to set, no key to forward.

rig.yaml sets reproducible: true, so rig deploy runs the install: script once in a builder VM, freezes the upstream Go binary (and that config) as an image, and later deploys boot from it instead of re-running the installer:

reproducible: true
install: |
  set -euo pipefail
  curl -fsSL https://opencode.ai/install | bash            # → ~/.opencode/bin/opencode
  sudo ln -sfn "$HOME/.opencode/bin/opencode" /usr/local/bin/opencode
  sudo tee /etc/profile.d/opencode-routing.sh <<'EOF'
  …                                                       # PATH for login shells, below
  EOF
  cat > "$HOME/.config/opencode/opencode.json" <<'EOF'
  …                                                       # managed-AI provider, below
  EOF

No Dockerfile — install: is the same script a plain deploy would run on the VM (as developer, with passwordless sudo for the system-path steps); reproducible: true is what makes rig deploy freeze its result.

SSH-in to use it

OpenCode is a TUI — there is no web UI. The app is declared with kind: cli, so rig.yaml carries no port, start, or health — the platform doesn't expect an HTTP front door. The real UX is SSH:

ssh "$(rig workspace ssh-info --workspace <name-or-id> --output json | jq -r .ssh_target)"
opencode

Managed AI via a provider config

OpenCode's provider, base URL, key, and model live in a config file, not env vars. install: writes ~/.config/opencode/opencode.json with a custom @ai-sdk/openai-compatible provider pointed at the managed proxy:

{
  "model": "rigbox/anthropic/claude-sonnet-4.5",
  "provider": {
    "rigbox": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "baseURL": "http://172.16.0.1:9090/v1", "apiKey": "managed-by-rigbox" }
    }
  }
}

The /etc/profile.d/opencode-routing.sh that install: writes only puts ~/.opencode/bin on PATH for non-interactive login shells — the AI wiring is entirely in the config file.

Deploy

cd opencode && rig deploy

No secret required — ai: managed: true routes OpenCode through the workspace's managed AI proxy (your account's AI mode must be managed, which is the default).

Notes

• Persistence: yes. ~/.opencode/ (session state, project config) lives on the workspace disk, outside the rsync zone — durable across redeploys.
• No public UI. kind: cli means there's no HTTP front door at all — the workspace is reachable only via SSH on the rigbox gateway.
• Stack: Go binary from the upstream installer; the ~/.opencode/bin path (and the legacy ~/.local/bin fallback) are both pre-added to PATH so the binary is reachable from any login shell.

Deployment strategy

This example explicitly uses workspace.deployment.strategy: image because its installer changes system packages, global executable paths, or shared tool configuration. The badge review shows image replacement and requires permission before replacing an existing workspace root filesystem. It is not an incremental app release. Use a dedicated workspace and back up root-filesystem development files; persistent volumes are retained. Migrating this installer to app-local releases remains separate work.