Skip to main content

Environment Variables

Royal Glow runs a monorepo with three Next.js apps (apps/web, apps/admin, apps/cms) plus the apps/invoicing PDF render service, deployed across Cloudflare Workers (rgss-web, rgss-admin — via the OpenNext adapter @opennextjs/cloudflare), Render (rgss-cms), and Cloud Run (apps/invoicing), and relies on ~15 external services.
Environment variables are validated at build time using @t3-oss/env-nextjs + Zod. If any required variable is missing or malformed, the build fails immediately. Never use process.env directly — always import from apps/web/src/env.ts.
Guarded-no-op pattern. Optional integrations (Redis, R2, Resend, Brevo, web-push, Ably, Slack, QStash heartbeats) degrade gracefully. When their keys are absent the related call becomes a no-op + log instead of throwing: the health probe reports skip rather than fail, the Ably token route returns 503 so the client falls back to polling, and background jobs still complete and return 200. This is why the app builds and runs with an incomplete .env — only the truly required core (database, auth) is hard-validated.

Quick Start

1

Copy templates

2

Fill in values

Populate each .env.local with values from your service dashboards.
3

Generate VAPID keys (one-time only)

4

Validate

The build fails fast if anything required is missing or malformed.

File Structure

Complete Variable Reference

Database (Neon)

Per-environment branches: Use GitHub Environments so DATABASE_URL points to the correct Neon branch per environment (prod / pprd / test / dev).

Auth — Better Auth

Email — Transactional (Resend)

Email — Marketing (Brevo)

Realtime — Ably

File Storage — Cloudflare R2

Cache — Upstash Redis

Queue — Upstash QStash

Web Push — VAPID Keys

Generate once: bunx web-push generate-vapid-keys. These never change unless you intentionally rotate (which invalidates all existing push subscriptions).

Cloudflare — KV + CI/CD

Observability — Sentry

Observability — BetterStack

Analytics — PostHog & Clarity

Ads & Tracking — Meta

Reporting

CRM — AiSensy

CMS — Payload

App Configuration

NODE_ENV vs APP_ENV: NODE_ENV is always development or production (Next.js convention). APP_ENV distinguishes between our 4 deployment environments: dev, test, pprd, prod. Use APP_ENV for environment-specific logic.

Variable Count Summary

Platform Injection

All platforms inject vars at runtime — no .env file is needed or present in production.

GitHub Secrets

Set under Repository Settings → Secrets and variables → Actions: Reference in GitHub Actions:
Last modified on July 30, 2026