Deployment

Any model. Any hosting mode. One control plane.

Qua Cloud — live todayYour VPC — roadmapOn-prem — roadmap

Qua Cloud is live today. Your VPC and on-prem/air-gapped are roadmap — not built, no date, no waitlist. The commitment is that governance, receipts and the audit ledgers behave the same wherever Qua runs; today they run, and can be checked, in the one mode that exists. This page keeps those two things apart on purpose.

See governance live →What ships today
Three deployment modes

Pick where the stack runs. The governance doesn’t change.

Same policy engine, evaluated before routing. Same receipt on every answer. Same two audit ledgers. What changes is where the control plane sits — and today only one of these three exists.

SaaS · Live today

Qua-hosted cloud

The control plane runs on a Cloudflare Worker that Qua operates; your rows live in Postgres with row-level security on every table. This is what you get when you sign in.

  • Data residencyQua-operated Postgres. Row-level security on every table, with cross-org isolation enforced in the database — a verified invariant, not an application-layer check.
  • Model accessGoogle, OpenAI, Groq, DeepSeek and Qwen. Per-provider blocks, per-task-class max-tier clamps and masking rules are all applied before routing.
  • ControlThree independent authorization axes — org/department, platform, session. Permissions-as-data with a CI drift check. Two audit ledgers, with actor and reason mandatory on platform actions.
Available now · email + password or Google sign-in · owner-only Pro Models escalation approvals.
Single-tenant · Roadmap

Your VPC

Not available today. Described here so the shape of the plan is legible, not because you can run it.

  • Data residencyPlanned: the control plane and Postgres run inside your own AWS, Azure or GCP account, so the data plane never leaves your boundary.
  • Model accessPlanned: the same catalog, called through your egress. Per-provider blocks and max-tier clamps behave exactly as they do on Qua Cloud.
  • ControlPlanned: the same three authorization axes and the same two audit ledgers, running in your account rather than Qua’s.
Roadmap · no preview, no waitlist, no availability date.
Sovereign · Roadmap

On-prem / air-gapped

Not available today. The hardest mode to build, and the one it would be least honest to imply is close.

  • Data residencyPlanned: the whole stack inside your perimeter — prompts, receipts and both audit ledgers included.
  • Model accessPlanned: no external provider calls at all. Work resolves at Personal Knowledge and Enterprise Search, which already resolve with no external model call today.
  • ControlPlanned: the same policy engine and the same audit ledgers, hosted and operated by you.
Roadmap · no preview, no waitlist, no availability date.
The claims ledger

Exactly what ships today. Exactly what doesn’t.

Deployment pages are where vendors quietly promise things they have not built. So here is the whole list, split in two. Every line on the left names a mechanism that exists in the product now. Every line on the right is planned work — do not plan around it.

Available today

Shipped · in the product now

Row-level security on every table, with cross-org isolation enforced in the database — a verified invariant.rls
Three independent authorization axes: org/department, platform, and session.authz
Permissions-as-data, with a CI drift check.ci
Two audit ledgers. Actor and reason are mandatory on platform actions.audit
Platform operators cannot read customer session content — single audited moderation-excerpt exception.access
Org suspension, plus database-level guards behind it.orgs
RBAC regression proofs committed in the repo (docs/rbac_proofs/).proofs
Email + password and Google sign-in.auth
Per-provider blocks.policy
Per-task-class max-tier clamps.policy
Masking rules applied before routing.masks
Owner-only Pro Models escalation approvals.approvals
Personal Knowledge and Enterprise Search resolve with no external model call.waterfall
Claims stated as fact on this page13

On the roadmap

Not built · no dates

Your VPC — the control plane and data plane inside your own cloud account.vpc
On-prem and air-gapped deployment.on-prem
SSO, SAML and SCIM.sso
Bring your own model, or bring your own provider keys.byo
Per-model approvals. Today the control is per-provider blocks plus a max-tier clamp — not per model.models
Data-residency selection.residency
Compliance certifications. Qua is not yet certified.certs
Planned, not shipped7

The left column is checkable rather than reassuring: the row-level security policies, the two audit tables, and the RBAC regression proofs committed under docs/rbac_proofs/ are all artifacts you can open. No third party has audited any of it — Qua holds no compliance certifications and is not yet certified. If a certificate is what you need this quarter, this page is not going to hand you one.

Model flexibility

The catalog stays open. The controls are not suggestions.

Qua routes across Google, OpenAI, Groq, DeepSeek and Qwen. Which of those your org may reach, how far up the tiers a task class may climb, and what gets redacted on the way out are org policy — stored as data, and evaluated before the router ever sees the prompt.

org policy · waterfall_policy
Evaluated before routing, not after
Live control

Providers provider_mask

Googlegateway provider — shares one block with OpenAIAllowed
OpenAIgateway provider — shares one block with GoogleAllowed
Groqown provider entryAllowed
DeepSeekown provider entryBlocked
Qwenown provider entryBlocked

