VoltroFramework

Berechne deinen Kunden
nicht länger die Verkabelung.

Deine Agentur hat "Multi-Tenant-SaaS mit Auth, Billing, Cron und Dashboard" dieses Jahr schon sechs Mal gebaut. Jedes Kundenprojekt beginnt mit denselben zwei Wochen Verkabelung, bevor du etwas ausliefern kannst, das wirklich dem Kunden gehört. Voltro ist genau diese zwei Wochen — fertig geformt, getestet, im Eigeneinsatz erprobt und bereit für dich. Zieh den nächsten Kunden in unter einer Stunde hoch und rechne die Teile ab, auf die es ankommt.

Quickstart lesen
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.

Sechs Dinge, die du nicht mehr von Grund auf baust.

Das Skelett, das du immer wieder neu schreibst

Multi-Tenant-Schema, Sign-in-/Sign-out-Routen, ein authentifiziertes Dashboard, eine Billing-Anbindung, eine Oberfläche für transaktionale E-Mails. Vom CLI generiert, von dir angepasst, im Besitz deines Kunden.

Dieselben Muster in jedem Projekt

Wenn dein Team Voltro einmal beherrscht, sieht jede Kunden-Codebase gleich aus. Einen neuen Entwickler einzuarbeiten heißt, ihm EIN Framework zu übergeben — nicht zehn Stack-Overflow-Suchen pro Kunde.

Eine Codebase, die du übergeben kannst

Der Anwendungscode, den du baust, liegt im Repo deines Kunden, in seinem Git, auf seiner Platte. Er kann ihn nach Projektende selbst weiterpflegen; du kannst dieselben Muster beim NÄCHSTEN Kunden wiederverwenden. Das Framework ist eine Runtime, die er konsumiert — keine Blackbox.

Drei Deploy-Baselines

`compose` für "Deploy auf einem VPS", `helm` für Kunden mit k8s-Cluster, `bare` für "sie geben dir systemd". Wähle beim Erstellen, wechsle später. Der Anwendungscode ändert sich nicht.

Kundenspezifisches Branding

@voltro/ui-shadcn liefert Kompositionen, die du pro Kunde über Tailwind-v4-Tokens neu einfärbst. LoginCard, AppShell, DocShell, ProfileMenu usw. des Kits übernehmen projektspezifisches Branding, ohne die Komponenten zu forken.

Cloud als Upsell, nicht als Lock-in

Hoste die App des Kunden ab Tag eins selbst. Sobald Voltro Cloud startet, richtest du dasselbe Projekt darauf aus — dieselben Primitive, keine Code-Änderungen (Managed Cloud kommt bald). Die Cloud ist der Upgrade-Pfad, nicht der einzige Pfad.

Rechne Ergebnisse ab, nicht Boilerplate.

Deinen Kunden ist es egal, dass du einen eigenen Auth-Flow geschrieben hast. Ihnen ist wichtig, dass das Produkt funktioniert. Voltro nimmt dir die Teile jedes Projekts ab, die immer gleich aussehen — damit du die Engagement-Zeit auf die Teile verwendest, für die dein Kunde tatsächlich zahlt: seine Domäne, seine Differenzierung, seine UX.

Was ab Tag eins ausgeliefert wird:

  • • Funktionierende Auth. @voltro/plugin-auth: Sign-up, Sign-in, Sign-out, HttpOnly-Cookies, Passwort-Hashing. In Produktion einen echten User-Store einstecken, im Dev den Memory-Store.
  • • Funktionierendes Billing. @voltro/plugin-billing: Stripe-Checkout, Portal, Webhook-Handling, Entitlement-Gating über requireEntitlement.
  • • Funktionierende Mails. @voltro/plugin-mail: Resend / Postmark / SendGrid / SMTP / Konsole. React-Email-Templates mit typsicheren Props. Suppression-Liste pro Tenant.
  • • Funktionierender Storage. @voltro/plugin-storage: S3 / R2 / Azure / Dateisystem / Datenbank. Öffentliche + private Objekte, vorsignierte Uploads, Virenscan-Hook, Bildtransformationen on the fly.
  • • Funktionierende Observability. OpenTelemetry-Traces, strukturierte Logs, das voltro-logs-CLI für "Warum ist das fehlgeschlagen"-Antworten in Sekunden.

Sie bekommen eine wartbare Codebase, kein Vendor-Lock-in.

Die Anwendung, die dein Kunde erhält, ist eine TypeScript-+-Postgres-Codebase in seinem Repo. Er kann Anbieter wechseln (Stripe → Paddle, Resend → SendGrid), ohne neu zu architektieren. Er kann JEDEN einstellen, der TypeScript + Postgres kann, um sie nach dem Projekt zu warten. Seine Daten liegen in seiner Datenbank — nicht hinter einer Vendor-Mauer, für die er Miete zahlt. Das ist ein Wertversprechen, das du in einem Sales-Call vorbringen kannst.

Typsicherheit

Kein Codegen-Schritt, den sie vergessen. Das Schema ist der Vertrag; der Editor fängt den Bug, bevor der Test läuft.

Multi-Tenancy

tenant() im Schema. Cross-Tenant-Bugs werden auf der Runtime-Ebene eliminiert.

Durable Workflows

Die Flows, die Kunden wollen — Einladungs-Onboarding, Winback abgesprungener Kunden, Monats-Digest — überstehen Deploys ohne separaten Job-Runner.

Öffne das Framework. Schau es dir selbst an.

Jede Primitive auf dieser Seite ist heute im Framework. Klone den Starter, lass `voltro dev` laufen, in zwei Minuten ist es auf dem Bildschirm.

Quickstart lesen