Ein Framework.
Jede Primitive, erstklassig.
Die meisten Stacks lassen dich dieselben Primitives bei jedem Projekt neu herleiten — Auth, Tenants, Realtime, Jobs, AI. Voltro shippt sie, verdrahtet mit einer Runtime. Hier sind sie nach Kategorie; öffne eine für die Details.
Reaktive Datenschicht
Live-Daten sind der Default, kein Feature-Flag.
Typsicherer Full-Stack
Ein Schema, von der DB-Zeile bis zur React-Prop.
Backend-Power
Die harten Teile — durable Execution und AI — als Primitives.
Multi-Tenancy & Security
Isolation und Identität von der Runtime erzwungen, nicht von Hoffnung.
Ökosystem & Betrieb
Die Batterien — und alles, was du zum Betrieb brauchst.
Die Oberfläche, in nachprüfbaren Zahlen.
veröffentlichte Pakete — installiere den Einstiegspunkt und greif nach dem Rest, wenn du ihn brauchst
Plugins, von denen keines geladen wird, bevor eine Anforderung danach fragt
Datenbank-Engines, über Paritätstests geprüft statt als kompatibel angenommen
Starter-Templates, jedes eine echte App, die bootet — kein Skelett
Wie die Teile zusammenhängen — und welches du brauchst.
Warum ist das ein Framework statt eines Stapels Bibliotheken?
Weil die teuren Fehler zwischen den Bibliotheken leben, nicht in ihnen. Eine Query-Bibliothek, die nichts von deinen Hintergrundjobs weiß, kann keinen Screen invalidieren, wenn einer fertig wird; ein Scheduler, der die Mandantengrenze nicht kennt, führt einen Job bereitwillig für den falschen aus. Die Teile selbst zusammenzusetzen heißt, jede Naht dazwischen zu besitzen.
Hier sind die Nähte das Produkt. Eine Mutation, ein Workflow-Schritt und ein geplanter Job schreiben durch dieselbe Datenbankschicht, eine Änderung von einem davon erreicht also jeden offenen Screen ohne Invalidierungsregel. Derselbe Autorisierungskontext fließt durch alle drei — eine einmal geschriebene Regel gilt, egal ob der Aufrufer ein Browser, ein Job oder ein Webhook ist.
Der Preis dieser Integration ist real: das hier ist ein Framework, und es hat Meinungen zu Dateilayout, Datenzugriff und Fehlerbehandlung. Der Tausch ist bewusst — weniger Wahlfreiheit an den Nähten, dafür weniger von der Fehlerklasse, die erst entsteht, wenn zwei je für sich korrekte Bibliotheken sich uneinig sind.
Was muss ich davon wirklich zuerst lernen?
Vier Dinge tragen die meisten Anwendungen: die Schema-DSL, die deine Tabellen deklariert, die Query- und Mutation-Primitive, die sie lesen und schreiben, die Routing-Konvention, die Dateien zu Seiten und Endpunkten macht, und die reaktiven Hooks, die Screens aktuell halten. Alles andere auf dieser Seite ist von diesen vier aus erreichbar und darf warten, bis eine Anforderung danach fragt.
Die zweite Ebene erreichen Teams in Woche zwei: Authentifizierung, Hintergrundarbeit und Mandantenfähigkeit. Sie haben eigene Seiten, weil jede Entscheidungen trägt, die man verstehen statt kopieren sollte — wie Sessions widerrufen werden, was einen Workflow durable macht, wo das Mandantenprädikat erzwungen wird und warum es keine WHERE-Klausel ist, die du schreibst.
Der Rest — KI-Primitive, Local-First-Sync, Caching, Observability, Deploy-Baselines — ist wirklich optional. Eine funktionierende Anwendung berührt die meisten davon nie, und die, die sie berührt, übernimmt sie meist einzeln, weil ein Nutzer etwas bemerkt hat.
Was ersetzt das in einem typischen Stack?
In der Praxis verdrängt es die Klebeschicht: eine Data-Fetching-Bibliothek samt Invalidierungskonventionen, eine Job-Queue und ihr Worker-Deployment, einen Scheduler, eine WebSocket-Schicht, ein ORM plus Migrationswerkzeug, und den Auth-Dienst, den das Projekt sonst integriert hätte. Jedes davon bleibt ein gutes Werkzeug; der Punkt ist, dass sie nicht mehr miteinander in Einklang gebracht werden müssen.
Es ersetzt nicht deine Datenbank, dein Hosting, dein CDN, deinen Identity-Provider, falls du einen hast, oder dein Observability-Backend. Diese werden konsumiert statt nachgebaut — Postgres oder eine andere unterstützte Engine, OpenTelemetry an den Collector, den du betreibst, und Deployment auf Infrastruktur, die du schon hast.
Ehrlich zusammengefasst ist das eine framework-förmige Wette: sie nimmt viel Integrationsarbeit weg und fügt eine Abhängigkeit mit Meinungen hinzu. Das lohnt sich für Anwendungen, die wie Anwendungen aussehen — Konten, Mandanten, Workflows, Live-Screens — und weniger für einen Einzweckdienst, der sonst zweihundert Zeilen wäre.
Wie greifen die Kategorien zur Laufzeit ineinander?
Daten und Reaktivität sind die Basisschicht. Dein Schema deklariert die Tabellen, die Primitive lesen und schreiben sie, und der Change-Feed trägt die Wirkung eines Writes nach außen zu jedem Abonnenten — weshalb Live-Screens keine eigene Invalidierungsstrategie obendrauf brauchen.
Darüber sitzt die Ausführung. Workflows und geplante Jobs sind gewöhnlicher Code, der zufällig Neustarts überlebt und sich über Replicas koordiniert; weil sie in dieselbe Datenbank journalisieren, ist ihr Fortschritt abfragbar und ihre Wirkung nimmt denselben reaktiven Weg wie ein nutzerausgelöster Write.
Isolation und Betrieb umschließen beides. Die Mandantengrenze und die Autorisierungs-Guards gelten an jedem Einstiegspunkt, unabhängig davon, welche Schicht den Aufruf begonnen hat, und Observability fädelt einen einzigen Trace durch die ganze Kette — ein Fehler liest sich als eine Geschichte statt als vier korrelierte.
Was was ersetzt.
| Sonst betreibst du | Was hier mitkommt |
|---|---|
| Data-Fetching und Cache | Reaktive Queries über den Change-Feed der Datenbank — keine Cache-Keys, keine manuelle Invalidierung. |
| Job-Queue und Worker | Durable Workflows, in deine Datenbank journalisiert, über Neustarts fortsetzbar, ohne Broker — und ein Kafka, das du schon betreibst, wird integriert statt ersetzt: *.consumer.ts-Consumer, transaktionales Produzieren über die Outbox, ein kafkaSink für Change-Data-Capture. |
| Cron-Dienst | Geplante Jobs, die sich über Replicas koordinieren — ein Lauf heißt eine Ausführung. |
| ORM und Migrationswerkzeug | Typisierte Schema-DSL plus Planer, der Soll gegen Live diffed und destruktive Schritte klassifiziert. |
| Auth-Dienst | First-Party-Sessions, MFA, Passkeys und API-Keys; SSO und Provisionierung als Plugins. |
| Realtime-Schicht | Subscriptions und flottenweites Fan-out über den Change-Stream der Datenbank. |
Häufige Fragen
Muss ich alles davon übernehmen?
Nein. Die Basis sind Schema, Primitive und Routing-Konvention; alles andere ist zuschaltbar. Plugins werden installiert, wenn eine Anforderung kommt, und ein Projekt ohne Bedarf an Billing oder KI trägt sie nie mit.
Kann ich es nur für eine API nutzen, ohne Frontend?
Ja. Eine api-Anwendung ist für sich ein vollständiges Ziel, und der reaktive Client ist das, was ein Frontend nutzt, falls es eines gibt. Templates scaffolden beide Formen einzeln oder zusammen.
Wie steht das gegen selbst zusammengestellte Best-of-Breed-Bibliotheken?
Du gibst Wahlfreiheit pro Schicht auf und bekommst die Nähte erledigt — ein Autorisierungskontext, ein Change-Feed, ein Trace. Ist deine Anwendung klein genug, dass die Nähte trivial sind, ist das Selbstzusammenstellen eine vernünftige Alternative.
Gibt es einen Codegen-Schritt, an den ich denken muss?
Typen entstehen aus den Schema-Deklarationen selbst statt aus einem Artefakt, das du synchron halten musst — der Editor stimmt, sobald du speicherst. Was an Verdrahtung nötig ist, erledigt der Dev-Server ohne separaten Befehl.
Wo fange ich am besten an zu lesen?
Schema-DSL und Primitive erklären zusammen das meiste, was eine Anwendung tut; Routing erklärt, wie Dateien zu Seiten und Endpunkten werden. Authentifizierung und Mandantenfähigkeit kommen dazu, sobald der Prototyp vorbei ist.
Lieber managed betreiben? (bald)
Jede Primitive hier läuft heute self-hosted. Voltro Cloud fährt dieselbe Runtime für dich — Deploys, managed Infrastruktur und gehostete Observability — und kommt bald.
Ö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.