21 days ago
Hello Railway Support,
I'm experiencing an issue where environment variables defined in my service are not being injected into the container at runtime, and where deploys do not seem to apply pending changes.
Service: kalkener-engine
Project URL: https://miraculous-enjoyment-production-38ca.up.railway.app
Plan: Hobby
Issue 1 — Pending changes not applied after deploy
The project dashboard and the service dashboard both show a persistent banner indicating 6 pending changes. Despite triggering multiple deploys (both from the dashboard and from GitHub), this banner never clears — the 6 pending changes remain after every deploy.
This started after a period where Railway reported delays in GitHub-triggered builds.
Issue 2 — Two environment variables not injected into the container
Two variables set at service level are not available inside the container at runtime:
- RESEND_API_KEY
- ALERT_EMAIL
All other variables in the same service load correctly: API_SECRET_KEY, XLS_PATH, ALLOWED_ORIGINS, NUM_WORKERS, MAX_QUEUE_SIZE, CALC_TIMEOUT, ALERT_QUEUE_THRESHOLD.
Evidence from runtime logs:
INFO:main:RESEND_API_KEY loaded: NO
INFO:main:ALERT_EMAIL loaded: NO
INFO: Started server process [27]
INFO: Waiting for application startup.
INFO: Application startup complete.The application reads these with os.getenv() at startup. These log lines are produced by explicit checks in main.py, confirming the values are None inside the container.
Steps already taken:
- Deleted and recreated both variables from scratch (manually, no copy-paste artifacts)
- Redeployed multiple times after each change
- Waited for the previously reported deployment delay incident to resolve
- Confirmed variables are set at service level
I believe Issues 1 and 2 may be related — if pending changes are not being applied correctly, the new variables may never reach the container.
Could you please investigate the state of this service and force-apply or reset the pending changes?
Thank you.
4 Replies
21 days ago
Our logs confirm that RESEND_API_KEY and ALERT_EMAIL are being injected as empty strings at container start, which aligns with the pending staged changes not being applied. Variable changes in Railway create staged changes that must be applied by clicking the "Deploy" button in the staged changes banner on the canvas, not by triggering a GitHub push or using the per-service redeploy action. A GitHub-triggered deploy or a manual redeploy of the service will rebuild and deploy the current code but will not apply pending staged changes. Please try clicking "Details" on the staged changes banner, confirming the 6 changes look correct, and then clicking "Deploy" from that panel. If the banner still does not clear after that, please let us know.
Status changed to Awaiting User Response Railway • 21 days ago
Railway
Our logs confirm that `RESEND_API_KEY` and `ALERT_EMAIL` are being injected as empty strings at container start, which aligns with the pending staged changes not being applied. Variable changes in Railway create [staged changes](https://docs.railway.com/deployments/staged-changes) that must be applied by clicking the "Deploy" button in the staged changes banner on the canvas, not by triggering a GitHub push or using the per-service redeploy action. A GitHub-triggered deploy or a manual redeploy of the service will rebuild and deploy the current code but will not apply pending staged changes. Please try clicking "Details" on the staged changes banner, confirming the 6 changes look correct, and then clicking "Deploy" from that panel. If the banner still does not clear after that, please let us know.
21 days ago
Thank you for the clarification about staged changes.
However, I have already followed that exact process multiple times:
- Clicked "Details" on the staged changes banner
- Confirmed the 6 changes look correct (including RESEND_API_KEY and ALERT_EMAIL)
- Clicked "Deploy" from that panel
After each of these deploys, the banner still shows 6 pending changes, and the runtime logs still show:
INFO:main:RESEND_API_KEY loaded: NO
INFO:main:ALERT_EMAIL loaded: NOThe staged changes banner never clears regardless of how many times I deploy from it. It seems the service is stuck in an inconsistent state where staged changes cannot be applied through the normal UI flow.
Could this be escalated to a human engineer who can inspect and reset the state of this service on your end?
Thank you.
Status changed to Awaiting Railway Response Railway • 21 days ago
20 days ago
You did the right thing, and this is on our end. Your staged changes, including RESEND_API_KEY and ALERT_EMAIL, are stuck and are not being committed into the environment when you click Deploy, which is why the container still sees those two as empty. This is a known stuck state that the normal Deploy flow can't clear on its own. We're getting it applied for you from our side and will follow up here once the changes have gone through and the banner clears.
Status changed to Awaiting User Response Railway • 20 days ago
19 days ago
Update: we cleared the stuck state that was preventing your staged changes from committing. Open the staged-changes banner and click Deploy once more. It will go through this time, the banner will clear, and RESEND_API_KEY and ALERT_EMAIL will be available in the container. If anything still looks off after that deploy, reply here and we'll take another look.
12 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 12 days ago