Catalog operations
List, get, create, update, and delete every catalog kind from the same prompt — components, teams, APIs, resources, systems, domains, dependency edges.
marboba component listmarboba CLI
marboba — IDP, scriptable.
The full MarBoba surface, available from a shell, a CI runner, or an AI agent. Same auth model as the REST API; no SDK, no agent, no service account.
marboba scorecard run sc_release_readiness \
--kind component --entity billing-svc
Use it as a release gate. Pipe its JSON into jq.
Ship it in your golden-path scaffolds.
What it does
One binary, three workflows.
Every /v1 resource has a matching command —
list / get / create / update / delete — plus the operational reads you'd
expect (SLOs, drift, costs, on-call). Three of the most useful surfaces:
Release gates
Score a service against a scorecard from a CI step. Exit non-zero blocks the deploy. Audit row tagged so postmortems know it was an automated check.
marboba scorecard run sc_release_readiness \
--kind component --entity billing-svcOperational checks
SLO burn-down, drift status, error-tracker totals, on-call shifts, deployment history. Pipe JSON into jq, alert on anything off-target.
marboba slo list -o json | jq '.[] | select(.status != "ok")'Get started
Two commands to a working CLI.
Install with one line, log in once with a Personal Access Token, and the config sticks. Mac, Linux, and Windows binaries are signed and SHA-256 verified.
1. Install
# macOS / Linux — one-liner (verifies SHA256):
curl -fsSL https://marboba.com/install.sh | bash
# Or via Homebrew:
brew install somexai-applications-group/marboba/marboba
# Or from source (Go 1.22+):
git clone https://github.com/SomexAI-Applications-Group/somexai-apps-management
cd somexai-apps-management/marboba-cli
make install
Lands at ~/.local/bin/marboba
(curl path) or $(brew --prefix)/bin
(Homebrew). Windows users grab the
.exe from the GitHub release.
2. Log in
marboba login \
--endpoint https://api.marboba.com/v1 \
--token mb_pat_live_…
Saves to ~/.config/marboba/config.yaml
(mode 0600). Override per-command
with --endpoint /
--token or the
MARBOBA_* env vars.
Who uses it
For people who don't click for a living.
Platform engineers
Live in terminals; pipe everything into jq + scripts. The CLI is where you spend the day — not the web UI.
CI / CD pipelines
Run as a release gate, a nightly compliance audit, or a post-deploy verification. Same auth as the REST API, no agent to install on runners.
AI coding agents
Cursor, Claude Code, or your in-house orchestrator can drive the catalog as a tool. Predictable JSON, honest exit codes, stable schemas.
Same surface, different verbs
REST, Terraform, CLI — pick the right tool.
Three ways to drive MarBoba. They all share one auth model (Personal Access Tokens or org-scoped API keys), one resource model, and one audit log.
REST API
Every CLI command maps 1:1 to /v1. Use one or the other, or both — the auth model is identical.
Browse the API →Terraform provider
For declarative state — components, teams, scorecards, SLOs, runbooks, dependency edges, and on-call bindings.
View on the Terraform Registry →Personal Access Tokens
How you authenticate the CLI. Mint one in Settings → Personal Access Tokens, paste it into `marboba login`, and you're done.
Open settings →Ship it through your terminal.
Start with one command in a CI step. By next week the CLI is wired into your golden-path scaffolds and your release gates.