Integration

Hosted API & CLI

A control-plane runs against a real Kubernetes cluster; you talk to it with the boxxkite CLI or the REST API directly, without ever touching SandboxManageror Kubernetes yourself. Easiest path: sign up against boxxkite's own always-on hosted cloud at api.boxxkite.com, below. Prefer to run that control-plane yourself instead? Same CLI, same REST API — just point --url at your own deployment (see Kubernetes deployment).

Two credential types, deliberately non-interchangeable

A dashboard session token (a short-lived JWT from POST /v1/auth/signup or /login) is only accepted by /v1/api-keys routes. A long-lived API key (from POST /v1/api-keys, sent as Authorization: Bearer bxk_live_...) is only accepted by /v1/sandboxesroutes. You can't create a key using a key — revoking a leaked one can't be worked around by minting a replacement with it first. The raw key is returned exactly once, at creation, and is never retrievable again.

Sign up and provision an API key

boxxkite signup chains signup → login-token → create-api-key into one command and saves the result to ~/.boxxkite/config.toml. It defaults to boxxkite's own hosted cloud — nothing to deploy first, and no --url needed:

terminal

boxxkite signup
# prompts for --email / --password
# Account created and API key saved for https://api.boxxkite.com.
# You're ready to run: boxxkite session create

Self-hosting instead (see Kubernetes deployment)? Pass --url pointing at your own deployment — everything else below works identically either way:

terminal

boxxkite signup --url https://your-control-plane.example.com

Already have an account (from another machine, or the dashboard) but not a saved key on this one? boxxkite login exchanges your existing email/password for a fresh API key the same way:

terminal

boxxkite login
# prompts for --email / --password
# Logged in and API key saved for https://api.boxxkite.com.

Already have a key for either? Set it directly instead of running signup again — set-keyalone is enough for boxxkite's own hosted cloud:

terminal

boxxkite config set-key bxk_live_...
boxxkite config show

Pointing at your own control-plane instead? Add set-url too:

terminal

boxxkite config set-url https://your-control-plane.example.com
boxxkite config set-key bxk_live_...
boxxkite config show

What the CLI can do

Every capability has its own page with the exact CLI syntax alongside Python/JS/MCP — the CLI covers all of them:

Sandboxes — boxxkite session create/get/ls/rm
Process & exec — boxxkite exec
File system — boxxkite files view/create/edit/ls/glob/grep
Command allowlist — boxxkite allowlist get/set/clear
Secrets — boxxkite secrets create/ls/rm
MCP server config — boxxkite mcp init <target>

Every session/exec/files command auto-detects the target session if exactly one active session exists; otherwise pass --session <id> explicitly.

Check your account and usage

terminal

boxxkite whoami
# email: you@example.com
# account id: 3f9a...
# usage: 2.1/20.0 sandbox-hours this month
# concurrent sandboxes: 1/2

See Rate limits & quotas for what those numbers mean and how they're enforced.

Manage API keys

Unlike session/exec/files, key management needs your dashboard credentials (email + password), not the API key itself — by design, per the credential-separation rule above. These commands prompt for both each time rather than persisting a session.

terminal

boxxkite keys ls
boxxkite keys rm <key_id>

https only

Every entry point (CLI, both SDKs, the MCP server) refuses a plain http:// base_url except http://localhost/127.0.0.1 — an API key is a full-privilege, long-lived credential, and a non-https URL would put it on the wire in cleartext.