Rigbox separates platform operations from user code. Your workspaces run in isolated micro-VMs that have no access to platform credentials, other users’ data, or control plane services.Documentation Index
Fetch the complete documentation index at: https://docs.rigbox.dev/llms.txt
Use this file to discover all available pages before exploring further.
Workspace isolation
Each workspace is a micro-VM - not a container. This gives you:- Dedicated kernel - each VM boots its own Linux kernel, fully independent from other workspaces
- Own filesystem - isolated ext4 disk with no shared volumes
- Private network - workspaces cannot communicate with each other directly
- systemd init - full Linux userspace with service management
- No platform secrets - credentials and internal tokens never enter the VM
App routing
When you expose a port from a workspace, Rigbox creates a public URL with automatic HTTPS:- Each app gets a unique subdomain of the form
<APP_NAME>.rigbox.dev, where<APP_NAME>is the name you chose when creating the app - HTTPS termination is automatic - your service only needs to listen on HTTP inside the VM
- Routes are created and removed dynamically as you add or delete apps
- Visibility controls determine who can access each app (public, private, or privileged)
AI proxy
The managed AI proxy lets your workspace code call AI providers without holding API keys:- Provider API keys never enter your VM - the proxy injects them at request time
- Token usage is metered and deducted from your credit balance
- Workspaces export
OPENROUTER_BASE_URL=http://172.16.0.1:9090/v1andOPENROUTER_API_KEYat login so SDKs and CLI tools work out of the box;rig proxy onis available for shells/tools that need provider-native compatibility exports - The proxy fronts an OpenRouter gateway:
/v1/chat/completions,/v1/embeddings, and/v1/modelsfor OpenAI-shape clients, plus/v1/messagesfor the native Anthropic shape used by Claude Code;/braveexposes Brave Search when configured
VM-local bridge services
Each running workspace can reach a compute-local bridge service athttp://172.16.0.1:9090. That service hosts the managed AI proxy and the VM-scoped CLI API used by the baked-in rig command.
The bridge does not trust user-supplied workspace IDs as identity. Rigbox resolves the caller from the VM source IP and the compute node that received the request. This keeps VM identity fixed even if code inside the VM edits local files.
Regions
Workspaces run in specific regions. SSH connections to{region}.rigbox.dev (e.g., eu-west-1.rigbox.dev) connect directly to the region for lowest latency. The base hostname rigbox.dev routes to any region but may add latency depending on your location.
See SSH Access for connection details.
Learn more
Security & Isolation
Credential protection, access control, and network model
Resource Limits
Plan tiers, quotas, and rate limits