Every command, one page.

sproobo is a single binary that drives the exact same audited, role-gated API the dashboard uses — one org per API key, plan-first writes, and no privileged AI-only path. This page is the full reference: install, sign in, the plan-first model, every command and flag grouped by area, exit codes, and a CI recipe.

Install

One command, any OS/architecture it detects:

curl -fsSL https://cp.sproobo.com/cli/install.sh | sh

It resolves the latest version, downloads the right binary, and verifies its sha256 against published checksums before installing. See Scripts & one-liners for the sudo-free SPROOBO_INSTALL_DIR option and the rest of the installer behavior.

Sign in

Three equivalent forms, pick the one that fits where you're running:

sproobo login
sproobo login --paste
sproobo login --token sk_…

• sproobo login — browser-based login. It opens a browser and a human must approve the request there.
• --paste — prompts for a key instead of opening a browser.
• --token <sk_…> — fully non-interactive; no browser, no prompt.

CI / headless: set SPROOBO_TOKEN in the job environment to an sk_ API key minted in the dashboard under Team → API Keys (see Team, orgs & billing for scoped keys and roles) — no sproobo login needed. The env var beats the stored profile.

Self-hosted / non-default control plane: set SPROOBO_ENDPOINT (or pass --endpoint) to the control-plane base URL. Default: https://cp.sproobo.com.

Credentials live in the CLI's own config — ~/.config/sproobo/config.json on Linux, ~/Library/Application Support/sproobo/config.json on macOS. Never copy tokens anywhere else.

Verify what the current key resolves to at any time: sproobo whoami shows the org and role.

The plan-first model

Writes are plan-first: without -y a write prints a PLAN and changes nothing. In an interactive terminal the CLI shows that plan and prompts Apply? [y/N]; -y/--approve skips the prompt and applies. These flags apply to every command:

Every write carries a correlation ID whether you set one or not — it's the idempotency key the control plane uses to tell “retry the same write” from “apply it again.” To retry a write safely (a flaky CI job, a dropped connection), reuse the printed id via --correlation-id and the server replays instead of re-applying. Add --json to any command when you're parsing output instead of reading it.

Identity

Inventory

Read-only lists — the source of the ids every other command takes:

Deploys

See Apps & deploys for the blue-green mechanics behind both commands.

Apps

• --dockerfile <path> — build a Dockerfile that lives in a subdir of a monorepo (built from the repo root, e.g. apps/web/Dockerfile). Without it, a repo with no root Dockerfile falls back to Railpack auto-detection on the repo root.
• --health-path <path> — health-gate probe path (default /healthz). Pass / for a static-image app (e.g. a Caddy-served static export) that has no /healthz endpoint.

Creating a static site itself is dashboard-only today — there's no dedicated CLI flag for it; once created, an app created either way deploys and rolls back through the same commands above.

Secrets

Values are write-only — the CLI never reads one back, only names. See Secrets & env for the envelope-encryption model underneath.

Secret changes take effect on the app's next deploy.

Logs

Servers

See Servers & enrollment for the enrollment lifecycle the printed one-liner drives.

Misc

A tool that speaks MCP natively can use sproobo mcp directly instead of shelling out to individual commands — same API, same permissions, same audit trail. See AI & CLI for connectors and the coding- agent skill.

Exit codes

That's sproobo deploy <appId> -y as-is: a gating CI step, no extra polling needed. --detach returns right after enqueueing, so its exit code then reflects only the enqueue, not the deploy's outcome.

CI recipe

Sproobo auto-deploys on push when an app's GitHub repo is connected (see Apps & deploys), so most projects need no CI wiring at all. Reach for the CLI in CI when you want explicit control: deploy only after tests pass, deploy from a CI system Sproobo isn't connected to, or scripted rollbacks.

Mint an API key in the dashboard (Team → API Keys) and store it as a CI secret. Set SPROOBO_TOKEN in the job environment — no sproobo login needed. MEMBER role suffices for deploys and secrets.

deploy:
  runs-on: ubuntu-latest
  steps:
    - name: Install sproobo
      run: curl -fsSL https://cp.sproobo.com/cli/install.sh | sh
    - name: Deploy
      run: sproobo deploy ${{ vars.SPROOBO_APP_ID }} -y
      env:
        SPROOBO_TOKEN: ${{ secrets.SPROOBO_TOKEN }}

Writes are idempotent per correlation ID; the CLI generates one per write and already retries transient network errors itself. To make a whole re-run of the job replay instead of re-apply, pass a stable key, e.g. --correlation-id "deploy-$GITHUB_SHA".

Add --json to any command for machine-readable output.

Troubleshooting

• command not found: sproobo — install it (see Scripts & one-liners), then re-check.
• UNAUTHENTICATED / 401 — the key is missing, revoked, or mistyped. Interactive: sproobo login (opens a browser; a human must approve). Headless: check SPROOBO_TOKEN. sproobo whoami verifies what the current key resolves to.
• Permission / scope denied — org roles run VIEWER < MEMBER < ADMIN < OWNER. Reads work at VIEWER (except live container logs, which need MEMBER); writes (deploy, secrets set/import/rm, apps create) need MEMBER or higher. sproobo enroll is denied for scoped keys entirely — it needs an unscoped admin key.
• A plan printed but nothing changed — that's plan-first working as designed: without -y writes are a dry run. Re-run the same command with -y to apply it.
• Deploy exited 1 — the previous release is still serving. Diagnose with sproobo deployments --app <appId> to find the failed deployment's id, then sproobo logs --deployment <depId> for its build and runtime output, and sproobo status app <appId> for current fused health.
• logs shows nothing — container logs need both --server and --container; deployment logs need --deployment. Mixing the flags up returns nothing useful.
• Self-hosted / non-default control plane — set SPROOBO_ENDPOINT (or pass --endpoint) to the control-plane base URL. Default: https://cp.sproobo.com.

Next

• See every installer's exact flags and behavior on Scripts & one-liners.
• Roles, scoped API keys, and who can mint one — Team, orgs & billing.
• The blue-green deploy and rollback mechanics behind deploy/rollback — Apps & deploys.
• Connectors, the coding-agent skill, and the MCP bridge — AI & CLI.