Deployment

One control plane. A clear deployment path.

Qua Cloud — live todayYour VPC — ready for deploymentAir-gapped — ready for deployment

All three modes are available. Qua Cloud you can sign into right now; your own cloud account and a fully air-gapped install are provisioned per customer from the same codebase, with the same policy engine, receipts and audit trail. Request one below and you get a tracked plan with a named region and timeline — not a waitlist.

Request a deployment →What ships today
Three deployment modes

Pick the boundary. The product is the same in all three.

One codebase, three places to run it. The controls, the receipts and both audit ledgers behave identically whichever boundary you choose.

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 · Ready for deployment

Your VPC

The same control plane, provisioned into your own cloud account. Scoped and scheduled per customer — request it below and we return a named region and date.

  • Data residencyThe control plane and Postgres run inside your own AWS, Azure or GCP account, so the data plane never leaves your boundary.
  • Model accessThe same catalog, called through your egress. Per-provider blocks and max-tier clamps behave exactly as they do on Qua Cloud.
  • ControlThe same three authorization axes and the same two audit ledgers, running in your account rather than Qua’s.
Provisioned per customer · request below · region and timeline confirmed in writing.
Sovereign · Ready for deployment

On-prem / air-gapped

The whole stack inside your perimeter, with no external model calls at all. The strictest mode, and the one that needs a scoping conversation before install.

  • Data residencyEverything inside your perimeter — prompts, receipts and both audit ledgers included.
  • Model accessNo external provider calls. Work resolves at Personal Knowledge and Enterprise Search, plus any model you host yourself.
  • ControlThe same policy engine and the same audit ledgers, hosted and operated by you.
Provisioned per customer · request below · install scoped with your security team.
The claims ledger

Exactly what ships today. Exactly what doesn’t.

Deployment pages are where vendors quietly promise things they have not built. Here is the whole list, split in two: every line on the left names a mechanism that exists in the product today, and every line on the right is planned work you should not plan around yet.

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

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
Compliance certifications. Qua is not yet certified.certs
Planned, not shipped4

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

Ready for deployment
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 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
The single-tenant architecture: the control plane and the database inside your account, external model calls leaving through your own egress. Provisioned per customer, with the region and the install window agreed before work starts.

On-prem / air-gapped

Ready for deployment
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 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
The point of the picture is the arrow that is missing: with no external model calls, work resolves 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.

Get it running

Request your deployment.

Qua Cloud, your own cloud account, or fully air-gapped. You get a tracking code straight away and a named engineer within two business days.

Request a deployment

Tell us the boundary you need. You get a tracking code immediately and a scoped plan with a date — nothing here is a waitlist.

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