Octri CLI

@octri/cli

octri is the command line for your Octri project. It does what the dashboard does: push a spec, build SDKs, publish docs, and work through the errors those SDKs report from production.

Octri takes an OpenAPI spec and gives you a documentation site, client libraries in ten languages, an MCP server, and monitoring for the API behind all of it. See octri.dev.

Node 20 or newer.

Install

npm install -g @octri/clioctri --help

Start here

octri auth loginoctri projects useoctri specs push ./openapi.yaml

auth login prompts for your email and password, and for your authenticator code if you have two-factor on. projects use with no argument opens a picker.

specs push waits for the pipeline, not the upload. Your spec parses in about a second, then the doc pages, search index and changelog get written behind it. The spinner names the stage it is on.

Build an SDK

octri sdk audit                            # what is costing you, scoredoctri sdk build --lang go,typescript --download

In a terminal, sdk build draws a lane per language and repaints it through generating, verifying, packaging, installing, ready. Piped or under CI it prints append-only lines instead, and exits non-zero if any language fails, so it works as a build step with no extra flags.

sdk audit scores the spec and marks which findings the generator can fix on its own. octri sdk audit apply <key> writes one in.

For a look at real generator output without spending a build:

octri sdk preview --lang gooctri sdk preview --lang go --show client.go

Publish docs

octri docs versions publish <specId>octri docs versions label <specId> "Stable"octri docs domain set docs.example.com

docs domain prints the CNAME and TXT records to create, then docs domain verify checks them.

Monitoring

Reads and triage run on your session, so they need nothing but a login:

octri monitoring summaryoctri monitoring issues --status unresolvedoctri monitoring issue <id>octri monitoring resolve <id>

monitoring issue prints the stack and marks which frames resolved against uploaded source maps. When none of them did, the release those errors came from has no symbols, and the CLI says so.

The two upload commands work differently. They talk to the monitoring service directly with an ingest token, because a CI job has one secret and no way to log in:

# CIoctri monitoring sourcemaps upload ./dist \  --url "$MONITORING_URL" --token "$MONITORING_TOKEN" \  --environment "$MONITORING_ENVIRONMENT" --release "$GIT_SHA"
# your own machine, already signed inoctri monitoring sourcemaps upload ./dist

Run octri monitoring config for the three values to store as CI secrets. The release you upload under has to equal the release your SDK reports at runtime, or the service has nothing to pair a trace with.

Commands

Run octri <group> --help for one group on its own.

Global flags: --project <id>, --profile <name>, --api-url <url>, --json, --quiet, --plain, --no-color.

Output

--json is the one to script against:

octri sdk builds --json | jq '.[0].status'octri monitoring issues --status unresolved --json | jq 'length'

NO_COLOR and FORCE_COLOR are both honoured.

Configuration

State lives in ~/.octri/config.json, mode 0600, since it holds session tokens. OCTRI_CONFIG_DIR moves it.

Profiles keep environments side by side:

octri config use prod --api-url api.octri.devoctri config set defaultLanguages go,rust,swift

Every value resolves flag first, then environment, then the stored profile.

Behind a proxy

The CLI and octri mcp serve read the standard proxy variables, in upper or lower case, with no extra Node flag. https:// requests use HTTPS_PROXY, or HTTP_PROXY when that is the only one set. Hosts listed in NO_PROXY, and their subdomains, connect directly; * turns the proxy off.

export HTTPS_PROXY=http://user:[email protected]:3128export NO_PROXY=localhost,127.0.0.1,corp.exampleoctri specs push ./openapi.yaml

If the proxy inspects TLS with its own certificate authority, point Node at that CA with NODE_EXTRA_CA_CERTS=/path/to/ca.pem.

MCP clients usually start servers with a minimal environment, so set these in the server's env block rather than relying on your shell.

MCP server

octri mcp serve

This speaks MCP over stdio and offers the same commands as typed tools. An assistant can push a spec, wait for the build, read the generated Go, and then read the production error that build caused.

To add it to Cursor or VS Code in one click, through npx so no global install is needed:

[Add to Cursor] [Install in VS Code]

The server uses the profile from octri auth login, so sign in first, or set OCTRI_API_KEY in its environment. Listed in the official MCP Registry as dev.octri/cli.

// Claude Desktop / Cursor{  "mcpServers": {    "octri": {      "command": "octri",      "args": ["mcp", "serve"]    }  }}

Credentials come from your stored profile and the assistant never sees them. Reads are open. The two operations you cannot take back are refused unless you start the server with the flag for them:

octri mcp serve --allow-publish   # publishing to package registriesoctri mcp serve --allow-delete    # deleting specs

Tool failures come back as tool results rather than protocol errors, so an assistant can read the message and correct itself.

Notes

• Build progress is polled, not streamed. The /ws/sdk socket authenticates from a header or cookie, which Node's built-in WebSocket cannot set, and a WebSocket dependency would buy about a second of latency on a build that takes minutes.
• Artifact archives are extracted by hand-rolled tar and zip readers, so neither binary needs to be installed. Both refuse entries that would write outside the destination directory.
• @modelcontextprotocol/sdk is the only runtime dependency. Colour, spinners, progress bars, tables and prompts are all local.

The rest of Octri

Monitoring runtimes

Node · Python · Go · Ruby · Rust · PHP · Java · Kotlin · Swift · Dart

Documentation · Pricing · Changelog

MIT licensed.