Skip to main content
The detection engine is the same binary in both places. Self-hosting does not give you a cut-down firewall — the /guard engine, policy enforcement, dashboard, audit trail, and RBAC all run locally with no outbound connectivity. What differs is the managed surface around it: metering, hosted inference, the control plane, and a small amount of proprietary tooling that is stripped from customer images. This page is the honest line-by-line.

​
Capability matrix

Legend: ✅ available · ⚙️ available but you operate/supply it · ❌ not available · — not applicable

​
Why the cloud-only items are cloud-only

The offensive red-team engine is proprietary attack tooling that is stripped from non-cloud images at build time (DEPLOYMENT_MODE ≠ cloud). It is internal IP we do not ship inside customer environments. The defensive detectors it exercises are fully present in self-host; only the built-in “attack yourself” harness is cloud-only. You can still run your own adversarial spot-checks against your live config by POSTing known-attack payloads to /guard in CI.
On Cloud we operate the classifier and LLM-judge inference for you. Self-hosted, there is no bundled local transformer yet — so ML is bring-your-own: set DETECTION_ML_BASE_URL (and the LLM-guard / PII-redactor equivalents) to a model server you run inside your network, or run with ML_INFERENCE_MODE=off for the (substantial) rule engine alone. This is a deliberate deployment choice, not a capability gap: the detector code is identical, it just calls your endpoint so no traffic leaves your network.
Cloud enforces per-plan monthly request quotas through Stripe-backed subscriptions. A self-hosted instance has no reason to phone a billing provider, so it runs on a signed, node-locked annual license and is metered-but-uncapped: the counter increments for your own visibility, but requests are never hard-capped. No license behaves like the Free tier (10k requests/month); a lapsed/invalid license fails closed on billable requests (503 LICENSE_INACTIVE) while /health and /docs stay up.
Staged rollout, kill-switch, and auto-update for the Shadow AI desktop agents are control-plane features: they need the hosted release/telemetry backend to target cohorts and halt a bad release. An air-gapped fleet distributes agent updates through your own MDM instead.

​
Two things that behave differently self-hosted

RLS is enforced in the app, not Postgres. On a vanilla self-hosted Postgres, the Supabase-managed ROW LEVEL SECURITY statements are skipped. Access control (org/project RBAC, IP allowlists) is enforced at the application layer instead — which is why you must not expose the database directly to untrusted clients. On managed Cloud (Supabase), RLS is additionally active as defense-in-depth.
Pin a stable node identity. Self-host licenses are node-locked. Containerized deployments must set a stable PROMPTGUARD_NODE_ID (e.g. uuidgen once, then reuse) — the default hardware fingerprint changes on each container redeploy and would invalidate a node-locked license.

​
Choosing a model

Air-gapped and self-hosted deployments are an Enterprise-tier capability. See the Compliance page for the zero-egress audit path, or contact sales to scope a deployment.

​
Next steps

Enterprise Setup

Organizations, SSO, RBAC, and audit logs

Compliance

Zero-egress audit, build provenance, and certification status

Shadow AI Deployment Modes

Personal, fleet, and air-gapped agent deployment

Reliability

Fail-open vs fail-closed behavior