Where is my data stored, and who can see it?

Where the data lives

• Database: Postgres on Supabase, hosted in AWS us-east-1 (Northern Virginia). Single region; no cross-region replication.
• Storage (photos, logos, signatures): Supabase Storage, same AWS region. Encrypted at rest with AES-256.
• Marketing site: Astro static build on Vercel's edge network (global CDN). Public HTML only — no customer data.
• SPA: Vite-built static bundle on Vercel. The bundle ships an anon API key (PUBLIC by design); RLS is what gates access.
• Edge functions: Deno on Supabase Functions, same region as the DB. No cold-start cross-region calls.

How tenants are isolated

Every public-schema table has a tenant_id column and a Postgres Row-Level Security (RLS) policy that scopes every read and write to the caller's tenant_id only. The check is at the database level, not the UI level — even if a bug in the SPA tried to fetch another tenant's row, Postgres rejects it.

Three CI guards block the entire class of "drifted hardcoded list" bugs that destroy multi-tenant SaaS:

• verify-jwt — every edge function verifies the caller's JWT
• rls-tenant-clamp — every RLS policy must clamp on tenant_id
• tenant-id-trigger-coverage — every tenant-scoped table has a BEFORE-INSERT trigger that auto-fills tenant_id from the JWT

These run on every push. A PR can't merge if any guard fails.

Who can see your data

1. You and your invited users (admin, tech, client) — through their respective scoped portals. RLS enforces the boundaries.
2. Andres (TradelyHQ founder) — has Supabase project admin access, which means root DB access. Used only for support cases where you've explicitly asked for help and given consent. Audit log records every admin query against your tenant.
3. Supabase staff — Supabase has the operational access required to run their platform (DB backups, infrastructure access). They have their own SOC 2 program; see Supabase's security page.

Nobody else. No third parties, no analytics vendors with raw data access, no ad networks, no AI training. Resend has access to the FROM/TO/SUBJECT/BODY of emails we send through them (they're our email transport). QBO has access to the invoice data you push to them (you own the QBO connection).

Encryption

• In transit: TLS 1.3 everywhere. The SPA, edge functions, DB connections are HTTPS-only. CSP forbids mixed content.
• At rest: AES-256 on the underlying AWS volumes (Supabase Pro plan). Storage objects have an additional per-object encryption key.
• Sensitive columns: QBO OAuth tokens are encrypted at the application layer (Supabase Vault) on top of the at-rest encryption.

Backups

• Supabase runs daily logical backups, retained per their plan defaults
• Andres maintains a separate full-content backup procedure (see scripts/full-backup-via-api.mjs in the repo) that runs ad-hoc
• Point-in-time recovery (PITR) is checkbox-toggleable; currently disabled on this project but on the pre-tenant-2 todo list

Compliance posture

TradelyHQ is not currently SOC 2 / HIPAA / PCI certified. We rely on Supabase's underlying SOC 2. If your industry requires us to attest to compliance directly, ask before signing — we can talk about what's possible on your timeline + price tier.

Subprocessors

Three production-critical subprocessors:

• Supabase — DB, auth, storage, edge functions
• Vercel — static site + SPA hosting
• Resend — transactional email delivery
• Crisp IM SARL (France) — in-app support chat (email, name, and chat content for users who initiate a conversation)
• Optional: Intuit (QBO) — only if you connect it; you control the connection