Deployment
Royal Glow ships through a four-stage Git pipeline with progressively stricter gates, deploys to Cloudflare’s edge, and decouples deploy from release using PostHog feature flags. The whole platform runs at ₹0/month on free tiers at launch.Deploy ≠ release. Code goes live on the edge on every merge to
prod;
a feature only becomes visible when its PostHog flag is turned on. A bug means
flipping a flag off — no rollback required.Branch strategy
Four persistent branches, each mapped to an environment and a Neon DB branch. Work flows in one direction:dev → test → pprd → prod. There are no direct
pushes to prod.
The
pprd branch is reset from prod every 24h via the Neon Branch Reset
API (a near-instant copy-on-write operation), then a PII-anonymisation script
scrubs names, phones, and emails so UAT has realistic data without real customer
PII. QStash scheduled jobs target prod only.
Hosting topology
- Edge: Cloudflare Workers (via the OpenNext adapter,
@opennextjs/cloudflare) serve the customer site (rgss-web,theroyalglow.in) and the admin portal (rgss-admin,admin.theroyalglow.in) globally — deployed near India (Mumbai / Singapore). Not Cloudflare Pages, notnext-on-pages. - CMS: Render (Singapore, free tier) hosts Payload CMS (
rgss-cms,cms.theroyalglow.in). - PDF render: Cloud Run hosts the invoice PDF service (
@rgss/invoicing). - Database: a single Neon PostgreSQL 16 project with four branches.
- Media: Cloudflare R2 (S3-compatible, zero egress). Cache + queue: Upstash Redis + QStash. Realtime: Ably.
GitHub Actions workflows
These workflows enforce the gates above and handle production deploys.
Web, admin and CMS deploy from git on Render today;
deploy-aws.yml is the AWS path
described in M2AWS.md. The earlier Cloudflare workflows (deploy-prod.yml,
deploy-admin-prod.yml) were retired along with the Workers adapter.
Lighthouse gates require performance ≥ 95 and accessibility, best-practices, and
SEO = 100.
Feature-flag release strategy
Every feature ships to prod behind a PostHog flag and is exposed gradually.1
Deploy with the flag OFF
Code goes live on the edge, invisible to everyone.2
Flag ON for role = developer
Self-test directly in production.3
Flag ON for role = owner | manager
Stakeholder preview.4
Flag ON for 10% of customers
Watch Sentry for new errors.5
Flag ON for 100%
Full release to all customers.6
Remove flag + dead code
After 2 weeks stable, clean up the flag and dead code.Rollback tiers
When something goes wrong, escalate from the cheapest, fastest lever upward.Health check
GET /api/health probes the database, Redis, and R2 in parallel and returns a
HealthStatus contract: healthy / degraded / unhealthy. It responds 200
for healthy or degraded and 503 for unhealthy, always with
Cache-Control: no-store. BetterStack polls it every ~3 minutes and opens an
incident on status.theroyalglow.in if it fails.