VoltroDocumentation

Why Voltro?

The wager Voltro is making — reactive, multi-tenant, AI-first as primitives instead of libraries you bolt on.

Most frameworks make you re-derive the same primitives every time: auth, tenants, audit logs, billing, real-time updates, background jobs. Voltro ships them as first-class composable primitives so you can spend your time on what makes YOUR product different.

The wager

AI agents will increasingly write your code. The frameworks that win are the ones that give agents a stable, opinionated surface to target — not a thousand decisions every project re-litigates.

Voltro is deliberately opinionated about boring things (HTTP, state, transport, schema) so the only decisions left are the ones that matter for your product.

Where Voltro fits

You're building... Voltro is a good fit when...
A multi-tenant SaaS You want tenant isolation enforced by the runtime, not "by hope" in app code
A real-time collaboration app Live data should be the default, not a feature flag
An AI agent product Tool calling, RAG, streaming, durability should be primitives
A control plane You need durable workflows + audit logs + RBAC out of the box

Where Voltro is a bad fit

  • You need an existing JS/TS ecosystem feature on day one. Voltro is pre-release; APIs change.
  • You're publishing to a CDN-only edge. Voltro is a stateful, long-running runtime — Vercel, Fly, Railway, Render, or self-host on a Node 24 box.
  • You want a visual ORM / GUI builder. The CLI + your editor + LLMs are the editor.

What we won't do

  • Lock you in. Self-hosting is fully supported. Cloud is the premium tier of the same runtime, not a fork.
  • Multi-runtime grab-bag. Effect-TS end-to-end — no Restate, no Temporal, no Inngest, not even opt-in.
  • Magic. Every file convention is documented; every generated file lives in .framework/ and you can read it.
  • Codegen you have to remember to run. Schema flows from your tables to your React components automatically via Vite's module graph.

Deliberate noes

Two questions come up in every framework comparison. Both are decided — deliberately no — and here is why, so nobody has to re-litigate them.

Why is there no GraphQL API?

  1. GraphQL's three core promises are solved differently here. Type-safe selective reads ⇒ typed queries + schema inference. One endpoint for every client ⇒ the RPC socket with a generated client. Third-party consumers ⇒ REST routes + OpenAPI 3.1 (@voltro/plugin-openapi).
  2. A GraphQL gateway would have no access to the reactivity path — source-based invalidation, per-delivery guards. It would be a second, dead read path whose results are never live: exactly the kind of duplicate path this framework refuses to keep.
  3. Resolver N+1, persisted-query complexity, and a second permission model (field-level vs. our guards/RLS) buy nothing the existing surface cannot do.

Don't build a GraphQL layer over the stores. External consumers get REST + OpenAPI; internal clients get RPC + live subscriptions.

Why not React Server Components?

RSC is a second rendering and data model — Flight serialization, 'use client' boundaries, deep bundler integration — that would compete with the reactive subscription model instead of composing with it. The problems it solves are covered by what exists today: islands for shipping less JS, loaders for server data at render time, and streaming SSR with defer() for progressive delivery. Don't write 'use server' / 'use client' directives in a Voltro app; they mark a boundary this framework does not have.