Security
Deltex is multi-tenant by design. Every request is authenticated, every tenant is isolated inside the Wasm sandbox, and there is no long-running server process to compromise.
Authentication
Two ways to authenticate, both backed by the same control plane:
- API keys — 128-bit cryptographically-random tokens (
dtx_k_...). Only a SHA-256 hash is stored; verification is constant-time and fail-closed. - Email login (OTP) — the console signs you in with a 6-digit code sent to your inbox. Codes are CSPRNG-generated, stored only as a SHA-256 hash, single-use, expire in 10 minutes, lock out after 3 wrong attempts, and are rate-limited to 5 per hour.
Sessions issued to the console are 256-bit random tokens with a 24-hour TTL, so your raw API key never lives in browser storage.
Row-level security
Define per-row access policies that the engine enforces at query time:
CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_tenant()); ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
Tenant isolation
Each database is keyed by an opaque db_id and every KV access is scoped to it. Cross-tenant reads, edge-mode writes, DDL, and db_id injection are all blocked at the engine boundary. The storage worker enforces privilege separation — engine keys cannot reach storage-admin routes.
Wasm sandbox
The engine runs inside the edge runtime's WebAssembly sandbox: no filesystem, no raw sockets, no process spawning. A compromised query cannot escape the module or reach another tenant's memory — the sandbox is the security boundary, and it is the same one the CDN trusts to run untrusted code.
Transport & headers
All endpoints are HTTPS-only with HSTS. Responses set X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and a strict Content-Security-Policy. Control-plane CORS is restricted to the official console origins.
Sub-processors
Deltex relies on the edge compute platform (Fastly) for hosting, Resend for transactional email, and Stripe for billing. No customer query data is shared with any third party.