VoltroFramework

Stop billing your clients
for plumbing.

Your agency has built "multi-tenant SaaS with auth, billing, cron, and a dashboard" six times this year. Every client project starts with the same two weeks of wiring before you can ship anything that's actually theirs. Voltro is that two weeks, shaped, tested, dogfooded, and waiting for you. Spin up the next client in under an hour and bill for the parts that matter.

Read the quickstart
terminal
bash
# A new client project: working in 60 seconds.
pnpm dlx @voltro/cli create-project acme \
  --api=api-backend \
  --web=frontend-shadcn \
  --baseline=compose \
  --cache=redis

cd apps/acme && pnpm install && pnpm dev

# What you have:
#  - Postgres + Redis up via docker-compose
#  - Working dashboard (shadcn + auth + nav)
#  - Multi-tenant schema (org / actors / users seeded)
#  - Stripe billing routes scaffolded
#  - OpenTelemetry traces in the dashboard
#  - Cron + workflows wired
#  - Yours to deploy: VPS, k8s, or Voltro Cloud — your call.

Six things you stop building from scratch.

The skeleton you keep rewriting

Multi-tenant schema, sign-in/sign-out routes, an authenticated dashboard, a billing wire, a transactional-email surface. Generated by the CLI, customised by you, owned by your client.

Same patterns on every project

Once your team learns Voltro, every client codebase looks the same. Onboarding a new dev means handing them ONE framework, not ten stack-overflow searches per client.

A codebase you can hand over

The application code you build sits in your client's repo, in their git, on their disk. They can keep maintaining it after the engagement ends; you can re-use the same patterns on the NEXT client. The framework is a runtime they consume, not a black box.

Three deploy baselines

`compose` for "deploy on a VPS", `helm` for clients with a k8s cluster, `bare` for "they hand you systemd". Pick at create time, switch later. The application code doesn't change.

Customer-specific branding

@voltro/ui-shadcn ships compositions you re-skin per client via Tailwind v4 tokens. The kit's LoginCard, AppShell, DocShell, ProfileMenu, etc. take per-project branding without forking the components.

Cloud as an upsell, not a lock-in

Self-host the client's app on day one. When Voltro Cloud ships, you'll point the same project at it — same primitives, no code changes (managed cloud is coming soon). The cloud is the upgrade path, not the only path.

Bill for outcomes, not for boilerplate.

Your clients don't care that you wrote a custom auth flow. They care that the product works. Voltro takes the parts of every project that look the same off your plate so you can spend the engagement on the parts your client is actually paying for — their domain, their differentiation, their UX.

What ships from day one:

  • • Working auth. @voltro/plugin-auth: sign-up, sign-in, sign-out, HttpOnly cookies, password hashing. Plug a real user store in production, memory store in dev.
  • • Working billing. @voltro/plugin-billing: Stripe checkout, portal, webhook handling, entitlement gating via requireEntitlement.
  • • Working mail. @voltro/plugin-mail: Resend / Postmark / SendGrid / SMTP / console. React-Email templates with type-safe props. Suppression list per tenant.
  • • Working storage. @voltro/plugin-storage: S3 / R2 / Azure / filesystem / database. Public + private objects, presigned uploads, virus scan hook, on-the-fly image transforms.
  • • Working observability. OpenTelemetry traces, structured logs, voltro logs CLI for "why did this fail" answers in seconds.

They get a maintainable codebase, not a vendor lock-in.

The application your client receives is a TypeScript + Postgres codebase in their repo. They can swap providers (Stripe → Paddle, Resend → SendGrid) without re-architecting. They can hire ANYONE who knows TypeScript + Postgres to maintain it after the engagement. Their data lives in their database — not behind a vendor wall they pay rent on. That's a value proposition you can put on a sales call.

Type safety

No codegen step they'll forget. The schema is the contract; the editor catches the bug before the test runs.

Multi-tenancy

tenant() in the schema. Cross-tenant bugs are eliminated at the runtime layer.

Durable workflows

The flows clients want — invite onboarding, lapsed-customer winback, monthly digest — survive deploys without a separate job runner.

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.

Read the quickstart