Start from a working app,
not an empty folder.
Every template is a small, opinionated, dogfooded reference — a real app that boots, not a skeleton with TODOs. Scaffold one, read it in a sitting, then own it. There is no update channel and nothing phones home: from the moment it lands in your repo, it is your code.
# One project, a backend and a frontend that talk to it
voltro create-project acme --api=api-backend --web=frontend-app
# Add more later — a mobile app, a docs site, edge functions
voltro add-app mobile --template=mobile-app --to acme
voltro list-templates # the registry itself, never a stale listWhat a template actually gives you.
Four kinds, one CLI call
Backends (api-*), frontends (frontend-*), a serverless function library, and an Expo mobile app. `voltro create-project acme --api=api-backend --web=frontend-app` scaffolds a whole project; `voltro add-app` grows it later. `voltro list-templates` is the authority — it reads the registry, so it cannot drift from what your CLI actually has.
Feature showcases, not toy demos
Beyond the minimal shapes, each showcase exercises one whole slice of the framework end to end: auth with MFA and passkeys, storage with public and private objects, durable workflows, RBAC, search, moderation, governance, billing, collaborative editing. You read a template to learn the slice, then delete what you do not need.
They ship with tests — and we run them
Every template carries a real test suite, and a harness scaffolds each one into a temp workspace, installs it and runs those tests. It has caught unbootable templates, schemas using APIs that no longer exist, and a missing dependency — before a single user scaffolded them.
Bilingual out of the box
Every frontend template ships en/de with typed catalogs, a locale switcher, and the right URL strategy for its render mode — cookie-based where the page is interactive, URL-prefixed where it is statically rendered with zero JS. A missing translation fails typecheck rather than shipping an English string to a German visitor.
The deploy layer is a baseline, not a guess
Pick a baseline at scaffold time and the project gets the matching deploy surface — a Docker Compose stack, a Helm chart, or nothing at all. The templates stay identical; only the layer around them changes, so choosing wrong is a re-run, not a rewrite.
A template you can write yourself
A template is a directory with a manifest and the files to copy — no plugin API, no lifecycle. Point the CLI at your own repo of private templates and `voltro add-app --template my-template` works exactly like the shipped ones.
Content from markdown, typed
The blog, docs and changelog templates run on content collections: markdown files with a schema-checked frontmatter (a violation fails the build naming the file), server-rendered bodies with highlighted code fences, locale trees with fallback, and an RSS feed emitted by the build — without installing a markdown dependency.
Why we test our own examples.
A stale template teaches every project the wrong shape
Templates are the first framework code most people read, and a broken one is worse than no template — it is a wrong pattern copied into a hundred projects with full confidence. So they are not shipped on trust: the harness renders each into a real workspace, installs it, and runs its suite; a separate pass typechecks them, because a green test run transpiles without checking types. When a framework convention changes, the templates move with it or the gate goes red.
What the library actually holds.
templates, each a real app that boots — 26 backends, 19 frontends, a serverless library and an Expo app
database dialects any of them can be pointed at without changing application code
From one command to a running project.
# One project, a backend and a frontend that talk to it
voltro create-project acme --api=api-backend --web=frontend-app
# Add more later — a mobile app, a docs site, edge functions
voltro add-app mobile --template=mobile-app --to acme
voltro list-templates # the registry itself, never a stale listThe tree is what you own from that moment: no update channel writes into it, and nothing phones home. Adding a second app later is the same command with a different template.
The template library, in depth.
What is actually in a template?
A working application. Not a skeleton with TODO comments, but an app that boots, serves requests, has a schema, has tests, and demonstrates one coherent slice of the framework end to end. You scaffold it, read it in a sitting, and then it is yours.
Mechanically it is a directory with a manifest and the files to copy, with a handful of tokens substituted for your project and app name. There is no plugin API and no lifecycle — which is why pointing the CLI at your own repository of private templates works exactly like the shipped ones.
Nothing is retained afterwards. There is no update channel writing into your project later and nothing phones home; a template is a starting point rather than a dependency you inherit.
How do the feature showcases differ from the minimal ones?
The minimal backends share one small domain and differ only in the store or plugin wired on top — the right place to start when you want the shape without the noise. The showcases each exercise a whole slice: auth with MFA and passkeys, storage with public and private objects, RBAC, search, moderation, governance, billing, collaborative editing.
A showcase is meant to be read as documentation you can run. Reading how the storage template declares a private object with an access policy is faster than reading the storage page and then guessing at the wiring, because the wiring is right there and it works.
They are also meant to be cut down. Scaffold, delete the parts you do not need, keep the pattern. That is a better starting position than an empty folder plus a documentation tab, and a much better one than copying snippets that were never run together.
Why do the templates ship tests, and why do you run them?
Because templates are the first framework code most people read, and a broken one is worse than none — it is a wrong pattern copied into a hundred projects with full confidence. So every template carries a real test suite, and a harness scaffolds each into a temporary workspace, installs it, and runs those tests.
That gate has caught real defects before anyone scaffolded them: templates using APIs that no longer existed, a missing dependency, and an app that could not boot. A separate pass typechecks them, because a green test run transpiles without checking types — a distinction that has bitten this repository more than once.
When a framework convention changes, the affected templates move with it or the gate goes red. A stale template silently teaches every new project the wrong shape, and it does it for as long as nobody notices.
How do templates and deploy baselines fit together?
A baseline is the deploy surface, chosen independently of the app: a Docker Compose stack for a single box, a Helm chart for Kubernetes, or nothing if you already have a pipeline. The templates are identical under each — only the layer around them differs.
That separation is what makes choosing wrong cheap. Picking the wrong baseline is a re-run rather than a rewrite, because nothing in the application depends on which one you took.
A project can also mix kinds: a long-running api, a static marketing site and a serverless function library in one workspace, deployed to three different places from one repository, scaffolded a command at a time.
The four kinds, and what they scaffold.
| Kind | What you get |
|---|---|
| api-* | A long-running backend: schema, procedures, tests — minimal shapes plus feature showcases. |
| frontend-* | A web app with its render mode chosen for the job, bilingual, wired to a sibling api. |
| edge-functions | A library of standalone serverless functions — no long-running server, no port. |
| mobile-app | An Expo app consuming the same api with the same typed hooks; Expo owns its dev loop. |
| Baselines | The deploy layer — Compose, Helm or none — chosen independently of the app itself. |
| Your own | A directory with a manifest and files; private template repositories scaffold like the shipped ones. |
Frequently asked questions
Am I locked into a template after scaffolding?
No. The code is yours from that moment — there is no update channel writing into your project and nothing phones home. A template is a starting point, and deleting most of it is a normal thing to do.
Can I combine several templates in one project?
Yes, that is the intended shape. `voltro add-app` grows a workspace, so an api, a web frontend, a docs site, a serverless function library and a mobile app can live in one repository and deploy to different places.
Are the templates actually maintained?
They are gated. A harness scaffolds each into a real workspace, installs it and runs its tests, with a separate typecheck pass — so a convention change that breaks a template turns the build red rather than teaching the wrong shape quietly.
Do frontend templates support more than one language?
Every frontend template ships English and German with typed catalogs and the URL strategy that fits its render mode — cookie-based where the page is interactive, URL-prefixed where it is statically rendered. A missing translation fails typecheck.
Can my company keep private templates?
Yes. A template is a directory with a manifest and the files to copy; point the CLI at your own repository and `voltro add-app --template my-template` behaves exactly like the shipped ones.
What you scaffold onto.
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.