❯ cat /etc/security
Architecture you can audit
Engineers pick tools they can reason about. Here's where your data actually lives — and where it doesn't.
❯ verified
The four things that matter most
Zero-knowledge cloud Vault
Connection secrets are encrypted client-side with PBKDF2-derived keys before they leave your machine. We literally cannot read them.
OS keychain, not localStorage
Desktop credentials live in the platform keychain via Electron safeStorage — macOS Keychain / Windows DPAPI / libsecret on Linux.
Your MongoDB data is never stored on our servers
Desktop talks straight to MongoDB. The web client forwards each operation through a stateless Spanna proxy to your database — the proxy holds no documents at rest.
Native crash dumps stay on your machine
The Electron crashReporter writes minidumps locally and never auto-uploads. JS-level crash diagnostics (stack traces, no document data) upload only if you opt into crash telemetry on first run.
❯ ls /spanna-storage
What we store. What we don't.
stored
- Account information needed for auth and subscription state
- Workspace metadata (connection names, folder + tag organisation, settings)
- Encrypted credential blobs when vault-backed sync is enabled
- Operational metadata: billing state, telemetry events (opt-in), audit log
never stored
- Plaintext MongoDB credentials — only encrypted blobs reach our servers
- Documents from your collections at rest — desktop never sends them anywhere; the web proxy forwards them in flight without persisting
- Query content beyond opt-in telemetry events you've consented to
- Cross-customer data — every workspace is scoped to its owning account by row-level security policies
❯ traceroute spanna
Where the traffic actually flows
| Surface | How it works |
|---|---|
| Desktop | Direct connection to your MongoDB. No traffic through Spanna. |
| Web client | client.spanna.app → Spanna proxy → your MongoDB. The proxy is connection-pooling only; no data at rest. |
| Auth | Supabase Auth. Email + password, OAuth providers, session cookies. |
| Billing | Paddle (merchant of record). Card data never touches Spanna servers. |
| MongoDB auth methods | Username/Password, OIDC, x.509, Kerberos, AWS IAM, SRV strings. |
❯ man honest
What we don't claim
Most security pages list every win. Here's the converse — the limits we know about, so you don't discover them later.
- We do not currently hold a SOC 2, ISO 27001, or HIPAA attestation. Several are on the GA roadmap.
- The browser client necessarily uses Spanna's service layer to reach MongoDB — it is not zero-infrastructure.
- On Linux without a keychain service, safeStorage falls back to base64 plaintext (with a clear `plain:` marker). Headless installs should provision GNOME Keyring or KWallet.
- Supabase auth tokens live in a JS-readable cookie scoped to .spanna.app (and mirrored to localStorage) — same posture as the Supabase default. HttpOnly hardening is tracked as a future pass.
❯ man hygiene
For your side of the wire
- Prefer least-privilege MongoDB users for application access
- Use TLS, x.509, OIDC, Kerberos, or AWS IAM where appropriate for your deployment
- Reset the cloud Vault and re-save credentials if your synced state becomes inconsistent
- Keep desktop builds current to receive security patches and auth/sync improvements
❯ report --vuln
Found something?
Email hello@spanna.app with reproduction steps, the affected surface, and any proof of concept. We respond within two business days.
Please hold public disclosure until we've had a reasonable chance to investigate and remediate. We coordinate disclosure timelines case by case.