Self-host guides
vura build emits a dist/ directory. Cache revalidation, websockets, ordinary background tasks, and cron run in the plain Node output without Vura Platform credentials. No account required. Standalone task state and waits are in-process; restart-durable queue delivery and suspend/resume currently require the managed broker.
Route kind support by target
| Target | Serverless | Hot (WebSocket) | Task / cron |
|---|---|---|---|
| Node / VPS | yes | yes | yes |
| Docker | yes | yes | yes |
| Fly.io | yes | yes | yes |
| Railway | yes | yes | yes |
| Cloudflare Workers | yes | no | yes |
| AWS Lambda | yes | no | yes |
Vura hot routes (WebSockets, in-memory state) require a persistent process. Vura's current Cloudflare and Lambda adapters do not implement that hot-route contract; use the persistent Node output for these routes. This does not describe all WebSocket capabilities offered by those providers. vura build warns by name when hot routes are excluded.
Page mode support by target
| Target | static |
client |
hybrid |
server |
revalidate (ISR) |
streaming |
|---|---|---|---|---|---|---|
| Node / VPS | yes | yes | yes | yes | yes | yes |
| Docker | yes | yes | yes | yes | yes | yes |
| Fly.io | yes | yes | yes | yes | yes | yes |
| Railway | yes | yes | yes | yes | yes | yes |
| Cloudflare Workers | yes | yes | yes | yes | no | yes |
| AWS Lambda | yes | yes | yes | yes | no | buffered |
static, client and hybrid pages are rendered at build time; every target
serves them as files. server pages render per request, with their loaders, on
every target.
Where a target cannot match the Node server, vura build says so by name
rather than shipping quietly: an revalidate page that will not be cached, a
streaming page that will be buffered, and a server page that cannot be
bundled at all (which fails the build outright, because a build that ships
without a page serves 404 for it).
The CI-tested promise
Middleware and actions: src/middleware.ts and server actions run in Node,
Docker, Fly, and Railway output, but are not executed by the Cloudflare or Lambda
adapters. On those targets, authorization must live in the API handler or page
loader accessing protected data. Server-page support does not imply middleware
or action support. See middleware and
actions.
Every guide below runs in CI on every commit — the exact commands you'll paste, executed by the seven jobs in .github/workflows/selfhost.yml. If a guide breaks, the build is red.
The CI jobs execute fenced code blocks extracted directly from each guide, so a guide can never silently drift from what CI actually runs.
No-gating commitment
The MIT license and commitment not to move framework features behind the managed service are documented in GOVERNANCE.md. The self-host audit verifies ordinary Node capabilities without platform credentials, including assertions A0–A12. It does not prove restart-durable task execution or identical capabilities on every target; those limitations are stated above.
Choose a target
- Node / VPS — the simplest path. One Node process, one port. All route kinds. Add a reverse proxy (Caddy) for HTTPS and WebSocket passthrough.
- Docker — containerized. Same Node server, reproducible image. Good baseline for Kubernetes or any container-capable host.
- Fly.io — the recommended host for hot routes. Persistent machines, global anycast, built-in TLS.
fly deploy ./distis the one-command path. - Railway — Dockerfile-based deploy on Railway's managed infrastructure. Shares the Docker guide's Dockerfile; upload
dist/so the build context matches it. - Cloudflare Workers — edge-native serverless and task routes. Hot routes not supported. Uses
@celsian/vura-adapter-cloudflare+wrangler deploy. - AWS Lambda — serverless and task routes via Lambda + API Gateway SAM. Hot routes not supported. Uses
@celsian/vura-adapter-lambda+ AWS SAM.