Railway support report — custom variables not reaching runtime env

Identifiers

• Project: discerning-liberation (c0cc29e0-ec3b-494a-b691-687e3c7e9b9c)
• Service: healthe-atlas (f1494336-4558-4da5-b683-a1cc3c511f17)
• Environment: production (9ab6b98e-91be-4f71-8e15-cee197f8023d)
• Most recent affected deployment: e4b394e6-970b-4146-a78a-e2dc9cbd5924

Issue

Two custom variables saved on this service's Variables page under the

production environment — VISION_PROVIDER=two_stage and

VISION_PROVIDER_MODE=two_stage — are not present in process.env at

runtime, on a deployment confirmed fresh.

Evidence

• Both variables are visible in the dashboard's Variables tab for this

  exact service/environment (confirmed via UI, including after a hard

  page refresh — they persist as saved, ruling out a client-side/unsaved

  UI state).

• ANTHROPIC_API_KEY, set on the same Variables page around the same

  time, IS present in process.env and is actively used successfully by

  the running app (real outbound API calls to Anthropic succeed).

• All Railway-injected system variables (RAILWAY_ENVIRONMENT_NAME,

  RAILWAY_SERVICE_NAME, RAILWAY_SERVICE_ID, RAILWAY_ENVIRONMENT_ID,

  RAILWAY_PROJECT_ID) are present and correctly identify this exact

  service/environment.

• A temporary diagnostic endpoint (GET /diagnostics/provider) added to

  the app reports a processStartedAt timestamp captured at module load.

  On the deployment above, this returned 2026-08-23T02:33:50.666Z,

  checked ~18 seconds later — proving the responding container is freshly

  booted from the latest deploy, not a stale/lingering one.

• The container's own RAILWAY_DEPLOYMENT_ID env value

  (e4b394e6-970b-4146-a78a-e2dc9cbd5924 on this check;

  a5c1d8ce-54f7-4c7c-b39f-3b0700e5949d on an earlier check) does not

  match any deployment ID visible in this service's Deploy

  UI — flagging this separately since it was initially misread as

  "stale deployment still serving traffic," which the processStartedAt

  check above then ruled out.

• Confirmed across five separate fresh deploys (three redeploys, one

  var-triggered auto-redeploy, one delete-and-recreate-from-scratch of

  the variable), all producing the same result: the two cu

  are absent at runtime despite being saved in the dashboard.

Ask

Why would two variables set on a service's Variables page (production

environment) not appear in process.env for that service's own fresh

deployments, while another variable set the same way on th

does?