Environments
Two fully isolated Railway environments — testing and production — each with its own domain, database, and deploy trigger. Set up 2026-09-24.
Production is not fully live yet. The domain, database, and deploy pipeline are real and isolated, but Razorpay/Cashfree on production still hold testing's sandbox keys (copied when the environment was created). Real money does not move on production until live keys are set — see Third-party services.
URLs
| Testing | Production | |
|---|---|---|
| Backend API | https://api-staging.dailymeet.in |
https://api.dailymeet.in |
| Admin Panel | https://admin-staging.dailymeet.in |
https://admin.dailymeet.in |
| Railway fallback URLs | backend-production-74c8.up.railway.app, admin-panel-production-64bd.up.railway.app |
backend-production-092e1.up.railway.app, admin-panel-production-b9f1.up.railway.app |
| Backend health check | /health on either backend URL | |
Everything else, side by side
| Testing | Production | |
|---|---|---|
| Railway environment name | testing | production |
| Deploys from git branch | main — every push auto-deploys | production — only when that branch updates |
Backend ENVIRONMENT value | staging | production |
| Database | own Postgres, own volume | own Postgres, own volume — never shares data with testing |
| Razorpay / Cashfree | sandbox / test keys | still sandbox (copied from testing) |
| Firebase, Agora, Cloudflare TURN, Stream, MSG91 | shared between both environments — see Third-party services | |
Why the apex domain (dailymeet.in) is untouched
The root domain already carries the account's Google Workspace mail records (MX → smtp.google.com, plus a google-site-verification TXT). A DNS CNAME at the root cannot coexist with those, so both environments live on subdomains only — the registrar (BigRock) refuses a root CNAME outright if other records already exist there.
DNS records (registrar: BigRock, zone dailymeet.in)
| Type | Host | Points to | Environment |
|---|---|---|---|
| CNAME | api-staging | bjs7qxy4.up.railway.app | testing |
| CNAME | admin-staging | mbe81k3e.up.railway.app | testing |
| CNAME | api | t9pf24e9.up.railway.app | production |
| CNAME | admin | teeqzggt.up.railway.app | production |
Check current status any time: railway domain status <domain> --service <name> --environment <env> (expect Verified: yes, Certificate status: CERTIFICATE_STATUS_TYPE_VALID). Note: if a custom domain is ever deleted and re-created, Railway issues a new CNAME target — re-check before assuming the value above still applies.
Promoting testing → production
production deploys only from the production git branch, specifically so a routine push to main can never reach real users by accident. To release what's on main:
git checkout production
git merge main
git push origin productionRailway auto-deploys both backend and admin-panel in the production environment once that lands. There is no CI gate beyond this — the merge itself is the release action, so only merge what has actually been exercised on testing first.
Switching which environment you're looking at (Railway CLI)
railway environment testing # or: railway environment production
railway status # confirms which one is linked
railway variables --service backend --environment production --kvHistory
Until 2026-09-24 there was a single Railway environment, internally (and confusingly) named production even though it was being used for day-to-day testing. It was renamed to testing, moved onto the -staging subdomains, and a real production environment was created alongside it via railway environment new production --duplicate testing (which is also why production initially inherited testing's env values — each had to be corrected by hand afterward, including the security-relevant ENVIRONMENT flag). Full blow-by-blow is in daily-meet-platform/docs/KT_CHANGELOG.md under 2026-09-24.