Cloud roadmapqcloud
The managed control plane, honestly tracked.
Qirava Cloud is the managed, multi-tenant control plane — a DMS that manages other DMSes, billed per resource. Control plane v1 is built: the _cp_* catalogs, the cloud.* functions (infra effect simulated), and the RBAC-gated Cloud Console. The live infra, public signup, the FIFO-hold cutover, delegation, and metered payment are planned. No dates — only state.
Status board
Built control plane, planned infra
Three lanes, no dates. The BUILT lane is control plane v1 plus the OSS-core primitives it reuses; PARTIAL is the seams whose real effect is not yet wired; PLANNED is the live managed-cloud layer — the node agent, real spawning, the silent cutover, signup, delegation, billing, and domains.
Shipping today
Present in the codebase and usable now.
- Control plane v1 — the _cp_* catalogsTenants, nodes, plans, subscriptions, usage, invoices, and an audit log are modeled as data in the control plane's own DMS — the same config-as-data pattern as _sys_*.
- cloud.* functionsprovision, scale_vertical, scale_horizontal, switch_mode, suspend, resume, terminate, and generate_invoice make real _cp_* writes today; the infra effect is simulated and badged PLANNED in the UI.
- The Cloud Console (a Quill app)An RBAC-gated console — Overview, Tenants, Plans, Nodes, Billing, Governance (custodian > admin) — built as a Quill app, the way Studio is the DMS's admin app.
- Resource governance (the executor)The bounded executor caps memory and work per call — the per-DMS cap mechanism the control plane sets and meters.
- Single-leader replication + change-streamThe replication seam every cutover reuses — committed op-frames stream master → follower (single-direction today).
- The cloud is itself a DMSThe control plane runs as a DMS hosting a cloud app, reusing the worker pipeline, execute(), and Quill — only the cloud.* functions are new, not a forked engine.
In progress
A working seam exists; the rest is designed, not yet built.
- Live infra effectcloud.* writes the catalogs, but the actual DMS spawn / scale / move is simulated and badged PLANNED — the node agent that performs it is the next build.
- Confidential-VM attestation seamA tenant DMS should attest from inside a SEV-SNP / TDX VM before receiving its seed; the setup runbook exists, the in-DMS attestation handshake is being designed.
Planned
Designed but not yet built — no dates promised.
- Node agent + DMS control socketThe cloud's per-node hands — spawn/stop, cgroup caps, routing — driving a narrow, envelope-only lifecycle socket on each DMS that never reads tenant data.
- Real DMS spawning + dense packingSpawn isolated, hard-capped DMS processes and bin-pack many per node, so one account can run many isolated DMSes and nodes are not wasted.
- FIFO-hold cutover trioWrite-forwarding + epoch-fencing + location repoint — the primitive that makes vertical/horizontal scale, live migration, and upgrades silent (no restart).
- Public signup + self-serveOpen email signup, purchase a resource pool, and self-serve create DMS instances, databases, and worker apps.
- Email-scoped delegationGrant another email a scope to manage one of your DMSes — cross-account delegation bridged into the DMS's own RBAC.
- Metering → billing → paymentMeter thread / RAM-GB / storage-GB per DMS and bill per unit on an hourly / monthly / yearly cycle, with real payment.
- Domain automationA default id.qirava.in subdomain per DMS plus custom domains via a cloudflared tunnel and CF Zero Trust.
- Signed-release CI/CD + rolling updatesM-of-N-signed, transparency-logged releases rolled out node-by-node with proper drain and health-gated rollback.
Sourced from the Cloud control plane and Scaling & upgrades architecture pages — the single source of truth. The managed-service layer is planned on top of the Apache-2.0 DMS core, and the direct/self-host path stays open.