a month ago
Hi Railway support,
I’m seeing a critical issue where environment variables are not being applied in the running container for my production service, even after multiple redeploys.
Project / service:
• Project: playbook-energy-services (production)
• Service name: playbook-energy-services
• Recent deployment ID: 920df3bc-52be-4711-b08f-448b98910049
• Commit SHA: 016c212a084d6009019adcd9cfacf6421329a01b
Symptoms:
- OANDA account ID value appears stuck
I previously had an account ID with a trailing newline. I edited the variable in the Railway UI so it is now a clean value (no newline) and then redeployed. However, my service’s diagnostic endpoint /api/safety/status still shows:
“oanda_account_id”: “101-004-39487968-001\n”
The \n at the end indicates the runtime is still using the old value, not the updated one.
- Supabase environment variables appear missing at runtime
Supabase-related variables are set in the Railway Variables UI, and supabase_url_configured is true in my health output, so the URL is present. But the same /api/safety/status endpoint reports:
“supabase_write_health”: false,
“supabase_write_error”: “client_unavailable”,
“supabase_service_role_diagnostics”: {
“selected_source”: “NONE”,
“primary_reason”: “MISSING”,
“candidate_reason”: “MISSING”,
“selected_key_format”: “none”,
“selected_role_claim”: null,
“url_configured”: true
}
From the application’s perspective, no Supabase key source is visible at runtime, even though the corresponding environment variables exist in the dashboard and have been edited and redeployed.
- Newly added test variable not reflected
To rule out misconfiguration, I added a brand‑new variable in the same service/environment:
TEST_VAR=hello123
Then I deployed again. The runtime behavior and diagnostics still indicate that custom variables are not being picked up. This is consistent with prior reports of a “stuck” environment state where variables look correct in the UI but never reach the running process.
Impact:
• The trading loop previously worked correctly.
• Market data and forecasts (for example, recent EUR/USD practice trades) still appear active, but:
• Supabase writes fail because the server cannot create a Supabase client without a visible key.
• OANDA account-level behavior is at risk because the stale oanda_account_id with the trailing newline is still visible in diagnostics.
• The current /api/safety/status output shows:
• “loop_status”: “ERROR”
• “supabase_write_error”: “client_unavailable”
What I’ve already tried:
• Edited environment variables (including OANDA_ACCOUNT_ID to remove the newline).
• Added a new test variable (TEST_VAR).
• Triggered new deployments after these changes.
• Verified that Supabase itself is healthy by writing directly from the Supabase SQL editor (the database is working fine).
Despite this, the runtime still shows:
• The old OANDA value with \n ,
• No detected Supabase key source (selected_source: “NONE”).
Request:
Could you please:
- Check whether this service/project is in a stuck environment state where variable changes are not being applied to the runtime, and
- Force-apply or reset the environment so that updated service variables (including OANDA_ACCOUNT_ID, Supabase keys, and TEST_VAR) are actually injected into the running container on deploy?
I am happy to provide the full JSON from /api/safety/status for specific deployments or run any additional diagnostics you recommend.
Thank you for your help.
Best regards,
Darryl
Pinned Solution
a month ago
Before assuming a stuck environment — the trailing \n and TEST_VAR symptoms are equally consistent with your app reading variables from somewhere other than Railway's live environment. That's self-fixable, so rule it out first.
The \n is the biggest tell. If Railway just weren't applying your edit, you'd see a stale value — but a preserved newline points to the value being read from something that keeps it: usually a committed .env file baked into the image, or a cached/config read, not live process.env. If your code loads .env (e.g. dotenv with override: true, or reading the file directly), that file beats Railway's injected vars, and editing the UI does nothing — exactly what you're seeing. TEST_VAR not showing reads as "stuck environment," but it's equally "the app isn't looking at process.env." Same symptom, opposite fix.
Two checks that tell you which it is:
Prove whether Railway injects at all — print the raw value, bypassing any config layer:
node -e "console.log('TEST_VAR =', JSON.stringify(process.env.TEST_VAR))"
Prints hello123 → Railway is fine, the bug is in how your app loads vars. Prints undefined → genuine injection issue, escalate with your deploy ID.
Check for a committed .env in the image. If one exists, that's almost certainly it — add it to .dockerignore/.gitignore and stop loading it in production. You don't need dotenv on Railway at all; vars are injected directly.
Supabase selected_source: NONE while url_configured: true usually means a variable-name mismatch — the key name your code reads doesn't match the UI (e.g. SUPABASE_SERVICE_ROLE_KEY vs SUPABASE_SERVICE_KEY). Check the exact name the code looks for against what's set.
Safe dotenv pattern (local file, never override platform vars):
js// Only loads .env if present (local dev); on Railway, real env vars win
require("dotenv").config(); // default: does NOT override existing process.env
// never use { override: true } in production
TL;DR: run check #1. hello123 → it's a .env/config-layer or name-mismatch issue in your app, not Railway. undefined → escalate to Railway as a real injection problem.
3 Replies
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
Maybe try Redeploy source image/Redeploy latest commit
You can do it by opening your service, open the command palette (Ctrl-K) then select "Redeploy source image" or "Redeploy latest commit"
If the value is still bank, try delete the variable > deploy > add it back > deploy
a month ago
Before assuming a stuck environment — the trailing \n and TEST_VAR symptoms are equally consistent with your app reading variables from somewhere other than Railway's live environment. That's self-fixable, so rule it out first.
The \n is the biggest tell. If Railway just weren't applying your edit, you'd see a stale value — but a preserved newline points to the value being read from something that keeps it: usually a committed .env file baked into the image, or a cached/config read, not live process.env. If your code loads .env (e.g. dotenv with override: true, or reading the file directly), that file beats Railway's injected vars, and editing the UI does nothing — exactly what you're seeing. TEST_VAR not showing reads as "stuck environment," but it's equally "the app isn't looking at process.env." Same symptom, opposite fix.
Two checks that tell you which it is:
Prove whether Railway injects at all — print the raw value, bypassing any config layer:
node -e "console.log('TEST_VAR =', JSON.stringify(process.env.TEST_VAR))"
Prints hello123 → Railway is fine, the bug is in how your app loads vars. Prints undefined → genuine injection issue, escalate with your deploy ID.
Check for a committed .env in the image. If one exists, that's almost certainly it — add it to .dockerignore/.gitignore and stop loading it in production. You don't need dotenv on Railway at all; vars are injected directly.
Supabase selected_source: NONE while url_configured: true usually means a variable-name mismatch — the key name your code reads doesn't match the UI (e.g. SUPABASE_SERVICE_ROLE_KEY vs SUPABASE_SERVICE_KEY). Check the exact name the code looks for against what's set.
Safe dotenv pattern (local file, never override platform vars):
js// Only loads .env if present (local dev); on Railway, real env vars win
require("dotenv").config(); // default: does NOT override existing process.env
// never use { override: true } in production
TL;DR: run check #1. hello123 → it's a .env/config-layer or name-mismatch issue in your app, not Railway. undefined → escalate to Railway as a real injection problem.
hygrivakondury
Before assuming a stuck environment — the trailing \n and TEST_VAR symptoms are equally consistent with your app reading variables from somewhere other than Railway's live environment. That's self-fixable, so rule it out first. The \n is the biggest tell. If Railway just weren't applying your edit, you'd see a stale value — but a preserved newline points to the value being read from something that keeps it: usually a committed .env file baked into the image, or a cached/config read, not live process.env. If your code loads .env (e.g. dotenv with override: true, or reading the file directly), that file beats Railway's injected vars, and editing the UI does nothing — exactly what you're seeing. TEST_VAR not showing reads as "stuck environment," but it's equally "the app isn't looking at process.env." Same symptom, opposite fix. Two checks that tell you which it is: Prove whether Railway injects at all — print the raw value, bypassing any config layer: node -e "console.log('TEST_VAR =', JSON.stringify(process.env.TEST_VAR))" Prints hello123 → Railway is fine, the bug is in how your app loads vars. Prints undefined → genuine injection issue, escalate with your deploy ID. Check for a committed .env in the image. If one exists, that's almost certainly it — add it to .dockerignore/.gitignore and stop loading it in production. You don't need dotenv on Railway at all; vars are injected directly. Supabase selected_source: NONE while url_configured: true usually means a variable-name mismatch — the key name your code reads doesn't match the UI (e.g. SUPABASE_SERVICE_ROLE_KEY vs SUPABASE_SERVICE_KEY). Check the exact name the code looks for against what's set. Safe dotenv pattern (local file, never override platform vars): js// Only loads .env if present (local dev); on Railway, real env vars win require("dotenv").config(); // default: does NOT override existing process.env // never use { override: true } in production TL;DR: run check #1. hello123 → it's a .env/config-layer or name-mismatch issue in your app, not Railway. undefined → escalate to Railway as a real injection problem.
a month ago
Thanks for your assistance. Very much appreciated 👍
Status changed to Solved milo • about 1 month ago