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