What stet Cloud holds, who processes it, and how you leave. These pages are generated from the same inventory the infrastructure runs on — an omission there would be an omission here, so the table is kept complete.
Change notification before any addition takes effect.
| Holds contact data | Purpose |
|---|---|
| Supabase (Postgres) | Content, contacts, consent, suppression, audit — the store |
| AWS SES | Broadcast delivery — only for customers who activate Managed sending |
| Inbound-mail provider | Reply capture on mail.your-domain — vendor named before launch |
| Inngest | Form-intake events only (address in transit, short retention); all other jobs carry IDs |
| Never sees contacts | Purpose |
|---|---|
| Cloudflare | Edge worker, bundles, queues, media, hostnames, bot defense |
| Railway | The dashboard app |
| WorkOS | Sign-in and organisations — roles live in stet's schema |
| Stripe | Billing (card data never touches stet) |
| Resend | stet's own account email |
| Sentry · PostHog | Errors and analytics — events carry IDs, never addresses |
| KMS provider | Key custody for encrypted secrets |
| GitHub | The mirror commit, via a repo-scoped App |
Your repo always holds a complete, buildable copy of every string — the mirror commit is on by default, so stet eject is a formality, not a migration.
Contacts never enter the git mirror. They live in a database — yours when self-hosted; exportable as CSV/JSON from Cloud at any time, and stet upgrade migrates the list into your own Postgres.
Deletion is self-serve. A deletion request removes the contact and cascades its send history; the only survivor is a hashed suppression tombstone — kept so the person stays unsubscribed — and backups age out within 24 hours.