Voltro Cloud

Voltro Cloud is the managed tier of the same runtime you run yourself. It's not a fork — voltro start is what powers your production instances, just with custom domains, multi-region routing, provisioned Postgres / Redis / object storage, and a control plane that handles deploys.

Status: managed cloud deploy + provisioning is coming soon and is not yet available. What's live today is the Free control plane: sign up and use it to register and observe your self-hosted apps (hosted observability, quotas, governance, teams). The managed-tier features described below are the planned shape of Voltro Cloud — see the per-section notes.

#When to use Cloud vs self-host

	Cloud (coming soon)	Self-host (today)
Managed Postgres + Redis + pgvector	✓	You provision
Multi-region + edge routing	✓	You set up Caddy / Cloudflare / your CDN
Custom domains + automatic SSL	✓	You manage certs
AI provider gateway (key rotation, fallback)	✓	You wire AI_PROVIDER directly
Per-tenant vanity domains	✓ (Enterprise)	Possible but you build the routing
Observability (logs, traces, metrics)	✓	You wire OpenTelemetry to your sink
Audit log retention	≥ 90 days	Whatever you configure
You own the data	✓ — export anytime	✓
You own the source code	✓	✓

Pre-release: the Free tier is live — sign up through the shared Voltro login (passwordless, an email one-time code) and use the control plane to register + observe your self-hosted apps. Managed cloud deploy + provisioning is coming soon (voltro cloud deploy prints control-plane deploy pipeline pending — not yet available until it ships); paid tiers open with it at launch.

#The voltro cloud client

The control-plane client is voltro cloud, not a top-level voltro deploy. It authenticates against the control plane (base url via VOLTRO_CLOUD_URL) and manages projects + env vars:

voltro cloud login [--token <t>]          # store a session token in ~/.voltro/credentials.json
voltro cloud whoami                       # the current account
voltro cloud projects                     # list your projects
voltro cloud project link <slug> [--project P] # bind one local project
voltro cloud env list [--project P]       # list a project's env vars
voltro cloud env set <KEY> <VALUE> [--project P]
voltro cloud env pull [--project P]       # write .env.cloud from the project's env
voltro cloud import                       # scaffold voltro.cloud.toml from app.config.ts

When a workspace contains multiple projects, project link requires --project and writes the binding only to that project's project.json.

#Scaffolding the deploy config — voltro cloud import

voltro cloud import reads the app's app.config.ts (name + type) and writes a voltro.cloud.toml next to it. It refuses to overwrite an existing file. The generated shape:

# voltro.cloud.toml — generated by `voltro cloud import`.
# Describes how this app deploys to the framework cloud control-plane.

[project]
name = "acme"
type = "api"

[deploy]
# Target region + replica count. Tune before `voltro cloud deploy`.
region = "auto"
replicas = 1

[env]
# Project env-var names resolved from the control-plane at deploy time.
# Use `voltro cloud env set <KEY> <VALUE>` to populate them.

#Deploy is pending

voltro cloud deploy exists but the control-plane deploy pipeline is not yet available — running it prints control-plane deploy pipeline pending — not yet available. Build, upload, migrate, traffic-shifting, and one-click rollback are the planned shape of that pipeline; until it lands, use the voltro cloud env + project commands above to prepare a project.

#Environments

Per-project environments (preview / staging / production), each with its own env vars + DB + storage bucket, are part of the planned control-plane surface. Manage env vars today with voltro cloud env list/set/pull.

#Roles and rights

An organization has three roles, and one flag:

	Owner	Admin	Member	+ Billing access
See projects, members, usage	✓	✓	✓	✓
Projects, apps, environments, domains, env vars	✓	✓
Invite and remove members, service tokens	✓	✓
Plan, seats, payment method, invoices, invoice preview	✓	✓		✓
Change roles, grant billing access	✓

Billing access is a switch on a membership, set by owners on the Members page: a billing manager sees costs and invoices and may change plan, seats and payment method without touching a project. Owners and admins hold those rights anyway. Roles are changed on the same page (admin ↔ member); the owner role is not assignable — ownership is transferred, not assigned.

