Run AI Code.
Secure and Elastic Infrastructure for AI-Generated Code.

Overview OrbitBox

OrbitBox is a runtime infrastructure platform designed to run AI-generated code safely, in isolation, and efficiently. Unlike traditional approaches that rely only on simple function executors, OrbitBox gives AI agents a complete computer — a dedicated kernel boundary, private filesystem, controlled network connectivity, and interactive terminal access.

This means AI agents are no longer limited to function calls. They can install packages, run long-lived processes, create and modify files, access databases, and preview web applications — all inside an isolated environment that can be discarded when it is no longer needed.

Sandbox Concept

A sandbox in OrbitBox is a self-contained compute unit. Each sandbox operates independently and does not share state with other sandboxes. These are the core components of a sandbox:

• Dedicated kernel boundary — processes inside the sandbox cannot affect processes outside it.
• Isolated filesystem — every sandbox has its own filesystem.
• Network policy — outbound network access is controlled through configurable policies.
• Resource quotas — CPU, memory, and disk are limited according to platform configuration.
• Preview URL — every exposed port receives a secure URL for human access.

A sandbox can be ephemeral (automatically discarded after completion) or persistent (data is stored in durable volumes that can be snapshotted).

Lifecycle

Every sandbox moves through a structured lifecycle. Understanding this lifecycle is important for designing efficient agent workflows.

1. Create

A sandbox is created from a snapshot or base template, such as a Node.js, Python, or custom image. Initialization usually completes in under 100 ms because OrbitBox uses a fast copy-on-write snapshot mechanism.

2. Run

Agents or users run commands inside the sandbox through the Process API, PTY sessions, or the Filesystem API. In this phase, agents can install dependencies, write code, run servers, and iterate on changes.

3. Preview

Application ports are exposed through secure URLs that humans can access for human-in-the-loop review. Preview URLs remain available while the sandbox is active and do not require additional network configuration.

4. Snapshot

The verified sandbox state is saved as a snapshot. This snapshot can be used as the base for the next sandbox, so setup does not need to be repeated from scratch.

5. Dispose

The sandbox is stopped and all resources are released. Ephemeral data is deleted automatically. Data stored in persistent volumes remains available for future sessions.

Security Model

OrbitBox is designed around the principle of untrusted code execution by default. Every infrastructure layer assumes that code running inside it cannot be fully trusted.

• Kernel isolation — every sandbox has its own kernel boundary, not just a standard container namespace.
• Network egress policy — outbound network traffic is controlled by policy, not only by a host-level firewall.
• Ephemeral volumes — temporary volumes are discarded automatically on dispose, leaving no residual data.
• Audit logs — every operation is recorded in audit logs that can be exported to OpenTelemetry.
• Preview tunnel — preview URLs use encrypted tunnels and do not expose the server IP directly.
• Resource quotas — CPU and memory are limited per sandbox, preventing one sandbox from monopolizing resources.

Agent Workflow

The following is a typical AI-agent workflow using OrbitBox to complete a development task:

• The agent receives instructions from an orchestrator, for example: “Build a simple REST API with Node.js and Express”.
• The agent creates a new sandbox using the OrbitBox API or CLI.
• The agent installs dependencies through the Process API by running npm install inside the sandbox.
• The agent writes code files using the Filesystem API.
• The agent runs a server through a PTY session and monitors log output.
• The agent retrieves the Preview URL and sends it to a human for review.
• After approval, a snapshot is created and the sandbox is disposed.

This entire flow can be executed automatically by agents without human intervention, except at review points that require approval.

Quickstart

The following CLI commands use placeholders. Replace <YOUR-API-KEY> with the API key obtained from the OrbitBox dashboard.

# Set the API key environment variable
export ORBITBOX_API_KEY=<YOUR-API-KEY>

# Create a new sandbox from the Node.js 20 snapshot
orbitbox sandbox create my-workspace --snapshot node-20

# Run a command inside the sandbox
orbitbox exec my-workspace -- npm install express

# Write a file into the sandbox
orbitbox fs write my-workspace /app/server.js --from ./server.js

# Run the server in a PTY session
orbitbox exec my-workspace --pty -- node /app/server.js

# View the preview URL
orbitbox sandbox info my-workspace --json | jq '.preview_url'

# Save the current state as a snapshot
orbitbox snapshot create my-workspace --name baseline-v1

# Dispose the sandbox after completion
orbitbox sandbox dispose my-workspace

All commands above are idempotent — running the same command again will not create duplicates if the state already matches.

Conceptual API

OrbitBox provides a REST API for programmatic integrations from any programming language. The following endpoints are conceptual examples with placeholder URLs — not active production endpoints.

Create a Sandbox

POST https://api.orbitbox.example/v1/sandboxes
Authorization: Bearer <YOUR-API-KEY>
Content-Type: application/json

{
  "name": "ai-worker",
  "snapshot": "node-20",
  "region": "ap-southeast-1",
  "resources": {
    "cpu": 2,
    "memory_mb": 2048
  }
}

Example Response

{
  "id": "sbx_xxxxxxxxxxxx",
  "name": "ai-worker",
  "status": "running",
  "preview_url": "https://ai-worker.preview.orbitbox.example",
  "region": "ap-southeast-1",
  "created_at": "2026-01-01T00:00:00Z"
}

Run a Command

POST https://api.orbitbox.example/v1/sandboxes/sbx_xxxxxxxxxxxx/exec
Authorization: Bearer <YOUR-API-KEY>
Content-Type: application/json

{
  "command": ["npm", "install", "express"],
  "workdir": "/app",
  "env": { "NODE_ENV": "development" }
}

FAQ

How is an OrbitBox sandbox different from a regular container?

Traditional containers such as Docker share the host kernel and rely on namespaces for isolation. OrbitBox sandboxes use a stronger kernel boundary, providing more robust isolation for running untrusted code.

How long can a sandbox run?

A sandbox can run for as long as the task requires. For temporary workloads, use ephemeral mode. For projects that need continuity, use persistent volumes and create snapshots regularly.

Is data inside one sandbox safe from other sandboxes?

Yes. Every sandbox has an isolated filesystem. Data does not leak into other sandboxes. For additional security, enable volume encryption and ensure audit logs are sent to your SIEM system.

How do I access a sandbox interactively?

Three options are available: the web terminal in the OrbitBox dashboard, direct SSH into the sandbox using keys registered with the platform, or VNC for graphical interface access. PTY sessions are also available through the API for agents that need programmatic terminal access.

Does OrbitBox support programming languages beyond Node.js?

Yes. OrbitBox provides a variety of base snapshots: Python, Go, Rust, Java, and more. You can also create custom snapshots from your own images using the Declarative Builder feature.