Documentation

The whole backend in one command

nimbus dev

Run it in your project. One process — a single Rust binary — serves storage, TypeScript functions, realtime subscriptions, scheduling, and agent sandboxes, and reloads your functions as you save. No Compose file, no sidecar services, no managed account.

Install it first:

brew trust --cask nimbus/tap/nimbus
brew install --cask nimbus/tap/nimbus

Other platforms ship via the install script and release binaries — see the install options. The 5-minute quickstart scaffolds an app around nimbus dev; the self-host quickstart runs the same binary as a long-lived server with nimbus start.

One binary, your choice of client

# migrate an existing Convex app
nimbus dev

// convex/messages.ts — server-side functions with reactive queries
import { query, mutation } from "./_generated/server";
import { v } from "convex/values";

export const list = query({
  args: {},
  handler: async (ctx) => await ctx.db.query("messages").take(50),
});

export const send = mutation({
  args: { author: v.string(), body: v.string() },
  handler: async (ctx, { author, body }) =>
    await ctx.db.insert("messages", { author, body }),
});

Every tab is the same engine and the same data — five drop-in protocols, the native API, and the sandbox surface. See Developers for the adapters side by side.

Production is one more verb

nimbus dev      # laptop: watch files, run codegen, reload functions
nimbus deploy   # production: package, validate, activate atomically

You have already run the first one. Both are the same binary with the same configuration surface — no Terraform, no Helm chart, no Dockerfile between them. nimbus deploy packages your functions, previews a diff with --dry-run, and activates the new generation atomically on whatever server you point it at. Deploy to production walks the whole flow.

Built for agents

Agents need a backend they can run (one binary, started in one command), inspect (docs shipped as llms.txt, structured errors, and a plain table of what works today), and get isolated compute from. That last part is first-class: sandboxes are isolated worlds addressed by id, services are named workloads other code can depend on, and sessions are expiring leases for stdio, file, and browser-control access — all managed through the @nimbus/nimbus SDK against the same server that holds your data.

Scale with tenants and services

The unit of isolation is also the unit of growth. Every tenant gets its own storage namespace, its own write queue, and its own function budgets — load on one tenant cannot degrade another, and adding load means adding tenants. Heavier compute fans out into sandbox-backed services that Nimbus launches and supervises next to your data, and storage can move onto PostgreSQL, MySQL, or libSQL infrastructure that grows independently. One deployment is one process today — no cluster mode; scaling spells out the limits and the partitioning pattern for growing past one machine. Self-hosted, source-available, and protocol-portable by design: no lock-in.

Find your path

By surface