Knowledge base · Security & data

Security overview

How credentials and backups are protected: envelope encryption, sealed secrets, audited access, tenant isolation, and what we do not do.

VaultKeep holds keys to production databases, and the product is organised around that fact. This page is the practitioner's summary; the Privacy Policy covers the legal side.

Credentials

• Connection strings, Storage keys and destination credentials are sealed with AES-256-GCM the moment they arrive at the API, using a master key (KEK) held as a Worker secret. The browser never sees them again, and they are never written to logs.
• Only the isolated job runner opens them, at job time, through an authenticated internal endpoint. Every read writes an audit entry with the runner, the job and the purpose.
• Restore-target credentials are single-use and destroyed when the restore ends.
• Rotating credentials destroys the old ciphertext immediately.

Backups

• pg_dump output is streamed through AES-256-GCM straight into storage; plaintext never touches a disk during backup.
• Each backup gets its own data key (DEK), which is wrapped by the master key. Storage objects are encrypted individually with per-run keys.
• SHA-256 hashes of both ciphertext and plaintext are recorded and checked on every verification and restore.
• Artifacts live in Cloudflare R2, a different provider and control plane from Supabase, or in a bucket you own.
• Retention is crypto-shredding: the wrapped key is destroyed with the objects.

Isolation

• Every query is scoped to your organization after a role check; the test suite probes cross-tenant access with real users on every change.
• The job runner (pg_dump, throwaway Postgres clusters, restores) runs in a container separate from the web application, and only reaches the control plane through a token-authenticated internal API.
• Restores refuse a non-empty target and require typed confirmation.

Audit log

Append-only, enforced by database triggers, covering sign-ins, credential reads, backups, verifications, restores, plan changes, team changes and destination changes. Exportable as CSV from the app. Retained for 90 days after an organization is deleted.

Platform

VaultKeep runs entirely on Cloudflare (Workers, D1, R2, Containers, Queues, Cron Triggers), with Stripe for payments and Resend or Cloudflare for email. Sessions use one strictly necessary cookie. Optional Turnstile protects sign-in from bots.

What we do not do (yet)

• No HIPAA Business Associate Agreements; PHI is prohibited by the Terms.
• No SOC 2 report of our own yet. The controls above are designed to produce the evidence you need for yours.
• No point-in-time recovery; use Supabase's PITR alongside VaultKeep if you need it.

Reporting a vulnerability

Email support@vaultkeep.dev with "Security" in the subject. We acknowledge reports promptly, fix confirmed issues, and credit you if you wish. Please don't test against other customers' data.

Still stuck? Email support@vaultkeep.dev with your project name (never your connection string) and we'll take a look.