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/cli

octri --help

Start here

octri auth login

octri projects use octri 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, scored

octri 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 writes one in.

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

octri sdk preview --lang go

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

Publish docs

octri docs versions publish <specId>

octri docs versions label "Stable" octri docs domain set docs.example.com

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

The site's structure is drafted like it is in the API Studio. Redirects, the home page and draft endpoints wait for a publish; nav buttons apply on save:

octri docs redirects add /old-guide /guides/install

octri docs home set octri docs nav publish

octri docs endpoints add POST /refunds --summary "Refund a payment" octri docs endpoints publish

octri docs components push ./components/Banner.jsx octri docs buttons add "Sign up" https://app.example.com --style primary

A component file holds the markup alone: one root element, HTML attribute names (class, not className), and props written as {name}.

The sidebar itself round-trips through a file, and is drafted like the rest:

octri docs nav --json > nav.json

octri docs nav set nav.json octri docs nav publish

Appearance, SEO, social links, page feedback, the API playground and custom code have no draft: each set is live when it returns. Keys are spelled as in the API, @file reads a value from a file, and an empty value clears a link:

octri docs theme set primaryColor=#ff6a00 colorScheme=dark codeTheme=nord

octri docs seo set metaDescription="Payments API reference" indexable=true octri docs socials set github=https://github.com/acme x= octri docs feedback on octri docs playground set enabled=true allowedOrigins=https://acme.com octri docs custom-code set css=@docs.css enabled=true

In Git Bash on Windows, a lone argument starting with / is rewritten into a Windows path before the CLI sees it. Set MSYS_NO_PATHCONV=1, or use PowerShell, for commands that take docs paths.

Monitoring

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

octri monitoring summary

octri monitoring issues --status unresolved octri monitoring issue octri monitoring resolve

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:

# CI

octri monitoring sourcemaps upload ./dist \ --url "$MONITORING_URL" --token "$MONITORING_TOKEN" \ --environment "$MONITORING_ENVIRONMENT" --release "$GIT_SHA"

your own machine, already signed in

octri 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 --help for one group on its own.

Global flags: --project , --profile , --api-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.dev

octri 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:password@proxy.internal:3128

export NO_PROXY=localhost,127.0.0.1,corp.example octri 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:

The server uses the profile from octri auth login, so sign in first, or set OCTRI_API_KEY in its environment. An API key reaches the public routes only: the docs, webhook and MCP-management tools need the signed-in profile. 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 operations you cannot take back are refused unless you start the server with the flag for them:

octri mcp serve --allow-publish   # publishing SDKs, your MCP package, or the drafted docs nav

octri mcp serve --allow-delete # deleting specs, components or webhooks

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.