Infrastructure for the Agentic Era.

Every account starts with $100 in compute credits shared across vCPU and RAM. Storage has a separate 5 GB permanent free allowance, and only starts billing above that threshold. Credits do not expire during the alpha.

There is no monthly platform fee. Billing starts the moment a workload consumes vCPU or RAM above the free credit balance, metered per second. Storage bills per GB-hour once you exceed the 5 GB free tier.

Capacity unlocks progressively. Tier 1 is available after email verification. Tier 2 requires a card on file plus a $25 top-up. Tier 3 unlocks at $500 committed, Tier 4 at $2,000 sustained over 30 days. Enterprise is a custom agreement; contact us.

Incus is the open-source successor to LXD: a container and VM manager that gives each sandbox a full Linux system namespace with real systemd as PID 1. Unlike Docker-based sandboxes that share a kernel namespace, Incus containers boot a complete OS image in under 200 ms while keeping filesystem, network, and process namespaces strictly isolated. For agent workloads this means no shared kernel attack surface, per-second billing tied to actual container uptime, and ZFS-backed copy-on-write snapshots that branch instantly.

Yes. Each sandbox is a full Debian 13 system with systemd as PID 1. Your agent can run apt-get, install any package, start background daemons with systemctl, open ports, and run long-lived processes, exactly as on a real Linux machine. The golden images ship with mise, git, and common runtimes pre-installed so most agents start without needing to install anything.

Each workspace maps to a dedicated Incus project: a hard namespace boundary. Sandboxes in workspace A cannot see, reach, or share filesystem state with sandboxes in workspace B, even on the same host. Network traffic between workspaces is blocked at the virtual NIC layer. This is full project-level separation backed by the host kernel, not container-group isolation.

Snapshots use ZFS copy-on-write clones, so taking one is instant regardless of disk size; only changed blocks are stored. You can snapshot a running sandbox and branch it into independent clones: run one branch to completion, discard it, and retry from the snapshot. This is useful for replaying agent decisions, A/B testing tool configurations, or keeping a clean checkpoint before a risky operation.

Yes. A workspace is a multi-sandbox namespace, not a single container. You can provision dozens of sandboxes simultaneously, each with its own vCPU, RAM, and filesystem allocation. Each sandbox provisions independently, and the audit timeline tracks every execution history separately.

By default the sandbox stops. It moves to the stopped state and billing for compute pauses. The filesystem is preserved so you can inspect artifacts, take a snapshot, or restart later. You can also mark a sandbox to delete on completion so it cleans up automatically.

Golden images ship pre-configured for Claude Code (Anthropic), Codex (OpenAI), OpenCode, and OpenClaw. Each image sets the environment variables, installs the relevant CLI/SDK, and configures sensible workspace defaults. You can also bring your own Debian-based image and install any framework manually.

Sandboxes provide strong isolation: each runs in its own Incus container with dedicated kernel namespaces, no access to the host filesystem, and no cross-workspace networking. LLM-generated code running inside a sandbox cannot escape to the host or other workspaces. For additional safety you can restrict the sandbox's network policy and audit every command via the signed execution timeline.

Access is controlled by workspace membership roles: Owner, Admin, and Member. Members can view and interact with sandboxes; Admins can create, delete, and configure them; Owners have full control including workspace deletion. All access is mediated by JWT-authenticated RPC calls. Audit logs record every action with the acting user's identity.