Skip to content
nimbus

Agents

Nimbus is a backend AI agents can run, inspect, and get isolated compute from — without adding a second vendor next to the database.

  • Run. The whole backend is one binary. An agent (or the human supervising it) starts it with nimbus start and has storage, functions, realtime, scheduling, and sandbox execution in a single process — there is no service mesh to assemble before the first task runs.
  • Inspect. The docs ship as llms.txt artifacts, every API returns structured errors from a published error catalog, and current capabilities is a plain table of what works today.
  • Isolate. Agent workloads get three purpose-built resources, managed through the @nimbus/nimbus SDK or plain HTTP: sandboxes (isolated execution environments addressed by id), services (named workloads other code can depend on), and sessions (scoped, expiring connections for stdio, files, and browser control).

The shape to remember: reach for a sandbox when an agent needs an isolated world for one task — it has an id, a lifecycle, and session access, and it disappears without leaving a name behind. Promote work to a service only when other code should depend on it by name. Open a session when something needs to interact with a running resource under a lease that expires on its own. The design rationale behind the three nouns is explained in Services, sandboxes, and sessions.

Start here

Section titled “Start here”
  • Agent sandbox quickstart — create a sandbox, watch it run, open a session, and tear it down, in about five minutes.
  • Run sandboxes — standalone sandboxes: specs, labels, listing, and what the API redacts.
  • Manage services — named workloads: backends, readiness waiting, and generation-checked updates.
  • Open sessions — channels, TTLs, and target snapshots.

Where sandboxes actually run

Section titled “Where sandboxes actually run”

Sandbox execution runs on Linux hosts: workloads launch as OCI containers with deny-by-default network egress. (A libkrun microVM backend exists but fails closed for process execution today — containers are what run workloads.) On macOS and WSL2, nimbus machine provides the managed Linux VM that hosts them — see the CLI reference. The full status table is in current capabilities.

Ordinary Nimbus functions are not sandboxes: they run in V8 isolates inside the server process and never appear in sandbox listings. The boundary is explained in Services, sandboxes, and sessions.

Going deeper

Section titled “Going deeper”