Ship it your way.
Bare, Docker, or Kubernetes.
The app you write doesn’t change with the target — only the packaging does. Pick a baseline at create-project time or switch later with one command. Self-host on a single box, a Compose stack, or a Kubernetes cluster; offload edges to serverless. Running the same runtime managed on Voltro Cloud is coming soon.
# 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 startPick a target; the app stays the same.
Three baselines
bare gives a systemd unit + env example; compose gives Dockerfiles + a Postgres docker-compose (dev + prod variants); helm gives a Kubernetes chart with per-env values, Deployment, Service, Ingress and a Postgres StatefulSet. Switch with voltro baseline set.
Self-host anywhere
Node 24+, Postgres 16+ (pgvector for AI/search, wal_level=logical for subscriptions), and a reverse proxy (Caddy / nginx / Cloudflare). Optional Redis + object storage. No Kubernetes required — a single origin is enough.
Serverless functions
*.serverless.ts units run self-hosted on Node or offload to Cloudflare Workers / Scaleway Functions. They get HttpClient + ctx.env only — reach for one when you need process isolation or independent scaling; otherwise prefer an action.
Static-site deploy
voltro static ships a prerendered dist/ to Cloudflare Pages, S3-compatible hosts (AWS / Scaleway / R2 / B2 / MinIO) or Netlify — Content-Type, Cache-Control and SPA fallback set for you. A render-mode gate blocks non-static apps unless you opt in.
Scale to zero
dormancy: "sleep" plus the voltro dormancy orchestrator idle apps down to roughly zero cost; they wake on the next request, WebSocket upgrade, or a due scheduled job. Needs a SQL store to track wakeups.
Or run it managed (coming soon)
Voltro Cloud will run the exact same runtime, so nothing about your app changes — it adds managed infrastructure, a deploy pipeline and hosted observability. Managed cloud hosting is coming soon; today you self-host, and you can eject back to a baseline any time.
The job definition doesn’t care where it runs.
One app, any topology
The same schedule runs unchanged on one box, a multi-instance fleet, or a Kubernetes CronJob — voltro schedule-manifest even generates the k8s / AWS / GCP / Azure manifest for you. Because deploy config is packaging, not code, moving from Compose to Helm — or to Cloud and back — never touches a handler.
Deployment ties into operations.
Open the framework. See it for yourself.
Every primitive on this page is in the framework today. Clone the starter, run `voltro dev`, and have it on screen in two minutes.