Onde os dados moram

Banco de dados: Postgres no Supabase, hospedado na AWS us-east-1 (Norte da Virgínia). Região única; sem replicação entre regiões.
Storage (fotos, logos, assinaturas): Supabase Storage, mesma região AWS. Criptografado em repouso com AES-256.
Site de marketing: build estático Astro na rede edge da Vercel (CDN global). Apenas HTML público — sem dados de cliente.
SPA: bundle estático construído com Vite na Vercel. O bundle leva uma chave anon da API (PÚBLICA por design); o RLS é o que controla o acesso.
Edge functions: Deno no Supabase Functions, mesma região do banco. Sem chamadas frias entre regiões.

Como os tenants são isolados

Cada tabela do schema público tem uma coluna tenant_id e uma política Row-Level Security (RLS) do Postgres que escopa cada leitura e escrita ao tenant_id do chamador apenas. A verificação é no nível do banco de dados, não no nível da UI — mesmo que um bug na SPA tentasse buscar uma linha de outro tenant, o Postgres rejeita.

Três guards de CI bloqueiam toda a classe de bugs "lista hardcoded que diverge" que destroem SaaS multi-tenant:

verify-jwt — cada edge function verifica o JWT do chamador
rls-tenant-clamp — cada política RLS deve clampar em tenant_id
tenant-id-trigger-coverage — cada tabela com escopo de tenant tem um trigger BEFORE-INSERT que preenche tenant_id automaticamente do JWT

Eles rodam a cada push. Um PR não pode mergear se algum guard falhar.

Quem pode ver seus dados

Você e seus usuários convidados (admin, técnico, cliente) — pelos respectivos portais escopados. RLS aplica os limites.
Andres (fundador do TradelyHQ) — tem acesso admin do projeto Supabase, ou seja, acesso root ao banco. Usado apenas para casos de suporte onde você explicitamente pediu ajuda e deu consentimento. A trilha de auditoria registra cada query admin contra seu tenant.
Equipe do Supabase — o Supabase tem o acesso operacional necessário para rodar a plataforma deles (backups de banco, acesso à infraestrutura). Eles têm o próprio programa SOC 2; veja a página de segurança do Supabase.

Mais ninguém. Sem terceiros, sem fornecedores de analytics com acesso a dados brutos, sem redes de anúncio, sem treinamento de IA. O Resend tem acesso ao FROM/TO/SUBJECT/BODY dos e-mails que enviamos por ele (é nosso transporte de e-mail). O QBO tem acesso aos dados de fatura que você envia (você é dono da conexão QBO).

Criptografia

Em trânsito: TLS 1.3 em todo lugar. SPA, edge functions, conexões com o banco são HTTPS-only. CSP proíbe conteúdo misto.
Em repouso: AES-256 nos volumes AWS subjacentes (plano Pro do Supabase). Objetos de Storage têm uma chave de criptografia adicional por objeto.
Colunas sensíveis: tokens OAuth do QBO são criptografados na camada de aplicação (Supabase Vault) sobre a criptografia em repouso.

Backups

O Supabase roda backups lógicos diários, retidos conforme os padrões do plano deles
O Andres mantém um procedimento separado de backup de conteúdo completo (veja scripts/full-backup-via-api.mjs no repo) que roda ad-hoc
Recuperação ponto-no-tempo (PITR) é uma checkbox para ligar; atualmente desativada neste projeto mas está na lista de pendências pré-tenant-2

Postura de conformidade

O TradelyHQ não é atualmente certificado em SOC 2 / HIPAA / PCI. Nos apoiamos no SOC 2 subjacente do Supabase. Se seu setor exige que atestemos conformidade diretamente, pergunte antes de assinar — podemos discutir o que é possível no seu cronograma e faixa de preço.

Subprocessadores

Três subprocessadores críticos em produção:

Supabase — banco, auth, storage, edge functions
Vercel — hospedagem do site estático e SPA
Resend — entrega de e-mail transacional
Crisp IM SARL (França) — chat de suporte no app (e-mail, nome e conteúdo do chat para usuários que iniciarem uma conversa)
Opcional: Intuit (QBO) — apenas se você conectar; você controla a conexão

Onde meus dados são armazenados e quem pode vê-los?