Dónde viven los datos

Base de datos: Postgres en Supabase, alojado en AWS us-east-1 (Norte de Virginia). Una sola región; sin replicación entre regiones.
Almacenamiento (fotos, logos, firmas): Supabase Storage, misma región AWS. Cifrado en reposo con AES-256.
Sitio de marketing: compilación estática Astro en la red edge de Vercel (CDN global). Solo HTML público — sin datos de cliente.
SPA: bundle estático construido con Vite en Vercel. El bundle envía una clave anon de API (PÚBLICA por diseño); RLS es lo que controla el acceso.
Edge functions: Deno en Supabase Functions, misma región que la BD. Sin llamadas frías entre regiones.

Cómo se aíslan los tenants

Cada tabla del schema público tiene una columna tenant_id y una política Row-Level Security (RLS) de Postgres que limita cada lectura y escritura al tenant_id del invocador únicamente. La verificación es a nivel de base de datos, no a nivel de UI — incluso si un bug en la SPA intentara obtener una fila de otro tenant, Postgres la rechaza.

Tres guards de CI bloquean toda la clase de bugs "lista hardcodeada que se desvía" que destruyen SaaS multi-tenant:

verify-jwt — cada edge function verifica el JWT del invocador
rls-tenant-clamp — cada política RLS debe limitar por tenant_id
tenant-id-trigger-coverage — cada tabla con scope de tenant tiene un trigger BEFORE-INSERT que auto-rellena tenant_id desde el JWT

Estos corren en cada push. Un PR no puede mergear si algún guard falla.

Quién puede ver sus datos

Usted y sus usuarios invitados (administrador, técnico, cliente) — a través de sus respectivos portales limitados. RLS exige los límites.
Andres (fundador de TradelyHQ) — tiene acceso de admin del proyecto Supabase, lo que significa acceso root a la BD. Usado solo para casos de soporte donde usted explícitamente pidió ayuda y dio consentimiento. La auditoría registra cada query de admin contra su tenant.
Personal de Supabase — Supabase tiene el acceso operacional requerido para correr su plataforma (respaldos de BD, acceso a infraestructura). Tienen su propio programa SOC 2; vea la página de seguridad de Supabase.

Nadie más. Sin terceros, sin proveedores de analítica con acceso a datos crudos, sin redes publicitarias, sin entrenamiento de IA. Resend tiene acceso al FROM/TO/SUBJECT/BODY de los correos que enviamos a través de ellos (son nuestro transporte de correo). QBO tiene acceso a los datos de factura que usted le envía (usted es dueño de la conexión QBO).

Cifrado

En tránsito: TLS 1.3 en todas partes. La SPA, edge functions y conexiones a la BD son solo HTTPS. CSP prohíbe contenido mixto.
En reposo: AES-256 en los volúmenes AWS subyacentes (plan Pro de Supabase). Los objetos de Storage tienen una clave de cifrado adicional por objeto.
Columnas sensibles: los tokens OAuth de QBO están cifrados en la capa de aplicación (Supabase Vault) encima del cifrado en reposo.

Respaldos

Supabase corre respaldos lógicos diarios, retenidos según los predeterminados de su plan
Andres mantiene un procedimiento de respaldo de contenido completo separado (vea scripts/full-backup-via-api.mjs en el repo) que corre ad-hoc
La recuperación punto-en-tiempo (PITR) es activable con casilla; actualmente desactivada en este proyecto pero está en la lista pendiente pre-tenant-2

Postura de cumplimiento

TradelyHQ no está actualmente certificado SOC 2 / HIPAA / PCI. Confiamos en el SOC 2 subyacente de Supabase. Si su industria requiere que atestiguemos cumplimiento directamente, pregunte antes de firmar — podemos hablar de qué es posible en su línea de tiempo y nivel de precio.

Sub-procesadores

Tres sub-procesadores críticos en producción:

Supabase — BD, autenticación, almacenamiento, edge functions
Vercel — alojamiento del sitio estático y SPA
Resend — entrega de correo transaccional
Crisp IM SARL (Francia) — chat de soporte en la app (correo, nombre y contenido de chat para usuarios que inician una conversación)
Opcional: Intuit (QBO) — solo si lo conecta; usted controla la conexión

¿Dónde se almacenan mis datos y quién puede verlos?