Multi-org & MSSP¶
Run Vex Raptor for many isolated clients from one deployment — the model for MSSPs and for enterprises with independent business units.
The org boundary¶
Every resource — scans, findings, reports, API keys, users, quotas — belongs to
an organization (org_id). Isolation is enforced server-side on every
request: a caller can only see resources in their own org, and resources in
another org return 404 (not 403), so existence is never leaked across
tenants.
Isolation is a hard boundary
Cross-org access is not a UI convenience toggle — it is enforced in the data layer. Verify it in your own acceptance tests before onboarding clients.
Provisioning clients¶
- Create an org per client.
- Assign an admin (or connect the client's IdP via SSO).
- Set the client's plan and daily scan quota.
- Issue a scoped API key for the client's CI, if needed.
White-label reports¶
Rebrand deliverables per client — name, logo, and colors — so reports go out under your MSSP brand, not Vex's. Configure branding per org; every export (HTML/PDF/JSON) inherits it.
Quotas & plans per org¶
Each org carries its own plan and daily scan quota, enforced atomically
(429 when exceeded). This lets you meter and bill per client and prevents one
client's activity from starving another.
| Lever | Scope | Use |
|---|---|---|
| Plan | Per org | Feature gating (SSO, white-label, internal scans) |
| Daily scan quota | Per org | Capacity metering / billing |
| API keys | Per org | Client automation |
Operating at scale¶
- Put shared state (quota, scan status) in Redis so all workers agree — see Production.
- Monitor per-org usage and export it for billing via the API.
- Keep the audit log per org for client-facing evidence.