Subject: Service Variables not injected into running container (Dockerfile builder) Project: merry-spontaneity Service: refactored-octo-barnacle Environment: production (confirmed via RAILWAY_ENVIRONMENT_NAME) Public URL: https://refactored-octo-barnacle-production.up.railway.app Builder: Dockerfile (railway.json: "builder": "DOCKERFILE") Symptom: Variables set in the service's Variables tab are visible and correct in the dashboard, but do not appear in the running container's process environment at all. This affects ALL custom variables, not just newly-added ones — including long-standing ones like DATABASE_URL and APP_ENV that were set before today. Evidence: - Ran `env | grep -E "DATABASE_URL|APP_ENV|TELEGRAM"` in the Railway Console (connected to the live running container) — zero output, across multiple fresh deployments (container hostnames: fd367ded4d22, e09b46ee6d5d, 745a6620b6a6, and others). - Independently confirmed via HTTP: the app computes a value derived from one of these variables (a hash of TELEGRAM_BOT_TOKEN), and the computed value matches what you'd get from an EMPTY string, not the actual configured token — proving the main web process itself (not just the Console shell) never receives the variable. - Confirmed correct project (RAILWAY_PROJECT_NAME = merry-spontaneity) and environment (RAILWAY_ENVIRONMENT_NAME = production) via the dashboard's reveal toggle — so this isn't a wrong-project/wrong-environment mix-up. What we already ruled out: - Typos in variable names/values (re-checked pixel-for-pixel against what the app expects). - Dockerfile ARG/ENV shadowing (Dockerfile has no ARG/ENV for any of these keys — only PYTHONUNBUFFERED/PYTHONDONTWRITEBYTECODE/PIP_NO_CACHE_DIR). - Stale/cached deployment (reproduced across 5+ fresh deployments, each with a distinct deployment ID and container hostname). - Deleting and recreating the variables from scratch (no change). - A second, unrelated project existing on the account (proactive-inspiration) — not the one serving this domain, confirmed via RAILWAY_PROJECT_NAME. Could you help identify why this service's container isn't receiving its configured Variables at runtime? Happy to provide deployment IDs or run any diagnostic you need.

Service Variables not injected into running container (Dockerfile builder)

strawberryspring67-tech

FREEOP

a month ago

Subject: Service Variables not injected into running container (Dockerfile builder)

Project: merry-spontaneity

Service: refactored-octo-barnacle

Environment: production (confirmed via RAILWAY_ENVIRONMENT_NAME)

Public URL: https://refactored-octo-barnacle-production.up.railway.app

Builder: Dockerfile (railway.json: "builder": "DOCKERFILE")

Symptom:

Variables set in the service's Variables tab are visible and correct in the

dashboard, but do not appear in the running container's process environment

at all. This affects ALL custom variables, not just newly-added ones —

including long-standing ones like DATABASE_URL and APP_ENV that were set

before today.

Evidence:

Ran env | grep -E "DATABASE_URL|APP_ENV|TELEGRAM" in the Railway Console

(connected to the live running container) — zero output, across multiple

fresh deployments (container hostnames: fd367ded4d22, e09b46ee6d5d,

745a6620b6a6, and others).
Independently confirmed via HTTP: the app computes a value derived from

one of these variables (a hash of TELEGRAM_BOT_TOKEN), and the computed

value matches what you'd get from an EMPTY string, not the actual

configured token — proving the main web process itself (not just the

Console shell) never receives the variable.
Confirmed correct project (RAILWAY_PROJECT_NAME = merry-spontaneity) and

environment (RAILWAY_ENVIRONMENT_NAME = production) via the dashboard's

reveal toggle — so this isn't a wrong-project/wrong-environment mix-up.

What we already ruled out:

Typos in variable names/values (re-checked pixel-for-pixel against what

the app expects).
Dockerfile ARG/ENV shadowing (Dockerfile has no ARG/ENV for any of these

keys — only PYTHONUNBUFFERED/PYTHONDONTWRITEBYTECODE/PIP_NO_CACHE_DIR).
Stale/cached deployment (reproduced across 5+ fresh deployments, each with

a distinct deployment ID and container hostname).
Deleting and recreating the variables from scratch (no change).
A second, unrelated project existing on the account (proactive-inspiration)

— not the one serving this domain, confirmed via RAILWAY_PROJECT_NAME.

Could you help identify why this service's container isn't receiving its

configured Variables at runtime? Happy to provide deployment IDs or run any

diagnostic you need.

$10 Bounty

3 Replies

Railway

BOT

a month ago

All 15 variables (DATABASE_URL, APP_ENV, TELEGRAM_BOT_TOKEN, etc.) are currently staged but not yet applied - they were edited in the dashboard but never committed. You should see a deploy bar showing "15 changes" at the top of the project canvas for this environment; clicking Deploy on that bar will apply them and trigger a new deployment with the variables injected into the container.

Status changed to Awaiting User Response Railway • about 1 month ago

Railway

All 15 variables (DATABASE_URL, APP_ENV, TELEGRAM_BOT_TOKEN, etc.) are currently staged but not yet applied - they were edited in the dashboard but never committed. You should see a deploy bar showing "15 changes" at the top of the project canvas for this environment; clicking **Deploy** on that bar will apply them and trigger a new deployment with the variables injected into the container.

strawberryspring67-tech

FREEOP

a month ago

Thanks for the pointer — that was a real issue (found the Raw Editor showed 15 vars that had apparently never been committed, all matching the app's built-in defaults, e.g. DATABASE_URL="sqlite:///./var/app.db"), but it hasn't fixed the underlying problem.

Steps taken after your reply:

Opened Variables → Raw Editor, confirmed all values there (including TELEGRAM_BOT_TOKEN and PUBLIC_BASE_URL) are correct.
Clicked "Update Variables" in the Raw Editor.
Confirmed via Deployments that this did NOT trigger a new deployment on its own — the active deployment was still 21+ minutes old afterward.
Manually triggered Redeploy on the active deployment (⋮ → Redeploy). New deployment went ACTIVE ~35 seconds later, "Deployment successful".
Tested immediately after: the running container's process still does not see TELEGRAM_BOT_TOKEN (verified two independent ways — a value derived from the token doesn't match what the app computes at runtime, and Telegram's own getWebhookInfo shows the exact same "401 Unauthorized" delivery error as before, timestamped after this redeploy).

So the "staged changes" explanation was plausible and partially confirmed (Update Variables clearly did something real, distinct from just editing fields), but a genuinely fresh deployment created immediately after using it still doesn't receive the variable at runtime. This now looks less like an unsaved-changes issue and more like variables not being passed into this specific service's container at deploy time, full stop.

Could a human take a look? Happy to run any diagnostic command or share more deployment IDs.

Status changed to Awaiting Railway Response Railway • about 1 month ago

Railway

BOT

a month ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • about 1 month ago

darseen

HOBBYTop 5% Contributor

a month ago

Have you deployed the changes after adding the variables? You should see a button that says "Deploy" to confirm the pending changes, it's positioned at the top of the canvas.

Attachments

image.png

Welcome!