Environment Variables: Phased Rollout

This file tracks env vars that upcoming phases will need so ops can provision them ahead of the corresponding ship date. Each entry notes the phase that first requires it, how to obtain the value, and where it lands (docker-compose env, caddy env, secret store).

Already provisioned (reference)

Var	Surface	Notes
DOMAIN	caddy + backend	mudah-dev.stub.id on dev
POSTGRES_*, DB_*	postgres + backend	.env.production
CLERK_SECRET_KEY, VITE_CLERK_PUBLISHABLE_KEY	backend + frontend build	auth
BRICK_BASE_URL, BRICK_CLIENT_ID, BRICK_CLIENT_SECRET	backend	Payment wrapper currently wired under this name; Mudah QRIS / WA capabilities will ride on the same credentials unless Mudah issues a new key pair

New variables required by upcoming phases

Phase 4: Telegram gating app

Var	How to obtain	Where to set
TELEGRAM_BOT_TOKEN	Create @DiskoverBot via Telegram @BotFather; /newbot → bot username → copy the token it returns	dev-machine/.env.production → passed into backend service via docker-compose.yml env_file
TELEGRAM_WEBHOOK_SECRET	Generate a random 32-byte hex string (openssl rand -hex 32)	Same as above. Used to sign/verify the X-Telegram-Bot-Api-Secret-Token header on /webhooks/telegram. Register with Telegram via setWebhook?secret_token=... at deploy time

Deploy step: add an idempotent dev-machine/setup-telegram-webhook.sh that calls https://api.telegram.org/bot<TOKEN>/setWebhook with url=https://mudah-dev.stub.id/webhooks/telegram and secret_token=$TELEGRAM_WEBHOOK_SECRET. Run on every deploy.

Phase 6: Email + WA broadcasts

Var	How to obtain	Where to set
RESEND_API_KEY (only if needed)	resend.com → API keys. Only provision if Mudah doesn't already expose a bulk email sender. Pending confirmation from Mudah operations before purchasing/integrating a third party	dev-machine/.env.production
MUDAH_WA_API_KEY (or confirm re-use of BRICK_*)	Internal Mudah team: confirm whether WA broadcasts ride on the existing Brick credential set or require a separate key	dev-machine/.env.production; naming decision should be ratified before Phase 6 starts

Rate limits to hard-code (not env): 2 WA campaigns per creator per day; 10k recipients per email campaign.

Phase 7: Compliance / KYC field encryption

Var	How to obtain	Where to set
DB_FIELD_KEY	Generate a random 32-byte key: openssl rand -base64 32. Back up in 1Password + split between two engineers; rotating this breaks decryption of existing KYC NIK + phone rows	dev-machine/.env.production → backend service env

Implementation note: use AES-256-GCM via Go's crypto/aes + crypto/cipher. Store as base64 in env. Don't use pgcrypto unless we're also committing to moving all KMS to the DB side (we're not for v1).

Notes

• All vars live in dev-machine/.env.production (git-ignored). The deploy.sh script already sources it via docker-compose --env-file. Vite-exposed vars must be prefixed VITE_ and referenced at build time in dev-machine/docker-compose.yml args:.
• When adding new secrets, also mirror them into dev-machine/.env.production.example (without real values) so the checklist is self-documenting for future ops.