3 hours ago
Subject: Sealed variable rotation unexpectedly triggers service redeployment
Hello Railway Community,
I'm using Railway Hobby with multiple services in a production environment.
I need to rotate sealed environment variables while avoiding unintended redeployments of existing services.
During a previous configuration update, I used Alt+Deploy to commit staged changes without redeployment. However, one existing service was unexpectedly redeployed, while the other services remained unchanged.
The affected service continued running correctly afterward, but I would like to understand how to prevent this behavior during future secret rotations.
Could someone clarify:
- Does editing an existing sealed variable always create staged changes without immediately redeploying the service?
- Is Alt+Deploy guaranteed to commit changes without triggering a redeployment, including when sealed variables are involved?
- Could changing a sealed variable cause a service to redeploy despite using Alt+Deploy?
- What is the recommended procedure for rotating related signing keys across multiple services without accidentally restarting production workloads?
- Do already-running containers receive updated environment variables, or is a controlled redeployment required?
- How should rollback be handled when previous sealed values cannot be retrieved?
I would appreciate a documented, safe procedure suitable for the Hobby plan.
I am not sharing project identifiers, credentials, signing keys, monitoring URLs, or deployment IDs.
Thank you!
1 Replies
Status changed to Awaiting Railway Response Railway • about 3 hours ago
an hour ago
Editing a sealed variable is staged the same way as any other variable change. Committing with Alt held on Deploy (or Alt+Shift+Enter) applies the commit without triggering deploys, and sealing a variable does not change that.
Running containers keep the environment variables they started with. A new value only reaches a service on its next deployment, so the controlled approach is to stage the rotated values, commit them without deploying, then redeploy each service yourself when you are ready to switch it over.
We can't tell from here what redeployed that one service without looking at the project. Networking changes are not staged and apply immediately, so a commit that changes networking alongside the variables behaves differently from a variables-only commit. Reviewing the staged change diff under "Details" before committing shows exactly what is included. Staged changes docs
Once a variable is sealed, its value cannot be shown again in the dashboard or the API, and it cannot be unsealed. To be able to roll back, keep the previous value in your own secret store before you rotate. Rolling back then means setting that saved value again and redeploying the affected services.
Status changed to Awaiting User Response chandrika • about 1 hour ago