One framework.
Every primitive, first-class.
Most stacks make you re-derive the same primitives on every project — auth, tenants, real-time, jobs, AI. Voltro ships them, wired to one runtime. Here they are by category; open any one for the detail.
Reactive data layer
Live data is the default, not a feature flag.
Type-safe full-stack
One Schema, from the database row to the React prop.
Backend power
The hard parts — durable execution and AI — as primitives.
Multi-tenancy & security
Isolation and identity enforced by the runtime, not by hope.
Ecosystem & operations
The batteries, and everything you need to run it.
The surface, in numbers you can check.
published packages — install the entry point and reach the rest as you need them
plugins, none of them loaded until a requirement asks for one
database engines, exercised by parity tests rather than assumed compatible
starter templates, each a real app that boots rather than a skeleton
How the pieces relate, and which one you need.
Why is all of this one framework instead of a stack of libraries?
Because the expensive bugs live between the libraries, not inside them. A query library that does not know about your background jobs cannot invalidate a screen when one finishes; a scheduler that does not know about your tenant boundary will happily run a job for the wrong one. Assembling those parts yourself means owning every seam between them.
Here the seams are the product. A mutation, a workflow step and a scheduled job all write through the same database layer, so a change made by any of them reaches every open screen without an invalidation rule. The same authorisation context flows through all three, so a rule written once applies whether the caller is a browser, a job or a webhook.
The cost of that integration is a real one: this is a framework, and it has opinions about file layout, data access and error handling. The trade is deliberate — fewer choices at the seams, in exchange for the class of bug that only appears when two independently correct libraries disagree.
Which features do I actually have to learn first?
Four things carry most applications: the schema DSL that declares your tables, the query and mutation primitives that read and write them, the routing convention that turns files into pages and endpoints, and the reactive hooks that keep screens current. Everything else on this page is reachable from those four and can wait until a requirement asks for it.
The second tier is the one teams reach in week two: authentication, background work and multi-tenancy. They are separate pages because each carries decisions worth understanding rather than copying — how sessions are revoked, what makes a workflow durable, where the tenant predicate is enforced and why it is not a WHERE clause you write.
The remainder — AI primitives, local-first sync, caching, observability, deployment baselines — are genuinely optional. A working application never touches most of them, and the ones it does touch it usually adopts one at a time in response to something a user noticed.
What does this replace in a typical stack?
In practice it displaces the glue tier: a data-fetching library plus its cache-invalidation conventions, a job queue and its worker deployment, a scheduler, a websocket layer, an ORM plus a migration tool, and whatever authentication service the project would otherwise have integrated. Each of those remains a fine tool; the point is that they no longer have to be reconciled with each other.
It does not replace your database, your hosting, your CDN, your identity provider if you have one, or your observability backend. Those are consumed rather than reimplemented — Postgres or another supported engine, OpenTelemetry to whatever collector you run, and deployment onto infrastructure you already have.
The honest summary is that this is a framework-shaped bet: it removes a lot of integration work and adds a dependency with opinions. That is worth it for applications that look like applications — accounts, tenants, workflows, live screens — and less so for a single-purpose service that would otherwise be two hundred lines.
How do the categories on this page fit together at runtime?
Data and reactivity are the base layer. Your schema declares the tables, the primitives read and write them, and the change feed carries the effects of a write outward to every subscriber — which is why live screens do not need their own cache-invalidation strategy layered on top.
Execution sits above that. Workflows and scheduled jobs are ordinary code that happens to survive restarts and coordinate across replicas, and because they journal to the same database, their progress is queryable and their effects propagate through the same reactive path as a user-initiated write.
Isolation and operations wrap both. The tenant boundary and the authorisation guards apply on every entry point regardless of which layer initiated the call, and observability threads a single trace through the whole chain so a failure can be read as one story rather than four correlated ones.
What replaces what.
| You would otherwise run | What this provides |
|---|---|
| Data fetching and cache | Reactive queries driven by the database change feed — no cache keys, no manual invalidation. |
| Job queue and workers | Durable workflows journalled to your database, resumable across restarts, with no broker — and a Kafka you already run is interop, not replaced: *.consumer.ts consumers, transactional producing through the outbox, a kafkaSink for change-data-capture. |
| Cron service | Scheduled jobs that coordinate across replicas so one run means one execution. |
| ORM and migration tool | A typed schema DSL plus a planner that diffs declared against live and classifies destructive steps. |
| Auth service | First-party sessions, MFA, passkeys and API keys; SSO and provisioning as plugins. |
| Realtime layer | Subscriptions and fleet-wide fan-out over the database's own change stream. |
Frequently asked questions
Do I have to adopt all of it?
No. The base is the schema, the primitives and the routing convention; everything else is opt-in. Plugins are installed when a requirement arrives, and a project that never needs billing or AI never carries them.
Can I use it for just an API, with no frontend?
Yes. An api application is a complete target on its own, and the reactive client is what a frontend uses if there is one. Templates scaffold either shape or both together.
How does this compare to assembling best-of-breed libraries?
You give up per-layer choice and get the seams handled — one authorisation context, one change feed, one trace. If your application is small enough that the seams are trivial, assembling libraries is a reasonable alternative.
Is there a code generation step I have to remember to run?
Types come from the schema declarations themselves rather than from a generated artefact you keep in sync, so the editor is correct as soon as you save. The development server handles what wiring it does need without a separate command.
Where should I start reading?
The schema DSL and the primitives pages together explain most of what an application does; routing explains how files become pages and endpoints. Add authentication and multi-tenancy when you are past the prototype.
Prefer to run it managed? (coming soon)
Every primitive here works self-hosted today. Voltro Cloud will run the same runtime for you — deploys, managed infrastructure and hosted observability — and is coming soon.
Open the framework. See it for yourself.
Every primitive on this page is in the framework today. Clone the starter, run `voltro dev`, and have it on screen in two minutes.