One command line,
create-project to production.
The voltro CLI is the whole workflow: scaffold a project, run the dev loop with automatic codegen, plan and apply migrations, build and deploy, inspect a running app, and check the blast radius of a change. It reports zero telemetry.
$ voltro create-project my-app
$ voltro dev # codegen on every change
$ voltro db plan # diff schema → migration
$ voltro db apply
$ voltro check --diff # blast radius of a change
$ voltro build && voltro startThe command surface, by job.
Scaffold anything
voltro create-project (with --api / --web / --cache=redis / --baseline), add-app, package create for publishable or private packages, and generate "[prompt]" for the AI app-builder (dry-run unless --write).
A dev loop with no codegen step
voltro dev writes rpcGroup.generated.ts and the typed client on every change via the module graph — there is no separate codegen command to forget. Generated files live in .framework/ and are disposable.
Database, planned
voltro db plan / apply / drift / squash / rollback / restore-snapshot / status / seed, plus embeddings backfill — file-based, online-safe migrations with drift detection across environments.
Build, run & deploy
voltro build / start / serve, baseline (bare / compose / helm), static (Cloudflare Pages / S3 / Netlify), serverless (Cloudflare / Scaleway) and dormancy for scale-to-zero.
Inspect & check
voltro inspect / logs / traces / workflows / cluster read a running app; voltro check validates against its live manifest — dangling source/target tables, unknown RBAC scopes, orphan tables — with --json and --diff.
Data, secrets & cloud
voltro data export / import / backup / restore (portable .vbundle with masking + encryption), secret generate for every purpose, and voltro cloud (login / whoami / projects / env / import).
check knows what your change will break.
Blast-radius checks against the live app
voltro check doesn’t lint files — it validates against the running app’s live capability manifest, catching dangling source/target tables, unknown RBAC scopes and broken route bindings before they ship. --diff previews the blast radius of a removal, and --json emits LLM-shaped diagnostics so an agent can fix its own mistakes in a loop.
One binary, counted.
commands, each with its own help, examples and notes — printed from the registry, so the help cannot describe a command that no longer exists
templates it can scaffold from, listed by reading the registry rather than a hand-kept list
What `voltro dev` does before your first request.
- 1
Reads your app config
A config that exists but fails to load is a refusal, never a quiet downgrade — the alternative writes a valid-looking generated file with every plugin silently missing.
- 2
Discovers your primitives
Queries, mutations, actions, streams, workflows and events are found by file convention, so a new procedure needs no registration step to forget.
- 3
Generates the client surface
The typed rpc group your frontend imports, plus a structural guard that walks its imports and aborts the boot if any of them reaches server-only code.
- 4
Applies the schema and boots
The declarative planner diffs your schema against the live database, prints what it intends and classifies the destructive steps before running them.
The CLI, in depth.
What does the dev server actually do for me?
It boots your api and web app together, watches the filesystem, runs codegen when a primitive changes, restarts the parts that need restarting, and keeps the browser in step. Route changes hot-update rather than full-reloading, so component state survives an edit.
It also seeds an agent guide into the project on first boot — a slim always-loaded core plus on-demand topic modules — so an AI coding assistant working in your repo reads the framework's actual conventions instead of guessing from training data.
The parts that usually need a second terminal are folded in: schema changes are applied on boot, environment variables are validated before anything starts, and a missing required secret is a refusal to boot rather than a mystery at the first request that needed it.
How do I go from nothing to a running project?
One command. `voltro create-project acme --api=api-backend --web=frontend-app` scaffolds a workspace, an api and a frontend wired to it, allocates ports, and can apply a deploy baseline at the same time. `voltro add-app` grows it later; `voltro list-templates` shows what is available, read from the registry rather than from a list somebody maintains.
`voltro new` scaffolds a single primitive — a query, a mutation, an action, a workflow, a page — in the right place with the right file convention, which matters because discovery is by filename.
Everything scaffolded is yours from that moment. There is no update channel writing into your project later, and nothing phones home; a template is a starting point rather than a dependency.
What does it give me for production?
`voltro build` precompiles the serve path into a single artefact so a cold start loads one file instead of resolving hundreds of modules — measured at roughly a five-fold improvement on the framework's own fixture, and worth more on a small container where module resolution dominates.
`voltro doctor` is the preflight: it checks what production needs before you find out at boot, and includes a hand-roll detector that names the shipped primitive at the exact spot where you are rebuilding one by hand. `voltro capabilities` reads the export surface out of your installed packages, so an agent or a person can verify what exists instead of recalling it.
`voltro deploy` shows the paths rather than assuming one: self-host through a baseline and your own CI, ship individual serverless functions, publish a static site, or use the managed control plane. The framework does not require a particular host.
How do I inspect a running app?
`voltro inspect`, `logs`, `traces`, `workflows` and `cluster` talk to a running process over an authenticated inspect surface. You read live subscriptions, request traces, workflow runs and their journals — including dead-lettered ones, which can be replayed — rather than reconstructing them from log lines.
`voltro check` validates the wiring without running anything: whether every procedure has an access decision, whether a guard requires a scope no role grants, whether a binding is unreachable. It is the check you can run in CI and in a code review.
`voltro db plan` prints the migration a schema change would produce, before applying it. Reviewing a plan is the habit the declarative migration model is built around — you approve operations rather than write them.
The commands you reach for daily.
| Command | What it does |
|---|---|
| voltro dev | Boots api + web, watches, runs codegen, hot-updates routes, applies schema changes on boot. |
| voltro create-project | Scaffolds a workspace with an api, a frontend, ports and an optional deploy baseline. |
| voltro db plan / apply | Diffs your schema against the live database, prints the operations, applies them on approval. |
| voltro build / serve | Precompiles the serve path into one artefact for a fast cold start, then runs it in production. |
| voltro doctor / check | Production preflight and wiring validation — including guards that require scopes no role grants. |
| voltro inspect / logs / traces | Reads a running app's subscriptions, traces and workflow journals over an authenticated surface. |
Frequently asked questions
Is the CLI required, or can I use my own tooling?
It is the supported path because discovery, codegen and the boot sequence live in it, but it is a normal package running normal Node — a project scaffolded by it is an ordinary workspace you can build and deploy with your own pipeline.
Does anything phone home?
No. `voltro telemetry` exists to report that none is collected — there is nothing to opt out of. The one network call is optional cloud registration during scaffolding, and only when you are logged in; `--no-register` skips it.
How do I upgrade across a breaking change?
`voltro update` bumps every framework package, installs, aligns the peer ranges your app declares, and runs the codemods shipped with the target version — rewriting your source where the change can be automated and printing written steps where it cannot.
Can I add my own templates?
Yes. A template is a directory with a manifest and the files to copy — no plugin API. Point the CLI at your own repository of private templates and they scaffold exactly like the shipped ones.
What happens if a required environment variable is missing?
The app refuses to boot and names the variable, rather than starting and failing at the first request that needed it. Secrets the framework owns are minted per project into a gitignored file during development, and the mint refuses to write until that file is actually ignored.
The CLI drives the whole runtime.
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.