WorkOS is the directory of record. Every organization and membership is mirrored into WorkOS — the organization, and an organization membership per person with the role slug owner, admin, member or billing (a member with billing access). A change made in WorkOS (admin portal, SCIM, SSO provisioning) is applied here at once through the /webhooks/workos endpoint; an hourly reconcile catches a webhook that was lost. A change made here is queued in the same transaction and reaches WorkOS as soon as it is saved — usually within a second — retried with backoff until it does; until then WorkOS cannot overwrite it. A person who has not signed in through WorkOS yet is mirrored on their first sign-in; the Members page shows the link state per person. Only active WorkOS memberships count — a pending WorkOS invitation is not a member. Ownership never moves through WorkOS: it cannot create, demote or remove an owner.

Ownership, leaving, deleting. Every organization has exactly one owner. The owner hands it to another member on the Members page (they become the owner, the previous owner stays as an admin). Any other member can leave; the owner leaves only by handing the organization over or deleting it. The owner deletes an organization once its projects are deleted: its subscription ends first, and all memberships, pending invitations and members' CLI tokens for it go with it. Removing or leaving takes effect on the next request — the person's CLI tokens for that organization are revoked and their seat is released.

Deleting your account (Settings) deletes it everywhere — Cloud and your Voltro login. Organizations you own alone and without projects are deleted with it; you leave every other one. It is refused while you own an organization other people belong to (hand it over first) or one with projects. Signing up through an invitation link creates no personal organization — the inviting organization is your first one.

One WorkOS environment, every Voltro product. Cloud and the products that follow hang off the same WorkOS environment per stage: one login, one set of organizations and roles. Each product signs in through the same hosted Voltro login as its own WorkOS application — whoever is signed in to one product is not asked again by the next. An invitation link opens that login with the invited address filled in and returns to the invitation; signing in with another account is an explicit fresh sign-in. The dashboard session is an HttpOnly cookie: script on the page never reads it, so an injected script cannot carry it away. Permissions are namespaced by product and attached to the four WorkOS roles:

Role slug	Permissions
owner	everything below, plus org:roles
admin	org:settings, org:members.invite, org:members.remove, org:tokens.manage, org:billing.view, org:billing.manage, cloud:projects.manage, plus everything a member has
member	org:members.view, org:usage.view, cloud:projects.view
billing	a member plus org:billing.view, org:billing.manage

Create these four roles with exactly these permission slugs in the WorkOS environment (Roles → Permissions); each product checks only its own namespace. Every rule is enforced by the API from one permission matrix (@voltro-cloud/contract, permissions.ts, WORKOS_ROLE_PERMISSIONS is the same sheet); the dashboard reads the same matrix to show only the controls that apply, so a control that is visible is a control that works.

#Custom domains

Coming soon with managed cloud hosting — not yet available. When it ships, you'll add a domain in the Cloud UI and the platform handles:

• DNS verification (TXT record)
• ACME-issued SSL (Let's Encrypt or Google Trust Services)
• Auto-renewal
• Per-tenant vanity domains (Enterprise) — tenant1.your-product.com routes to the right tenant scope automatically

#Observability

Available today for your registered self-hosted apps (this is the live Free-tier control plane). OpenTelemetry-native:

• Logs flow to the project's log stream (search + filter in-UI; export to Datadog / Loki / etc.)
• Traces for every mutation, query, workflow, agent run
• Metrics for request rates, error rates, p50/p95/p99 latencies, AI token spend per tenant

#Provisioning

Coming soon with managed cloud hosting — not yet available. When it ships, Cloud will provision managed Postgres, Redis, R2, Resend, etc. on your behalf. You'll also be able to BYO (point at your own Neon, Upstash, etc. via env vars) — billing for those goes through your account with the provider. Today you provision these yourself and self-host.

See the Cloud Premium Matrix for the full feature breakdown.

#Migration from self-hosted to Cloud

Deploying onto Cloud is coming soon — not yet available. You can prepare a project today (scaffold the config, populate env), but there is no managed destination to deploy to yet.

voltro cloud import   # scaffold voltro.cloud.toml from the app's app.config.ts

voltro cloud import reads the app's app.config.ts and writes a voltro.cloud.toml (project name + type + a deploy/env skeleton). Populate the project env with voltro cloud env set. When managed hosting ships, your local Postgres data won't be migrated for you — you'll use pg_dump + pg_restore against the target database directly.