Ship auf deine Art.
Bare, Docker oder Kubernetes.
Die App, die du schreibst, ändert sich nicht mit dem Ziel — nur das Packaging. Wähl eine Baseline beim create-project oder wechsle später mit einem Befehl. Self-host auf einer Maschine, einem Compose-Stack oder einem Kubernetes-Cluster; lagere Edges an Serverless aus. Dieselbe Runtime managed auf Voltro Cloud kommt bald.
# pick a baseline at create time…
$ voltro create-project my-app --baseline compose
# …or switch later
$ voltro baseline set helm
# build + run, anywhere Node + Postgres run
$ voltro build && voltro startWähl ein Ziel; die App bleibt dieselbe.
Drei Baselines
bare gibt eine systemd-Unit + Env-Beispiel; compose gibt Dockerfiles + ein Postgres-docker-compose (dev + prod); helm gibt ein Kubernetes-Chart mit Pro-Env-Values, Deployment, Service, Ingress und einem Postgres-StatefulSet. Wechsel mit voltro baseline set.
Überall self-hosten
Node 24+, Postgres 16+ (pgvector für AI/Search, wal_level=logical für Subscriptions) und ein Reverse-Proxy (Caddy / nginx / Cloudflare). Optional Redis + Object Storage. Kein Kubernetes nötig — ein einzelner Origin reicht.
Serverless-Funktionen
*.serverless.ts-Units laufen self-hosted auf Node oder lagern auf Cloudflare Workers / Scaleway Functions aus. Sie bekommen nur HttpClient + ctx.env — greif dazu, wenn du Prozess-Isolation oder unabhängiges Scaling brauchst; sonst nimm eine Action.
Static-Site-Deploy
voltro static shippt ein prerendered dist/ zu Cloudflare Pages, S3-kompatiblen Hosts (AWS / Scaleway / R2 / B2 / MinIO) oder Netlify — Content-Type, Cache-Control und SPA-Fallback für dich gesetzt. Ein Render-Mode-Gate blockt Nicht-Static-Apps, außer du optest ein.
Scale-to-Zero
dormancy: "sleep" plus der voltro-dormancy-Orchestrator idlen Apps auf nahezu null Kosten; sie wachen beim nächsten Request, WebSocket-Upgrade oder einem fälligen geplanten Job auf. Braucht einen SQL-Store, um Wakeups zu tracken.
Oder betreib es managed (bald)
Voltro Cloud fährt exakt dieselbe Runtime, also ändert sich nichts an deiner App — es ergänzt managed Infrastruktur, eine Deploy-Pipeline und gehostete Observability. Managed Cloud-Hosting kommt bald; heute self-hostest du und kannst jederzeit zurück auf eine Baseline ejecten.
Der Job-Definition ist egal, wo sie läuft.
Eine App, jede Topologie
Derselbe Schedule läuft unverändert auf einer Maschine, einer Multi-Instance-Flotte oder als Kubernetes-CronJob — voltro schedule-manifest generiert sogar das k8s- / AWS- / GCP- / Azure-Manifest für dich. Weil Deploy-Config Packaging ist, kein Code, berührt der Wechsel von Compose zu Helm — oder zu Cloud und zurück — nie einen Handler.
Was ein Produktions-Deploy im Betrieb kostet.
Datenbank-Engines, auf die es zeigen kann — die Deploy-Form ändert sich mit der Wahl nicht
veröffentlichte Pakete, von denen ein Deployment die Handvoll ausführt, die deine App importiert
Vom Repository zum ausliefernden Container.
- 1
Bauen
Der Serve-Pfad wird zu einem Artefakt kompiliert, statt beim Boot Hunderte Module aufzulösen — gemessen rund 176 ms bis bereit gegen rund 1010 ms ohne, auf derselben Fixture.
- 2
Schema anwenden
Ein Job vor dem Deploy diffed die Deklaration gegen die Live-Datenbank. Er verweigert, statt zu raten, wenn seine Antwort von der des ausliefernden Prozesses abwiche.
- 3
Starten
Ein Container und eine Datenbank sind ein vollständiges Deployment. Compose, Helm und ein schlichtes systemd-Ziel sind Baselines, die du beim Scaffolden wählst — keine Umbauten.
- 4
Rollen
Der Shutdown drainiert: laufende Requests werden fertig, Timer und Change-Subscriptions werden freigegeben, und die Analytics-Queue wird in die Senke geflusht, bevor der Prozess endet.
Deployment im Detail.
Was braucht eine Voltro-App zum Laufen?
Einen Node-Prozess und eine Datenbank. Das ist die gesamte Laufzeitanforderung — kein Message-Broker, kein Workflow-Dienst, keine separate Cache-Ebene, kein Sidecar. Durable Workflows journalisieren in deine Datenbank, geplante Jobs koordinieren sich darüber, und der Cache ist Memory, bis du anders entscheidest.
Alles Weitere ist additiv und opt-in. Redis kauft dir instanzübergreifende Reaktivität auf Dialekten ohne flottenweiten Change-Feed und einen geteilten Cache, sobald du mehrere Instanzen hast; keines ist nötig, um korrekt zu sein — nur, um auf eine bestimmte Weise zu skalieren.
Das zählt am Anfang und am Ende am meisten. Ein erstes Deployment ist ein Container und ein Managed-Postgres, und derselbe Code läuft später hinter einem Load Balancer mit Replicas — ohne Re-Architektur, weil die Teile, die sonst eine erzwingen, bereits koordiniert sind.
Wie komme ich vom Repository zu etwas Laufendem?
Über eine Baseline: eine neben deinem Projekt gescaffoldete Deploy-Oberfläche. Ein Docker-Compose-Stack für eine Maschine, ein Helm-Chart für Kubernetes oder gar nichts, wenn du schon eine Pipeline hast. Die Anwendung ist in jedem Fall identisch; nur die Schicht drumherum unterscheidet sich.
`voltro build` kompiliert den Serve-Pfad in ein einziges Artefakt vor — Produktion lädt also eine Datei, statt beim Boot Hunderte Module aufzulösen. Auf dem Fixture des Frameworks gemessen etwa fünffach schneller, und der Gewinn ist größer auf einem kleinen Container, wo die Modulauflösung den Kaltstart dominiert.
Der Build erzeugt außerdem eine in sich geschlossene Web-Ausgabe — das Server-Bundle inlined, was es braucht — ein Produktions-Image liefert also fast keine node_modules aus. Eine statische Site ohne native Abhängigkeit lässt sie ganz weg.
Was ist mit Serverless und statischen Sites?
Beides ist erstklassig statt ein Workaround. Ein eigenständiges Function-Bundle deployt mit `voltro serverless` nach Node, Cloudflare oder Scaleway; eine statische Site veröffentlicht `voltro static` auf Cloudflare Pages, S3 oder Netlify. Keines braucht einen dauerhaft laufenden Server.
Die Kombination ist die übliche Form für ein kleines Produkt: eine statisch gerenderte Marketing-Site auf einem CDN plus eine Serverless-Function für das eine dynamische Stück, etwa ein Kontaktformular. Ein Template liefert diese ganze Form mit, du setzt sie also nicht zusammen.
Die Wahl gilt pro App, nicht pro Projekt. Ein Workspace kann eine dauerhaft laufende api, eine statische Marketing-Site und eine Serverless-Function-Library halten — aus einem Repository an drei verschiedene Orte deployt.
Wie verhält sich die App in Produktion gegenüber der Entwicklung?
Das Framework behandelt diesen Unterschied als Gefahr, nicht als Detail. Entwicklung und Produktion sind zwei unabhängige Boot-Pfade, und eine Fähigkeit, die in einem verdrahtet ist und im anderen nicht, funktioniert lokal und wird in Produktion still zum No-op — was hier wiederholt passiert ist und heute von einem aus dem Quellcode abgeleiteten Check bewacht wird statt von einer gepflegten Liste.
Produktion ist außerdem bewusst strenger. Ein fehlendes Session-Secret ist eine Boot-Verweigerung, kein Entwicklungs-Fallback, der still echten Traffic signiert. Ein scheiterndes Startup-Modul verweigert den Boot, statt zu warnen und trotzdem auszuliefern. Eine Procedure ohne Zugriffsentscheidung stoppt den Prozess.
Für Hosts, die auf null skalieren, stellt sich `voltro dormancy` vor die App, stoppt sie im Leerlauf und weckt sie beim nächsten Request — eine Ein-Knoten-Antwort, die keine Managed-Plattform verlangt.
Die Deploy-Wege und wann welcher passt.
| Weg | Passt, wenn |
|---|---|
| Compose-Baseline | Eine Maschine oder VM: App, Datenbank und optional Redis, mit dem Projekt gescaffoldet. |
| Helm-Baseline | Kubernetes: ein Chart, das dir gehört, mit bereits koordiniertem Replica- und Scheduling-Verhalten. |
| Serverless-Functions | Isolierte Arbeit ohne dauerhaft laufenden Server — Node, Cloudflare oder Scaleway. |
| Statische Site | Vorgerenderte Seiten auf ein CDN: Cloudflare Pages, S3 oder Netlify, ohne JS, wo die Seite es erlaubt. |
| Scale to Zero | Ein-Knoten-Dormancy: im Leerlauf stoppen, beim nächsten Request wecken, ohne Managed-Plattform. |
| Managed Cloud | Die Control-Plane registriert und beobachtet heute self-hosted Apps; Managed-Deploy kommt. |
Häufige Fragen
Brauche ich Kubernetes?
Nein. Ein einzelner Container und eine Datenbank sind ein vollständiges Deployment, und derselbe Code skaliert später ohne Re-Architektur raus. Helm ist eine Baseline unter mehreren — angeboten, weil manche Teams ohnehin Kubernetes fahren, nicht weil das Framework es braucht.
Brauche ich Redis?
Nur für bestimmtes Verhalten: instanzübergreifende Reaktivität auf Dialekten ohne flottenweiten Change-Feed und einen über Instanzen geteilten Cache. Auf Postgres oder MySQL/MariaDB mit einer Instanz brauchst du keines von beidem.
Wie groß ist ein Produktions-Image?
Klein, weil der Build in sich geschlossen ist: das Server-Bundle inlined das Framework, die Laufzeit braucht also fast keine node_modules. Eine statische oder SSR-Site ohne native Abhängigkeit kommt ganz ohne aus — an den eigenen Apps des Frameworks etwa auf ein Drittel des naiven Baums gemessen.
Kann ich auf meine eigene Infrastruktur deployen?
Das ist die Standardhaltung. Das Framework ist eine Runtime neben deiner Datenbank — dein Connection-String, deine Backups, deine Zugriffsregeln — und nichts wird durch fremde Infrastruktur geleitet, außer du wählst ausdrücklich ein Managed-Ziel.
Was unterscheidet voltro dev von Produktion?
Produktion ist bewusst strenger: kein Entwicklungs-Fallback für ein Session-Secret, ein scheiterndes Startup-Modul verweigert den Boot, und eine unentschiedene Zugriffsdeklaration stoppt den Prozess. Die zwei Boot-Pfade sind außerdem gegen Drift bewacht, denn eine Fähigkeit, die nur in einem verdrahtet ist, ist die Fehlerklasse, die erst in Produktion auffällt.
Deployment verzahnt sich mit dem Betrieb.
Observability
Jeder Deploy shippt OpenTelemetry-Spans und -Metriken — verdrahte sie mit deinem Sink oder lies sie in-app.
CLI
voltro build / start / serve / baseline / static / dormancy steuern jeden Deploy-Pfad.
Datenbanken
Zeig auf jeden unterstützten Dialekt; Read-Replicas und CDC funktionieren über Topologien gleich.
Ö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.