Architecture

Rigbox separates platform operations from user code. Workspaces run in micro-VMs with separate kernels and filesystems. Network controls and authenticated bridges mediate access to platform capabilities; see security boundaries for the limits of this model.

​

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
• VM networking - each VM uses a private interface, with platform routing and network controls governing traffic
• systemd init - full Linux userspace with service management
• Scoped credentials - managed upstream provider keys remain at the proxy; workspace configuration can contain user-supplied secrets and scoped credentials

Code running as root can read and modify that workspace’s files and credentials. Treat each workspace as a trust boundary and avoid placing mutually untrusted applications or credentials in the same workspace.

​

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:

• Rigbox-managed upstream provider keys stay at the proxy. BYOK credentials you supply are available to your workspace code
• Token usage is metered and deducted from your credit balance
• Workspaces export OPENROUTER_BASE_URL=http://172.16.0.1:9090/v1 and OPENROUTER_API_KEY at login so SDKs and CLI tools work out of the box; rig proxy on is available for shells/tools that need provider-native compatibility exports
• The proxy fronts an OpenRouter gateway: /v1/chat/completions, /v1/embeddings, and /v1/models for OpenAI-shape clients, plus /v1/messages for the native Anthropic shape used by Claude Code; /brave exposes Brave Search when configured

See Managed AI Proxy for usage details and BYOK for using your own keys.

​

VM-local bridge services

Each running workspace can reach a compute-local bridge service at http://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