Subject: Runtime V2 — custom environment variables never reach process.env in container

Project ID: 7f1f0d0d-34d3-40ee-a47f-876456125813 ("railway up")

Service ID: 55e81c31-5163-45da-823e-6805befc6593 ("simplexity-portal")

Environment: production (1bb87955-c918-493f-91ff-559425485970)

Summary

None of this service's custom/user-set environment variables reach process.env in the running container. Only Railway's own auto-injected platform variables are present (e.g. RAILWAY_PROJECT_ID, RAILWAY_PRIVATE_DOMAIN, RAILWAY_ENVIRONMENT_ID). This includes RAILWAY_BETA_ENABLE_RUNTIME_V2 itself, which IS present — the service appears to be on the Runtime V2 beta.

What I tried, all with no effect

1. Cross-service reference variable: set DATABASE_URL = ${{Postgres.DATABASE_URL}} (Postgres is a plugin service in the same project/environment). Redeployed twice — once with skipDeploys, once without, each followed by a full rebuild. Never appeared in the container's env.
2. Plain literal variable: set TEST_PLAIN_VAR = hello123 (no reference syntax at all). Also never appeared, after a full redeploy. This rules out "just reference resolution is broken."
3. Environment-wide shared variable: set DATABASE_URL at the environment level instead of service-scoped. Didn't even trigger a redeploy — services apparently need to explicitly opt in to shared vars, so this wasn't a real test, but it didn't help either.
4. Start-command override: set the service's custom start command to DATABASE_URL="${{Postgres.DATABASE_URL}}" node server.js, hoping the template syntax would resolve the same way it does for Variables. Instead the container crash-looped — the literal ${{...}} string appears to have been passed straight to the shell, which is invalid syntax. (I've since reverted the start command to empty and confirmed the service is stable again on plain npm start.)

Confirmation via a diagnostic endpoint

I added a temporary endpoint to the app itself that reports Object.keys(process.env) at request time. Across every attempt above, the full list of visible keys was limited to auto-injected platform vars (RAILWAY_*, NODE_ENV, PATH, npm-related vars, etc.) — never any custom variable I set, regardless of method.

Also affected: volume-derived variables

This service has a volume mounted at /data (confirmed via the service's own config: volumeMounts: {"1388f30e-822d-472b-9705-a916cd3c1d08": {"mountPath": "/data"}}), yet RAILWAY_VOLUME_MOUNT_PATH, RAILWAY_VOLUME_ID, and RAILWAY_VOLUME_NAME are also completely absent from the running container's env, despite being listed as configured variable names via the API (list-variables). This suggests the bug isn't specific to cross-service references — it affects any variable that isn't one of Railway's own baseline auto-injected platform vars.

Impact

This is blocking a migration from local-file storage (on the mounted volume) to Postgres for user-account persistence, since the app can never see DATABASE_URL and therefore can never connect. We suspect this same bug may be the root cause of an earlier, separate issue where the mounted volume appeared not to persist data across redeploys — if RAILWAY_VOLUME_MOUNT_PATH was never actually reaching the app, it would have silently fallen back to an ephemeral local path the entire time, which would look exactly like "the volume doesn't persist" from the outside.

Ask

Please look into why user-set and volume-derived environment variables aren't being injected into this service's running container, and whether this is a known Runtime V2 limitation. If there's a way to opt this specific service out of Runtime V2 back to the standard runtime, that would also be a welcome workaround — I wasn't able to find a UI toggle for it under Settings.