Max-tier clamps rules[]

document_reviewclient-confidential class04 Enterprise Search
researchregulated content04 Enterprise Search
*everything else01 Pro Models

Masks masks[]

[\w.+-]+@[\w-]+\.[\w.-]+applied before the prompt leaves the perimeter[EMAIL]
\d{3}-\d{2}-\d{4}applied before the prompt leaves the perimeter[SSN]

These are the real product controls, re-drawn — not an illustration of a feature. Blocks are stored per provider in the org’s waterfall policy: Google and OpenAI reach Qua through a single gateway provider today, so one block covers both. Per-model approvals are roadmap; today the controls are per-provider blocks plus a max-tier clamp, and masks are applied before routing rather than after.

Architecture

One control plane. Three perimeters.

The boxes do not move between modes. The line drawn around them does. Two of these three diagrams describe work that has not been built, and they say so on their face.

Qua Cloud

Live today
Qua Cloud architecture — live todayThe browser talks over HTTPS to Qua's control plane, a Cloudflare Worker that Qua operates. The control plane applies org policy, max-tier clamps and masking rules before routing, resolves Personal Knowledge and Enterprise Search without any external model call, and writes a receipt for every answer to a Postgres database where row-level security on every table enforces cross-org isolation and two audit ledgers record activity. Only the three AI Model tiers send a masked prompt out to an external model provider: Google, OpenAI, Groq, DeepSeek or Qwen. Qua platform operators have no read path to customer session content; the single exception is an audited moderation excerpt, and every view of it is logged.Live todayQua Cloud — operated by QuaBrowseryour team’s sessionHTTPSQua control planeCloudflare Worker→ policy, clamps and masks first→ zero-cost tiers resolve here→ receipt written per answerevery write auditedPostgresrow-level security on every table→ cross-org isolation, enforced in the DB→ two audit ledgersExternal providersGoogleOpenAIGroqDeepSeekQwenmasked promptAI Model tiers onlyQua operatorsno read path to yoursessions — one auditedmoderation excerpt,every view logged
Qua operates the control plane and the database. Row-level security in Postgres is what keeps one org’s rows unreadable to another, and both audit ledgers are written on the same path. The amber line is the one most vendor diagrams omit: platform operators cannot read customer session content — single audited moderation-excerpt exception.

Your VPC

Roadmap
Your VPC architecture — planned, not available todayPlanned architecture, on the roadmap and not available today. The same control plane and the same Postgres database would run inside your own cloud account, so the data plane never leaves your boundary, and external model calls would leave through your own egress. Nothing in this diagram ships today.PLANNED ARCHITECTUREPlanned architectureYour VPC — your cloud account (planned)Browseryour team’s sessionHTTPSQua control planeCloudflare Worker→ policy, clamps and masks first→ zero-cost tiers resolve here→ receipt written per answerevery write auditedPostgresrow-level security on every table→ cross-org isolation, enforced in the DB→ two audit ledgersExternal providersGoogleOpenAIGroqDeepSeekQwenmasked promptAI Model tiers only
Planned architecture. Nothing in this drawing exists yet — no preview, no waitlist, no date. It is here so the shape of the commitment is legible: the control plane and the database inside your account, external model calls leaving through your own egress.

On-prem / air-gapped

Roadmap
On-prem and air-gapped architecture — planned, not available todayPlanned architecture, on the roadmap and not available today. The browser, the control plane and the database would all sit inside your own perimeter, with no external model calls at all, so work would have to resolve at Personal Knowledge and Enterprise Search — which already resolve with no external model call today. Nothing in this diagram ships today.PLANNED ARCHITECTUREPlanned architectureYour data centre — no egress (planned)Browseryour team’s sessionHTTPSQua control planeCloudflare Worker→ policy, clamps and masks first→ zero-cost tiers resolve here→ receipt written per answerevery write auditedPostgresrow-level security on every table→ cross-org isolation, enforced in the DB→ two audit ledgersExternal providersGoogleOpenAIGroqDeepSeekQwenno externalmodel calls
Planned architecture, and also unbuilt. The point of the picture is the arrow that is missing: with no external model calls, work has to resolve inside the perimeter — which is exactly what Personal Knowledge and Enterprise Search already do today.
05 Personal Knowledge04 Enterprise Search03 Open Models02 Fast Models01 Pro Models

Personal Knowledge and Enterprise Search resolve with no external model call — today, in the mode that exists. That is what makes the deployment question smaller than it looks: most work never reaches the boundary, whichever boundary you eventually draw. It is also the routing behaviour behind Qua’s documented 5× spend reduction versus uncontrolled use.

Keep the receipts — from day one.

Governance, isolation and the audit ledgers are live now, in Qua Cloud. The deployment modes are what expands from here — and this page will keep saying, plainly, which is which.

Open the app →Try the demo