Skip to content

Search is only available in production builds. Try building and previewing the site to test it out locally.

Architecture FAQ

Reactor is an AI-first backend platform — a Rust workspace that provides identity, data (with RLS), object storage, serverless functions, background jobs, static/SSR sites, an LLM gateway, and data connectors behind one unified HTTP API. You can self-host with a single binary or use the managed Reactor.cloud service.

How is Reactor different from Supabase or Firebase?

Section titled “How is Reactor different from Supabase or Firebase?”

Reactor is self-hostable first with no vendor lock-in — the same binary runs on your laptop and in production. It is AI-native: Reactor Studio embeds an agent harness that can deploy, migrate, and operate your backend. Capabilities are composed as Rust libraries, not proprietary cloud services.

The reactor-cloud workspace is open source. See the GitHub repository for license details.


Rust gives Reactor a single static binary with predictable memory usage, strong type safety across capability boundaries, and native WASM runtime support (wasmtime). The quality bar targets sub-second boot and ≤ 60 MB for the full single-node (O2) binary.

Capabilities are independent backend services packaged as Rust library crates. Each exposes an Axum router, configuration struct, and SQL migrator. The unified reactor-server composes them in one process; sizes 5–6 run each as a separate binary.

For sizes 1–2, a single process eliminates network overhead (especially auth token verification), simplifies operations, and meets the sub-second boot target. When you need isolation or independent scaling, sizes 5–6 split capabilities into separate binaries with the same HTTP contract.

Does the unified binary duplicate the standalone binaries?

Section titled “Does the unified binary duplicate the standalone binaries?”

No. reactor-server depends on capability libraries, not *-server binaries. Both mount the same cap::router(state). Topology contract tests assert the unified binary’s routes are a superset of each standalone binary’s routes.


O1 (laptop) with Reactor Studio for local development. Zero infrastructure cost.

See Deployment grades for the full comparison.

Yes. Export Postgres, copy file storage, keep [project].id stable, point Reactor.toml at new infrastructure, run migrations, and deploy your bundle. No application code changes required.

No. Reactor requires a reachable Postgres 15+ instance. You bring your own (Docker, managed provider, or embedded on Fly.io). SQLite support is planned for size 1 (local).

No. reactor-server is HTTP-only. Terminate TLS with Caddy, nginx, Fly.io, or your CDN. Size 1 (local) binds to 127.0.0.1 only.


One Reactor.toml at the project root. Environment variables with REACTOR_* prefix override file values. See the full Configuration reference.

Can I disable capabilities I don’t need?

Section titled “Can I disable capabilities I don’t need?”

Yes. Omit the [section] from Reactor.toml. The capability is not mounted and its migrations are skipped. This is how size 1 (Tauri) builds stay small.

Not in v0. Restart the process after changing Reactor.toml or environment variables. SIGHUP reload is planned.


No. [auth] is required at boot. Every API request must carry a valid JWT (or use admin endpoints with the admin token).

What’s the difference between admin token and user JWT?

Section titled “What’s the difference between admin token and user JWT?”
TokenGatesUsed by
Admin bearer/_admin/* (deploy, migrate, doctor, logs)CLI, CI, operators
User JWT/data/v1/*, /storage/v1/*, /fn/v1/*, etc.Client SDK, frontend

Never expose the admin token to client-side code.

Reactor Data sets PostgreSQL session variables from JWT claims before executing queries. Your migration SQL defines policies that reference current_setting('request.jwt.claims'). See Security.


Yes. Point [data].migrations_dir at your SQL migrations. Reactor runs them alongside its internal capability schemas (_reactor_auth.*, _reactor_data.*, etc.).

Yes. Set [storage] backend = "s3". Required for multi-node (size 5–6) deployments where nodes don’t share a filesystem.

What happened to my data if I use Reactor.cloud free tier?

Section titled “What happened to my data if I use Reactor.cloud free tier?”

Each project gets an isolated tenant_<ref> database on the shared cluster. Data is not shared between tenants. Free tier quotas limit requests, storage, and bandwidth — see Deployment grades.


WASM (default), Bun (JavaScript/TypeScript), and AWS Lambda. Enable subsets via [functions] runtimes = ["wasm", "bun"] and Cargo features.

Do jobs require a separate worker process?

Section titled “Do jobs require a separate worker process?”

No at size 2. The unified binary spawns a scheduler and worker pool as background tasks. At sizes 5–6, you can scale reactor-jobs-server independently.

Yes. Functions receive injected URLs and service credentials for data, storage, and auth. Use the Reactor SDK inside function code.


No. Studio is optional. You can develop with any editor + reactor-cli. Studio adds the agent harness, task workflow, and integrated cloud dashboard.

Yes at size 1 (local) with embedded reactor-server and local Postgres. Cloud features require network access.

Studio is a backend-focused environment — chat, tasks, deploy, cloud status. Many developers use Studio alongside their preferred editor for day-to-day coding.

See Reactor Studio for details.


Provisions infrastructure (Fly.io machines, volumes, DNS), manages deployments, domains, encrypted secrets, and log streaming. It does not replace reactor-server — it operates it remotely.

The control plane is designed for Reactor.cloud operation. Self-hosters use reactor-server directly with /_admin/* endpoints — no control plane needed.

Pricing model is under development. The shared cluster enforces per-tier quotas (requests, storage, bandwidth). See the shared cluster runbook for current free tier limits.


  • SSE streaming deploy progress from /_admin/deploy
  • GET /_admin/logs SSE multiplexing
  • reactor-cli deploy/logs/doctor wired to admin surface
  • Tauri embedding via reactor_server::run(cfg)
  • Cross-capability deploy rollback
  • Plugin capability surface (realtime, search)
  • Multi-region shared cluster
  • OpenTelemetry export