Introduction

Reactor.cloud is an AI-first backend platform that gives you identity, data, storage, serverless functions, background jobs, site hosting, an LLM gateway, and third-party connectors — all behind a single CLI, a single SDK, and a single project file (reactor.toml).

The same project runs on your laptop, on a single VPS, on your own cloud, or on Reactor.cloud without code changes. You pick a deployment grade; the platform handles the rest through swappable adapters.

Built in Rust. Designed for agents and humans alike.

Why Reactor?

Most backend stacks force you to stitch together a dozen services: an auth provider, a database API, object storage, a job runner, a hosting platform, and a separate LLM proxy. Each has its own config format, SDK shape, and deployment story.

Reactor replaces that patchwork with one coherent platform:

• One project file — reactor.toml declares your functions, sites, jobs, and data migrations.
• One CLI — reactor dev, reactor deploy, and capability-specific verbs share the same contexts and credentials.
• One SDK — @reactor/client exposes every capability through a unified TypeScript interface (Swift SDK available too).
• One server binary — reactor-server mounts all enabled capabilities in a single process, or scales them out at higher deployment grades.

Tip

If you are migrating from Supabase, Firebase, or a custom Express + Postgres stack, Reactor’s Data and Identity APIs will feel familiar — but you get jobs, sites, gateway, and connect in the same box.

The eight capabilities

Every capability is a stable HTTP surface, a typed SDK module, a CLI verb family, and a Rust trait with swappable adapters. Enable only what you need; the rest stays out of your way.

#	Capability	What it does	Typical use
1	Identity	Users, orgs, roles, MFA, OAuth, JWT issuance	Sign-up flows, multi-tenant apps, API keys
2	Data	Typed tables, queries, mutations, RLS, realtime	App state, user-generated content, dashboards
3	Storage	Blob upload/download, signed URLs, lifecycle rules	Avatars, documents, media pipelines
4	Functions	One-shot serverless HTTP handlers	Webhooks, custom API logic, AI tool endpoints
5	Jobs	Durable, retryable, scheduled background work	Email sends, rollups, data sync, onboarding flows
6	Sites	Static hosting and full app hosting (Next.js, etc.)	Marketing pages, SSR apps, admin panels
7	Gateway	LLM routing, metering, observability	Chatbots, agent backends, model failover
8	Connect	Third-party API connectors, data sync, webhooks	CRM sync, payment providers, SaaS integrations

Capabilities share a PostgreSQL database (SQLite at the lightest grade). Row-level security enforces tenant isolation at the data layer — not just in application code.

Note

Realtime, queues, and cache are primitives that several capabilities depend on. They are not separate user-facing products; you interact with them through Data subscriptions, Jobs, and Functions.

Deployment topologies

Reactor runs the same reactor-server binary across many topologies, described as <Edition><Size>@<platform>. Your SDK calls and CLI commands stay identical; only the underlying adapters change.

Token	Where it runs	Best for
O1 — Local	Desktop app (Tauri, Electron), local SQLite	Offline-first tools, dev sandboxes, single-user apps
O2 — Single node	One VPS, Docker Compose, homelab	Side projects, internal tools, early production
O4 — Managed cloud	Fly, Render, Railway + managed Postgres	Teams that want ops-light hosting
E6 — Enterprise self-host	Customer AWS, GCP, or on-prem	Regulated industries, existing cloud contracts
C6 — Reactor.cloud	Fully managed by AtomicoLabs	Fastest path to production, global edge

# reactor.toml — the deployment topology is configured at the server level
# Your project file stays the same regardless of topology.
project_id = "my-app-a1b2c3d4"
name = "My Application"
default_context = "local"

Caution

Some capabilities weaken their delivery guarantees at smaller sizes. For example, realtime fan-out at size 1 is in-process only. Check the Deployment topologies page before choosing a topology for production.

Who Reactor is for

Indie developers and startups

Spin up a full backend in minutes with reactor init and reactor dev. Ship a Next.js site, a Postgres-backed API, and auth — then deploy to Reactor.cloud when you are ready to go live.

AI and agent builders

Gateway gives you model routing, metering, and observability out of the box. Functions and Jobs are natural homes for tool calls and long-running agent workflows. The platform is designed so agents can read reactor.toml and know exactly what to deploy.

Teams with existing infrastructure

Run O2 on a VPS today, move to E6 on your AWS account tomorrow. Adapters swap; your SDK and project file do not. Self-hosting is first-class, not an afterthought.

Multi-tenant SaaS builders

Identity provides organizations, roles, and invitations. Data enforces row-level security per org. Connect syncs third-party data per tenant. See the Multi-tenant app guide for a full walkthrough.

How it compares

Reactor is not a single-purpose tool. It replaces several categories at once:

Category	Examples	Reactor capability
Auth / identity	Auth0, Clerk, Supabase Auth	Identity
Database API	Supabase, PostgREST	Data
Object storage	S3, Cloudflare R2	Storage
Serverless functions	Vercel Functions, Supabase Edge	Functions
Background jobs	trigger.dev, Inngest	Jobs
Frontend hosting	Vercel, Netlify	Sites
LLM proxy	LiteLLM, OpenRouter	Gateway
Integrations	Airbyte, Nango	Connect

Project layout at a glance

When you run reactor init, you get a standard structure:

my-app/
├── reactor.toml          # Project manifest
├── .reactorignore        # Files excluded from deploy bundles
├── data/
│   └── migrations/       # SQL migrations
├── functions/            # Serverless function sources
├── sites/                # Static or framework site sources
└── jobs/                 # Job definitions (optional)

Next steps

Ready to run something locally?

1. Quickstart — install the CLI and start a dev server in under five minutes.
2. Your first app — build a notes app with auth, data, a function, and a deployed site.
3. Concepts — understand reactor.toml, contexts, and the adapter model.

CLI

brew install reactor-cloud/tap/reactor
reactor init my-app
cd my-app
reactor dev

JavaScript

import { createClient } from '@reactor/client';

const reactor = createClient('http://localhost:8080', {
  key: 'rk_pub_...',
});

const { data } = await reactor.from('items').select('*');