Managed backends,
provisioned per project.
Self-hosting means you stand up Postgres, Redis and object storage and wire the credentials yourself — which is what you do today. With managed cloud hosting, Cloud will provision them per project on managed, EU-hosted infrastructure and keep the connection strings in a managed secret manager, never in the control-plane database or your logs. That is coming soon.
# What Cloud provisions per project (once, then reused)
postgres neon ● eu LISTEN/NOTIFY · pgvector
cache scaleway ● fr-par @voltro/cache
storage s3-compat ◐ eu @voltro/plugin-storage
secrets secret mgr ● never in control-plane db or logsWhat Cloud provisions
Created once per project, reused across deploys — you never copy a connection string into an env file.
Managed Postgres
On the roadmapA per-project Postgres database and branch via Neon, created on first deploy and reused. The same Postgres your app targets self-hosted — LISTEN/NOTIFY reactivity, pgvector, the lot.
Managed Redis / cache
On the roadmapA managed cache via Scaleway, wired to the framework’s @voltro/cache layer for query caching, single-flight and SWR — no separate Redis to run.
Object storage
On the roadmapS3-compatible object storage for the @voltro/plugin-storage surface: uploads, presigned URLs, ranges and image transforms. (Provisioning into the deploy step is landing.)
Secrets, kept managed
On the roadmapConnection strings and provider credentials live in a managed secret manager. The control-plane database and logs never see them — a boundary you’d otherwise have to enforce yourself.
EU-hosted, data-resident
On the roadmapRuntime and data sit in the EU (Scaleway fr-par / Neon EU) today. Combined with the framework’s data-residency primitive, a tenant can be pinned to a home region and fail closed everywhere else.
Free-tier quotas
On the roadmapThe free tier caps storage and compute (e.g. 512 MB DB storage) and suspends rather than billing overage — no surprise invoice while you evaluate.
Your database, still yours
No lock-in at the data layer
Because Cloud runs the same runtime and the same @voltro/database engine you’d self-host, the schema and migrations are portable. Eject to a compose or helm baseline and point the app at your own Postgres — nothing about the data layer is Cloud-specific.
The managed pieces are operational convenience, not a proprietary datastore. What you build here you can run anywhere Postgres runs.
Related capabilities
See it running.
Open the dashboard on a live demo project and click through the panels yourself — logs, traces, workflows, migrations and more.