Ops Runbook — deploys, versioning, rollback & backups

The operational bible as of 19 Jul 2026. One page to run the whole platform.

The four surfaces

Surface	URL / channel	Current	Deployed with
Marketing + web app + hub	`nutrisynccollective.com` (alias `nutrisync-collective.pages.dev`)	v11.45-po5	Deploy NutriSync Web
Mobile PWA (installable)	`m.nutrisynccollective.com` (Pages project `nutrisync-m`)	app v0.11.0 parity	Build NutriSync PWA
iOS app (React Native)	EAS Update, branch `production`	v0.11.0	Deploy NutriSync App
Android app (React Native)	same OTA channel	v0.11.0	Deploy NutriSync App

All four share the same Supabase (EU) backend under RLS. The PWA is the RN app rendered via react-native-web — parity by construction: re-run its build after any app deploy.

The working folder (single source of hand-off)

~/SKG_AI_Tribe_Projects/NutriSync — Cowork-connected (Engineering reads/writes directly).

Folder	Contents
`inbox/`	Builds ready to deploy. Scripts consume from here and auto-archive.
`releases/`	Every shipped version, kept forever — the rollback points.
`design-packs/`	All Design deliveries (37 historical + current).
`feedback/`	Founder review rounds (docs, screenshots, reference images).
`backend-sql/`	Every SQL migration ever applied (14 files) — DB history.
`tools/`	The three `.command` scripts + PWA kit.
`archive/`	Pre-reorg history: `builds/` (94 old zips) + `misc/`.
`repos/`	Git clones: `appdev`, `webdeploy`, `pwadev`.

Flow: Engineering drops a build in inbox/ → Juanjo runs the Spotlight command → deployed + zip auto-moved to releases/. Downloads is out of the loop.

Versioning

App: semver in app.json (0.11.0), release zips named nutrisync-app-v<semver>-<tag>.zip.
Web: Design pack version + integration counter (v11.45-po5).
PWA: inherits the app semver; deployed dist archived as nutrisync-pwa-dist-v<semver>-<date>.zip.
Nothing in releases/ is ever deleted. Superseded ≠ disposable.

Rollback (per surface)

Web / PWA — two ways: 1. Instant (Cloudflare): dashboard → Workers & Pages → project → Deployments → ⋯ → Rollback to this deployment. Any successfully-built production deployment is a valid target — no numeric limit, full history retained (per Cloudflare docs, Apr 2026). 2. From archive: older zip from releases/ → inbox/ → re-run the deploy command (web), or unzip a pwa-dist archive and npx wrangler pages deploy <dir> --project-name=nutrisync-m.

App (OTA): older nutrisync-app-v*.zip from releases/ → inbox/ → Deploy NutriSync App. Phones revert on the next two app opens. (EAS dashboard also keeps every published update, re-publishable.)

Database: snapshot-first rule stands (doc 11) — snapshot in the Supabase dashboard before any migration; restore from there if a migration misbehaves.

Backups

Working folder → Google Drive, excluding repos/ (git clones + node_modules = sync churn; GitHub is the code's backup). Optional skip: archive/builds/ if space matters.
Code: GitHub (nutrisync-app, nutrisync-web), main protected on both (rulesets: no force-push, no deletion).
Database: Supabase automated backups + manual snapshots before migrations.
Deployments: Cloudflare retains every Pages deployment; EAS retains every update.

Access control (two separate lists)

Builders/Investors areas (/hub/*): Cloudflare Access — email + one-time PIN, 24h sessions. Manage: Zero Trust → Access → Applications → NutriSync Builders Hub → policy Founders. Current allowlist (7): juanjose.cebrian@gmail.com, lcebrian@/pgonzalez@/mgarzon@nutrisynccollective.com, pilargonz05@/cebrianlucia281@/mapigarzon2204@gmail.com. Snapshot page inside the hub: Access tab.
Admin data (KPIs, waitlist, app feedback RPCs): public.admins table in Supabase (SQL editor). Being on list 1 does NOT grant list 2.

www → apex 301 redirect; pages.dev hub URLs bounce to the custom domain (canonical script), so Access can't be side-stepped.

Support email

contact@nutrisynccollective.com (English "contact") — app, privacy draft and docs all reference it; Design asked to fix hello@ at source (doc 12 §16).