There is some extremely misguided and old information in that thread.

- The V2 runtime has been out for well over a year.

- 100% of our customer workloads have run on it for well over a year.

- Legacy hasn't been an option for well over a year.

But bottom line, if you are experiencing variable injection issues, it's not a Railway platform or product issue.

Understood that V2 is the only runtime — withdrawing that theory.

But I do have evidence this isn't a code issue. On the same service, same deployment, same Node process:

- 6 environment variables ending in _SECRET are visible in process.env (verified via Object.keys(process.env).filter(k => k.endsWith('_SECRET')).length === 6)

- 3 specific variables I've added COMBO_WORLD_DOOR_SECRET, DOOR_SECRET_V2, DOOR_KEY) all return length: 0 from process.env

- Yesterday, when SSH'd into the running container, printenv showed COMBO_WORLD_DOOR_SECRET with the full 64-char hex value, but the Node process on that same container saw it as undefined - All three names are set at Service Variables scope. Verified values via the eye icon in the dashboard.

- I have a /api/debug/env-presence endpoint that runs inside the container and reads process.env directly. Latest probe output (deployment built from commit 09ac769, container booted 2026-04-27T23:33:52Z):

combo_secret_present: false, combo_secret_length: 0

v2_secret_present: false, v2_secret_length: 0

door_key_present: false, door_key_length: 0

all_secret_envs: 6

`

Repo has no .env file committed (only .env.example), so dotenv is a no-op. No code path overrides these specific names.

Service: probedge-master-production. Project: ProbEdge-Master.

If printenv shows the value but process.env doesn't, that's a runtime injection issue, not a user code issue. Can you check service-side logs for whatever's filtering these three names?

This is either a code, configuration, or setup issue on your end.

I'll open this thread up to the community so they can help you.