Environment Variables

TL;DR -This is the master list of the backend's "settings dials" -the environment variables that control everything from the database connection to SMS delivery to in-app-purchase verification -with the correct production value for each.

Who this is for -DevOps & Operations: your reference sheet, keep it open when editing a server config. Engineering: the source of truth when adding a new variable. Executive & Product: skim the section headings to see what moving parts exist.

An environment variable is a named setting the server reads when it starts — like DATABASE_URL or PORT. Rather than hard-coding secrets and hostnames into the app, we keep them in a single settings file so the same code can run in development, staging, and production just by swapping the file. That file is .env.production and it lives only on the server, never in the code repo, because it holds real secrets.

Two example templates in the repo document every variable without any real secrets: backend/.env.example (development) and .env.production.example (production, at the repo root). When someone adds a new variable, they add it to these templates in the same change -that keeps this page and the templates honest.

The rest of this page is the full reference, grouped by area. Each table lists the variable, what it does, and the value to use in production.

Core

The essentials: what mode the server runs in, which port it listens on, how it reaches the database, and the secrets used to sign login tokens.

OTP & messaging

These control how users receive login codes (by SMS or email), how social sign-in is validated, and how push notifications are sent. The OTP_TEST_* variables are QA conveniences that must be pruned before launch.

Media (SFU)

The SFU is the media server that relays one broadcaster's live video and audio out to many viewers. These variables tell it which network address to advertise and which UDP ports it may use for real-time media.

In-app purchases

These verify real money purchases with Apple and Google before any coins are credited. Getting them right is what stops fraudulent or replayed receipts.

Misc

Everything else: diagnostics toggles, payout scaffolding, object storage for media, the admin login token, the docs container binding, database bootstrap, and the offsite backup destination.

Conventions

A few rules that apply across all of the above:

• Multiline keys (*_PRIVATE_KEY) may be stored single-line with \n escapes -services normalize them.
• Env-only changes deploy with up -d <service> (no --build).
• docker-compose.prod.yml has no URL fallback defaults: PUBLIC_APP_URL, ADMIN_API_BASE_URL, and the two LIVE_ROOM_SIMULATOR_* URLs are required (${VAR:?}), and every compose command needs --env-file .env.production -see Server Provisioning.
• Never commit real values; the two example files are the documentation of record for new variables -update them in the same PR that adds one.

Related pages

• Infrastructure -the containers these variables configure.
• Server Provisioning -the script that reads the domain/certbot variables.
• Backup & Restore -where BACKUP_RCLONE_REMOTE is used.
• Authentication -the login flow the OTP and JWT variables drive.