Subprocessors
Last updated 25 July 2026
The third parties involved in running Vault, what each one receives, and what it cannot see. None of them can read your vault. We will update this page before adding or replacing a subprocessor; see the DPA for notice and objection rights.
Google LLC — Google Drive API
Purpose: Storage of your encrypted vault in your own Drive appDataFolder, if you enable sync
Receives: Your encrypted vault file, in your own Google account; connection metadata
Cannot see: Vault contents, master password, keys
Supabase Inc. — Realtime
Purpose: The revision-changed ping that tells your other devices to fetch
Receives: A revision indicator on a user-scoped topic; connection metadata
Cannot see: Vault contents, entry data, keys — none of it is ever sent
Supabase Inc. — Auth and sharing directory
Purpose: Public-key lookup, only if you use cross-user sharing
Receives: Sign-in email, user id, your public key
Cannot see: Private keys, vault contents
Merchant of record (Paddle)
Purpose: Selling, invoicing, payment and tax on subscriptions
Receives: Your payment details and billing information, under their own policy
Cannot see: Vault contents, master password, keys
Platform app stores (Apple, Google, Microsoft, Chrome Web Store)
Purpose: Distribution and, where you buy there, billing
Receives: Whatever the store collects for downloads and purchases under its own policy
Cannot see: Anything from inside your vault
Static web host
Purpose: Serving this website
Receives: Standard server logs: IP address, timestamp, requested path, user agent
Cannot see: Anything about your vault — the site has no account system and sets no cookies
The one that is missing
There is no Vault vault server on this list, because there is no Vault vault server. Your encrypted vault moves between your device and your own Google Drive. Nothing we operate ever holds it.
Questions
Email founder@dfacto.ai for hosting regions, transfer mechanisms, or a counter-signed DPA.