Concepts
How Nimbus works — the engine, the data model, tenancy, and the architecture.
Explanation-oriented pages: how Nimbus works and why it's built the way it is. Read these to build a mental model; reach for Developers or Operators when you have a task in hand.
The system
- How Nimbus works — the one-engine, many-adapters model: server, adapters, engine, runtime, and storage in one binary.
- Data and mutations — documents, optional schemas, the single mutation path, and reactive subscriptions.
- The adapter boundary — how five protocol front doors share one engine without sharing each other's semantics.
Trust and isolation
- Tenant isolation — the multi-tenant trust model: who a tenant is and what separates one from another.
- Runtime permissions — grants, mode ceilings, and why queries and mutations carry no ambient authority.
Workloads
- Services, sandboxes, and sessions — the resource model for long-running workloads beyond functions.
- Network control plane: how portable connectivity identity, leases, provider evidence, and recovery support those workloads.
- How the Node runtime works — why Node.js support is an in-process compatibility contract, not a Node process.
Operations
- Scaling — what one Nimbus process gives you today and where the scaling boundaries are.
Architecture
- Architecture — a system-by-system map of the binary: thirteen pages covering the server, adapters, engine, storage, networking, runtime, sandboxes, auth, tenancy, node lifecycle, CLI, SDK packages, and observability. Each page cites the crates that implement it.
Scale out by partitioning tenants
Grow past one Nimbus machine by partitioning tenants across independent instances — decision signals, the lever ladder to climb first, moving a tenant's data, and cutting client routing over.
How Nimbus works
The single-binary architecture — one engine, durable storage and network control planes, and protocol adapters for existing clients.