The plane is just a DMS
The control plane runs as a normal Qirava DMS with a cloud app on top. No new runtime, no special server — the same execute() funnel, the same auth checkpoints. It manages the fleet from inside its own catalogs.
Qirava Cloudqcloud
Managed DMS capacity: threads, RAM, storage.
Qirava Cloud is the planned managed-service layer for DMS. Today it is a real control-plane DMS with _cp_* catalogs, cloud.* functions, and an RBAC console. The business model is simple capacity — sell thread, RAM, and storage — while the long-term infra goal is no-disruption vertical and horizontal scaling of tenant DMS instances.
tenant DMS goal1
_cp_* control catalogs7
capacity units3
infra effects todaySIM
What it is
A control plane that sells capacity — not data access
The Cloud is a Qirava DMS running a cloud app, the same way Studio is the system app. It orchestrates the fleet — provisioning, placement, scaling, billing — and that is all. The tenant DMS it stands up is a separate instance with its own data, WAL, governance, and Studio; the two authority domains never cross.
Hard tenant isolation
A provisioned tenant is its own DMS instance: own data, WAL, _sys_* catalogs, seed, custodian governance, and Studio UI. A tenant never sees the control plane or any sibling — the cap is the only thing shared.
Envelope, not plaintext
The Cloud allocates resources and manages lifecycle; it has no privileged side-door into a tenant. The same L1→L2→L3 gate the core enforces keeps the operator out of tenant tables — by design, not by policy.
Features
The managed-service surface
The Console exposes the full lifecycle of a tenant as a set of governed actions. Each one persists durably to the control catalogs; each one writes an audit row; each one is gated by the operator's cloud role, deny-by-default.
Capacity placement
Create a tenant and the placer runs first-fit bin-packing over the node fleet, picking the first node with cap headroom and bumping its allocation — or flagging the operator when the fleet is full.
Vertical and horizontal scaling
Grow one tenant's CPU/memory/storage cap, or grow its cluster by adding replicas on distinct nodes. The new cap and replica count persist to the tenant row and the node allocations adjust.
Switch mode, non-destructively
Flip a tenant between standalone and cluster either direction. Because the on-disk storage layout is identical across modes, the switch is non-destructive — it just adds or drops followers.
Lifecycle control
Suspend a tenant on non-payment, resume it in place, or terminate it — releasing its node allocation. Each transition is one durable status change on the tenant row.
Metering and invoices
Usage counters (thread-seconds, GB-hours, GB stored, GB bandwidth) feed a per-unit plan — priced per thread-hour, GB-hour, GB-month, and GB transfer — and generate durable invoices. No fixed tiers.
Audited, role-gated Console
Every mutation writes a _cp_audit row (operator, action, tenant, node, result). The Console renders only the screens the signed-in cloud role can reach, and each action re-checks the role server-side.
How it works
Persisted in catalogs, run through one funnel, gated by role
There is no magic and no hidden service. The control plane keeps its entire state in a handful of catalogs, mutates it only through one set of functions, and gates those functions on the operator's cloud role.
Control plane ≠ tenant
Cloud governance (the operators of the fleet) is a completely separate authority from any tenant's custodian. A cloud admin governs plans, nodes, caps, and billing — and never a tenant's data or governance.
The whole fleet is rows
_cp_tenants, _cp_nodes, _cp_plans, _cp_subscriptions, _cp_usage, _cp_invoices, and _cp_audit hold the entire control-plane state. There is no out-of-band config — placement and billing read these tables.
One orchestration funnel
Every change runs through a cloud.* function — provision, scale_vertical, scale_horizontal, switch_mode, suspend, resume, terminate, generate_invoice — reached via execute(). One write path, durable through the WAL.
Role gates, re-checked server-side
The Console only shows what your cloud role permits, but the gate that matters is in the function: each cloud.* re-checks ctx.role and refuses if it is below the required rank. The UI is a convenience, not the boundary.
Bin-packing placement
The placer walks nodes in a stable order and takes the first with enough thread/memory/storage headroom, then records the allocation delta. Deterministic, so placement is testable and repeatable.
Real control state, simulated infra
Each cloud.* function persists the intended new state and returns it; the infrastructure effect — spawning the tenant DMS, applying OS caps, taking payment — is simulated and badged. The data model is real today.
Architecture
The control plane over the tenant fleet
An operator action enters the Console, runs through the cloud.* funnel, persists to the _cp_* catalogs, and the placer assigns a node — at which point a tenant DMS would be stood up. The persistence is real (BUILT); the physical infra step is SIMULATED.
BUILTConsoleRBAC-gated, deny-by-default
BUILTcloud.* funnelexecute() · audited
BUILT_cp_* catalogsdurable · WAL-backed
BUILTplacerfirst-fit bin-pack
PLANNEDtenant DMSspawn · cap · scale
Status
What's built, what's simulated, what's planned
The control-plane DATA MODEL is built and tested — provision, place, scale, switch, suspend, terminate, and invoice all persist durably through one funnel. The physical infra each action implies is SIMULATED; real tenant provisioning and no-disruption scaling are planned next steps.
- Control plane + _cp_* catalogsA real Qirava DMS running the cloud app; seven _cp_* catalogs hold the whole fleet, created and seeded idempotently.Built
- cloud.* orchestration funnelprovision · scale_vertical · scale_horizontal · switch_mode · suspend · resume · terminate · generate_invoice — each persists and audits.Built
- RBAC-gated Console + audit trailDeny-by-default Console: it renders only reachable screens and each action re-checks ctx.role; every mutation writes a _cp_audit row.Built
- First-fit bin-packing placementDeterministic placement over _cp_nodes by cap headroom, with allocation deltas recorded on the chosen node.Built
- Infra effects are simulatedSpawning the tenant DMS, applying cgroup/OS caps, live-scaling, and taking payment are simulated against the data model and clearly badged.Partial
- Real tenant provisioning + scalingBooting actual tenant DMSes, applying caps, live vertical/horizontal scaling without service disruption, real billing, and confidential compute replace simulated effects.Planned
Run the fleet from the docs
Qirava Cloud is documented in the open repo — the control catalogs, the cloud.* funnel, the placement model, and the real-vs-simulated seam. Read how the managed layer works and where it is honest about what is not yet real.