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.

Hi bro,

If printenv shows the variable in an SSH shell, but the running Node app sees it as undefined, that does not automatically prove a Railway injection bug. The SSH shell environment and the already-running Node process environment may not be identical.

process.env is captured when the Node process starts. If the variable was added or changed after the app started, the app will not see it until the service is redeployed/restarted.

I would verify the environment of the actual Node process directly:

ps aux | grep node
cat /proc/<NODE_PID>/environ | tr '\0' '\n' | grep -E 'COMBO_WORLD_DOOR_SECRET|DOOR_SECRET_V2|DOOR_KEY'

Results:

• If the variables are missing from /proc/<NODE_PID>/environ, then the Node process never received them. Check redeploy/restart, variable scope, active environment, start command, Docker entrypoint, or process manager.
• If the variables exist in /proc/<NODE_PID>/environ but process.env still returns undefined, then the app code or a dependency may be modifying/deleting process.env.

So the next step is not to compare printenv vs process.env, but to compare the actual Node process environment vs process.env.