Eine Kommandozeile,
create-project bis Produktion.
Die voltro-CLI ist der ganze Workflow: ein Projekt scaffolden, den Dev-Loop mit automatischem Codegen laufen lassen, Migrationen planen und anwenden, bauen und deployen, eine laufende App inspizieren und den Blast-Radius einer Änderung checken. Sie meldet null Telemetrie.
$ 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 startDie Befehls-Oberfläche, nach Aufgabe.
Scaffolde alles
voltro create-project (mit --api / --web / --cache=redis / --baseline), add-app, package create für publishable oder private Pakete und generate "[prompt]" für den AI-App-Builder (Dry-Run außer --write).
Ein Dev-Loop ohne Codegen-Schritt
voltro dev schreibt rpcGroup.generated.ts und den typisierten Client bei jeder Änderung über den Modul-Graph — es gibt keinen separaten Codegen-Befehl zum Vergessen. Generierte Dateien leben in .framework/ und sind wegwerfbar.
Datenbank, geplant
voltro db plan / apply / drift / squash / rollback / restore-snapshot / status / seed, plus embeddings backfill — dateibasierte, online-sichere Migrationen mit Drift-Erkennung über Environments.
Bauen, laufen & deployen
voltro build / start / serve, baseline (bare / compose / helm), static (Cloudflare Pages / S3 / Netlify), serverless (Cloudflare / Scaleway) und dormancy für Scale-to-Zero.
Inspizieren & checken
voltro inspect / logs / traces / workflows / cluster lesen eine laufende App; voltro check validiert gegen ihr Live-Manifest — baumelnde source/target-Tabellen, unbekannte RBAC-Scopes, verwaiste Tabellen — mit --json und --diff.
Daten, Secrets & Cloud
voltro data export / import / backup / restore (portables .vbundle mit Masking + Verschlüsselung), secret generate für jeden Zweck und voltro cloud (login / whoami / projects / env / import).
check weiß, was deine Änderung kaputt macht.
Blast-Radius-Checks gegen die laufende App
voltro check lintet keine Dateien — es validiert gegen das Live-Capability-Manifest der laufenden App und fängt baumelnde source/target-Tabellen, unbekannte RBAC-Scopes und kaputte Route-Bindings ab, bevor sie shippen. --diff zeigt den Blast-Radius einer Entfernung, und --json emittiert LLM-taugliche Diagnostik, sodass ein Agent seine eigenen Fehler in einer Schleife beheben kann.
Eine Binary, gezählt.
Befehle, jeder mit eigener Hilfe, Beispielen und Hinweisen — aus der Registry gedruckt, die Hilfe kann also keinen Befehl beschreiben, den es nicht mehr gibt
Templates, aus denen sie scaffolden kann, aufgelistet durch Lesen der Registry statt aus einer handgepflegten Liste
Was `voltro dev` vor deinem ersten Request tut.
- 1
Liest deine App-Config
Eine Config, die existiert, aber nicht lädt, ist eine Verweigerung und nie eine stille Abwertung — die Alternative schreibt eine valide aussehende generierte Datei, in der jedes Plugin still fehlt.
- 2
Findet deine Primitive
Queries, Mutations, Actions, Streams, Workflows und Events werden über Dateikonventionen gefunden — eine neue Prozedur braucht also keinen Registrierungsschritt, den man vergessen kann.
- 3
Generiert die Client-Oberfläche
Die typisierte rpc-Gruppe, die dein Frontend importiert, plus ein struktureller Wächter, der ihre Importe abläuft und den Boot abbricht, wenn einer davon serverseitigen Code erreicht.
- 4
Wendet das Schema an und bootet
Der deklarative Planer diffed dein Schema gegen die Live-Datenbank, druckt seine Absicht und klassifiziert die destruktiven Schritte, bevor er sie ausführt.
Die CLI im Detail.
Was macht der Dev-Server eigentlich für mich?
Er fährt api und Web-App zusammen hoch, beobachtet das Dateisystem, führt Codegen aus, wenn sich ein Primitiv ändert, startet neu, was neu gestartet werden muss, und hält den Browser im Takt. Routenänderungen aktualisieren heiß statt neu zu laden — Komponenten-State überlebt eine Bearbeitung.
Er sät beim ersten Boot außerdem einen Agent-Guide ins Projekt — einen schlanken, immer geladenen Kern plus Themen-Module auf Abruf — damit ein KI-Assistent in deinem Repo die tatsächlichen Konventionen des Frameworks liest, statt aus Trainingsdaten zu raten.
Die Teile, für die man sonst ein zweites Terminal braucht, sind eingefaltet: Schema-Änderungen werden beim Boot angewandt, Umgebungsvariablen vor allem anderen validiert, und ein fehlendes Pflicht-Secret ist eine Boot-Verweigerung statt eines Rätsels beim ersten Request, der es gebraucht hätte.
Wie komme ich von nichts zu einem laufenden Projekt?
Mit einem Befehl. `voltro create-project acme --api=api-backend --web=frontend-app` scaffoldet einen Workspace, eine api und ein damit verdrahtetes Frontend, vergibt Ports und kann gleichzeitig eine Deploy-Baseline anwenden. `voltro add-app` erweitert später; `voltro list-templates` zeigt das Verfügbare — aus der Registry gelesen, nicht aus einer gepflegten Liste.
`voltro new` scaffoldet ein einzelnes Primitiv — Query, Mutation, Action, Workflow, Page — an der richtigen Stelle mit der richtigen Dateikonvention. Das zählt, weil die Entdeckung über den Dateinamen läuft.
Alles Gescaffoldete gehört ab diesem Moment dir. Es gibt keinen Update-Channel, der später in dein Projekt schreibt, und nichts telefoniert nach Hause; ein Template ist ein Startpunkt, keine Abhängigkeit.
Was bekomme ich für Produktion?
`voltro build` kompiliert den Serve-Pfad in ein einziges Artefakt vor — ein Kaltstart lädt also eine Datei, statt Hunderte Module aufzulösen. Auf dem Fixture des Frameworks gemessen etwa fünffach schneller, und auf einem kleinen Container mehr wert, weil dort die Modulauflösung dominiert.
`voltro doctor` ist der Preflight: er prüft, was Produktion braucht, bevor du es beim Boot erfährst, und enthält einen Hand-Roll-Detektor, der genau an der Stelle das mitgelieferte Primitiv benennt, an der du gerade eines von Hand nachbaust. `voltro capabilities` liest die Export-Oberfläche aus deinen installierten Paketen — ein Agent oder ein Mensch kann also prüfen, was existiert, statt es zu erinnern.
`voltro deploy` zeigt die Wege, statt einen anzunehmen: self-hosted über eine Baseline und deine eigene CI, einzelne Serverless-Functions, eine statische Site oder die Managed-Control-Plane. Das Framework verlangt keinen bestimmten Host.
Wie inspiziere ich eine laufende App?
`voltro inspect`, `logs`, `traces`, `workflows` und `cluster` sprechen über eine authentifizierte Inspect-Oberfläche mit einem laufenden Prozess. Du liest live Subscriptions, Request-Traces, Workflow-Läufe und ihre Journale — auch Dead-Letter-Läufe, die sich wiederholen lassen — statt sie aus Logzeilen zu rekonstruieren.
`voltro check` validiert die Verdrahtung, ohne etwas zu starten: ob jede Procedure eine Zugriffsentscheidung hat, ob ein Guard einen Scope verlangt, den keine Rolle vergibt, ob ein Binding unerreichbar ist. Der Check, den du in CI und im Review fahren kannst.
`voltro db plan` druckt die Migration, die eine Schema-Änderung erzeugen würde, vor dem Anwenden. Einen Plan zu prüfen ist die Gewohnheit, um die das deklarative Migrationsmodell gebaut ist — du genehmigst Operationen, statt sie zu schreiben.
Die Befehle für den Alltag.
| Befehl | Was er tut |
|---|---|
| voltro dev | Fährt api + web hoch, beobachtet, führt Codegen aus, aktualisiert Routen heiß, wendet Schema-Änderungen beim Boot an. |
| voltro create-project | Scaffoldet einen Workspace mit api, Frontend, Ports und optionaler Deploy-Baseline. |
| voltro db plan / apply | Diffed dein Schema gegen die Live-Datenbank, druckt die Operationen, wendet sie nach Freigabe an. |
| voltro build / serve | Kompiliert den Serve-Pfad in ein Artefakt für schnellen Kaltstart und fährt es in Produktion. |
| voltro doctor / check | Produktions-Preflight und Verdrahtungsprüfung — inklusive Guards, die Scopes verlangen, die keine Rolle vergibt. |
| voltro inspect / logs / traces | Liest Subscriptions, Traces und Workflow-Journale einer laufenden App über eine authentifizierte Oberfläche. |
Häufige Fragen
Ist die CLI Pflicht, oder kann ich eigenes Tooling nutzen?
Sie ist der unterstützte Weg, weil Discovery, Codegen und die Boot-Sequenz in ihr leben — aber sie ist ein normales Paket auf normalem Node, und ein damit gescaffoldetes Projekt ist ein gewöhnlicher Workspace, den du mit deiner eigenen Pipeline bauen und deployen kannst.
Telefoniert irgendetwas nach Hause?
Nein. `voltro telemetry` existiert, um zu melden, dass nichts erhoben wird — es gibt nichts abzuwählen. Der eine Netzwerkaufruf ist die optionale Cloud-Registrierung beim Scaffolden, und nur wenn du eingeloggt bist; `--no-register` überspringt sie.
Wie steige ich über eine Breaking Change hinweg?
`voltro update` hebt jedes Framework-Paket, installiert, gleicht die von deiner App deklarierten Peer-Ranges an und fährt die mit der Zielversion ausgelieferten Codemods — schreibt deinen Quellcode um, wo es automatisierbar ist, und druckt geschriebene Schritte, wo nicht.
Kann ich eigene Templates hinzufügen?
Ja. Ein Template ist ein Verzeichnis mit einem Manifest und den zu kopierenden Dateien — keine Plugin-API. Zeig die CLI auf dein eigenes Repository privater Templates, und sie scaffolden genau wie die mitgelieferten.
Was passiert bei einer fehlenden Pflicht-Umgebungsvariable?
Die App verweigert den Boot und benennt die Variable, statt zu starten und beim ersten Request zu scheitern, der sie gebraucht hätte. Secrets, die dem Framework gehören, werden in der Entwicklung pro Projekt in eine gitignorierte Datei gemintet — und das Minten verweigert, solange diese Datei nicht wirklich ignoriert ist.
Die CLI steuert die ganze Runtime.
Ö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.