Infrastructure · Data Protection
Plain-English tour of the backup & security system across all 14 SaaS apps and Boom Online Ordering: what's protected, where it lives, what it costs, and how we roll a single client back to a point in time — whether they're a restaurant on BOO or a service business on the SaaS suite. Status badges below mark what's live today vs. in progress vs. planned — this is the honest picture, gaps included.
Everything Boom stores is sorted into three tiers by how much it would hurt to lose it. The higher the tier, the tighter the backup. Two numbers drive every decision:
"How much data can we afford to lose?"
The age of the newest backup you can fall back to. An RPO of 1 hour means a failure could cost up to the last hour of changes. Money data targets an RPO of seconds.
"How fast can we be back up?"
How long a restore takes. A tenant row-level restore is minutes; a full-cluster rebuild is longer. Lower RTO costs more (hot standby vs. cold backup).
Not all data is equal. A lost blog draft is an annoyance; a lost restaurant payment is a crisis. Each tier gets protection matched to its stakes.
Boom Online Ordering transactions, payouts, Stripe records, and login credentials/secrets. Losing or corrupting this = lost revenue and trust.
Plan: isolate BOO's transaction DB from the shared Postgres, add point-in-time recovery (PITR), an append-only order ledger, idempotency keys, and nightly Stripe reconciliation.
Every SaaS tenant's records — customers, reviews, loyalty points, documents, menus — plus client-uploaded files (images, PDFs, videos).
Method: hourly logical dump of the shared Supabase Postgres (all tenants) shipped off-site to Backblaze B2. User uploads still need to be included (see gaps).
Application source code and delivered media. If lost, it can be regenerated or re-deployed — no unique customer state at risk.
Method: code is versioned in GitHub; media is served from Bunny CDN. Bunny is delivery, not backup — master media files also copy to B2.
Every app writes to the shared Supabase Postgres (so one hourly dump covers them all), except BOO's money data, which is being moved onto its own isolated, PITR-protected database.
| Product | Sensitive data it holds | Tier | Backup path |
|---|---|---|---|
| 🍽️ Boom Online Ordering | Orders, payments, payouts, customer PII | 1 | Isolated DB + PITR → B2 Planned |
| 📍 Localey | Reviews, citations, customer contacts | 2 | Hourly dump → B2 |
| 🎁 Rewardee | Loyalty points, gift-card balances | 2 | Hourly dump → B2 |
| 🖊️ Signnee | Signed documents, signer identity | 2 | Hourly dump + file store → B2 |
| 💬 Replyee | Chat transcripts, captured leads | 2 | Hourly dump → B2 |
| ✓ Approvee | Client projects, feedback, approvals | 2 | Hourly dump → B2 |
| 📊 Dashee | Client dashboards, connected metrics | 2 | Hourly dump → B2 |
| 🖥️ Displayee | Playlists, screen config, hosted video | 2 | Hourly dump + Bunny masters → B2 |
| 🛡️ Compliee | Scan history, site issue reports | 2/3 | Hourly dump (re-scannable) |
| 📈 Rankee | Rank history, audits, keywords | 2/3 | Hourly dump (re-crawlable) |
| 📣 Addee · ✍️ Bloggy · 📅 Posttee | Generated creative, drafts, schedules | 3 | Hourly dump; AI-regenerable |
| 🔳 QRcodee | QR targets, scan analytics | 3 | Hourly dump → B2 |
| 🛟 Assistee | Session logs (self-hosted RustDesk) | 3 | Droplet + config backup |
The key capability: roll a single client back to how their data looked at a chosen moment, without disturbing any other tenant. It works in two layers — when (point in time) and who (that one tenant's rows).
Every tenant-scoped table carries a restaurant_id / client_id and is isolated by Supabase Row-Level Security — so we can lift just that client's rows out of a restored copy and merge them back into live, leaving everyone else untouched.
restaurant_id — menu, orders, customers.client_id across the affected tables.Deliberately boring, off-the-shelf pieces — each does one job, and backups land in a provider separate from where the data runs, so a compromise or fat-finger in one place can't reach the copies.
boom-media-backups). Cheap, immutable object storage — the copies live here, away from the app servers..env files; break-glass export mirrors secrets to B2.Data protection rides mostly on infrastructure already running. The incremental backup/security spend is small relative to what it protects.
| Piece | What it's for | Est. monthly |
|---|---|---|
| Core infrastructure | Droplets, Supabase, app hosting (Vercel/Coolify) — the whole ecosystem | $150–260 |
| Backblaze B2 | Off-site backup storage (~$6/TB/mo) + minimal egress | $5–15 |
| Doppler | Secrets management (free tier viable early) | $0–20 |
| BOO managed Postgres + PITR | Isolated transaction DB w/ point-in-time recovery (Tier 1) | $15–60 |
| GitHub / Bunny | Code hosting + media delivery (existing) | included |
| All-in, fully hardened | Everything above once Tier-1 PITR is live | ~$175–355/mo |
Note: the incremental cost of the backup/DR layer specifically (B2 + Doppler + BOO PITR) is roughly $20–95/mo on top of infrastructure you already run.
Where the plan is designed but not yet fully in place. These are the things to close next.
The step-by-step when a client needs a rollback. Keep this handy; run it against a scratch database, never live.
client_id/restaurant_id), which tables, and the exact "good" timestamp before the problem.