AI & CLI

Your infrastructure,
one conversation away.

Add Sproobo as a connector in claude.ai or ChatGPT, teach your coding agent the CLI with one command, or drive everything from the terminal yourself. Every path goes through the same audited, plan-first API you use — an AI can never do more than you can.

Start freeRead the security model
claude.ai · sproobo connectorlive
youwhy is staging behind — and can you ship it?
agentstaging is 3 commits behind main · requesting a deploy plan
planbuild off-box → blue-green swap → health gate → atomic switch
youapprove
00:47deploy #215 live · rollback armed
Three ways in

Chat, coding agent, or terminal.

Pick the surface that fits the moment. They are the same platform underneath — same API, same audit trail, same approval gates.

Connectors — claude.ai & ChatGPT

Add Sproobo as a connector and sign in with OAuth — no API key to paste. Then just ask: “why did last night’s deploy fail?”, “bump postgres on srv-fra-1”. Tokens rotate and are scoped to your role.

OAuth · scoped to your role

The Agent Skill

One curl installs a skill that teaches Claude Code, Codex or Cursor to drive Sproobo from inside the repo it’s already editing — deploys, secrets, logs, rollbacks.

claude code · codex · cursor

The CLI

sproobo login opens your browser — no token copy-paste. Create apps, import secrets from a .env, watch deploys until the health gate decides, tail logs live.

plan-first · -y to auto-approve
sproobo · a real session
# install the skill for your coding agent (Claude Code, Codex, Cursor) curl -fsSL https://cp.sproobo.com/skill/install.sh | sh # sign in — opens your browser, no token paste sproobo login Logged in to acme (acme) — role ADMIN # create an app; apex + www ingress and cert included, deploy watched sproobo apps create api --server srv_fra1 --repo github.com/acme/api --domain api.acme.dev plan → app + ingress + cert · apply? y deploy #1 · off-box build → blue-green → health gate ✓ · live # bulk-load secrets from a .env — one atomic write sproobo secrets import app_fra1 .env
agent · plan-first, approval-gated
~service: sproobo-api
-replicas: 2
+replicas: 4
-postgres: 16.3
+postgres: 16.4
AI-native, not AI-reckless

Powerful for the agent. Boring for the auditor.

There is no privileged backdoor and no separate, looser path. Whatever connects — a chat model, a coding agent, a script — it lands on the same rails you do.

  • one APIHumans, CLI, connectors and skills call the same audited surface.
  • plan-firstDestructive ops return a diff you approve before anything applies.
  • your roleTokens are minted at the connecting user’s role — never above it.
  • rate-limitedEvery AI surface is rate-limited and fully audit-logged.
Straight answers

The questions we’d ask too.

No. Connectors, the skill and the CLI all call the same audited API your dashboard uses. Every call is attributed to the user who connected it, recorded in the audit trail, and rate-limited. There is no separate, more-powerful path.
Read things and propose plans. Destructive operations return a plan first — nothing is applied until it’s approved, whether that’s a click in chat, a y at the CLI prompt, or an explicit -y you typed yourself.
Only what you ask the agent to fetch — a log tail, a deploy status. Sproobo still stores none of your telemetry; the AI sees what you show it, when you show it.
Exactly the role of the person who connected — OWNER, ADMIN, MEMBER or VIEWER. Tokens rotate and can be revoked at any time. An AI can never out-rank the human behind it.
Get started

Bring your server. Bring your agent.

Start freeRead the docs