2 hours ago
We are preparing a source-only release of an existing service using Railway CLI 5.71.0, with explicit project, environment and service IDs. The environment already has an unapplied STAGED patch with 14 actual configuration field changes (12 variable names, including sealed attributes). We need to keep that patch untouched and deploy only code using applied LIVE variables. Production deployment is paused until this behavior is clear.
Please confirm the supported server-side behavior of the existing-service upload endpoint used by this CLI:
railway up <release-directory> --project <ID> --environment <ID> --service <ID>
- Does this source upload leave a non-empty pending patch unapplied and unchanged, without internally calling environmentPatchCommitStaged or an equivalent commit?
- For Build, pre-deploy and runtime separately, are variable values and secret/reference resolution taken only from applied LIVE configuration, excluding pending staged values and pending sealed-attribute changes?
- Which supported read-only configuration/snapshot checks can verify the effective variable SOURCE without exposing secret values?
Evidence: the v5.71.0 CLI source directly calls upload_deploy_tarball and POSTs to /project/{project}/environment/{environment}/up?serviceId={service}; its existing-service path has no direct staged-commit call. Previous successful source uploads left the same non-empty patch visible. We understand configuration-as-code in the release can intentionally override deployment-level build/start/pre-deploy settings; those are separately reviewed. Patch preservation alone does not prove which secret values each phase used.
The official variables documentation says staged edits must be reviewed/deployed before applying, but we did not find an explicit description covering all three phases of this source-upload path with a non-empty patch. We have not performed a new production test or modified the patch to investigate.
The user requested an official clarification of this release blocker. This is a product-semantics question, not a request to change, deploy, restart or inspect application/customer data. Please do not modify any resources. No credentials or private resource IDs are included. If there is an existing authoritative reference or safer source-only method, please point us to it.
Prepared with Railway's support template (v1).
1 Replies
Status changed to Awaiting Railway Response Railway • about 2 hours ago
2 hours ago
Following up on this existing thread with the precise remaining release question:
We have a Production Railway service with a non-empty STAGED environment patch containing encrypted/sealed variable changes.
We deploy a source-only package using Railway CLI 5.71.0 (railway up), without accepting or discarding staged changes.
Please explicitly confirm whether each phase resolves variables exclusively from the committed LIVE configuration:
- Image Build
- Pre-deploy command
- Running application container
Can any of these phases resolve staged encrypted values or staged sealed-variable references before environmentPatchCommitStaged?
Does railway up preserve the existing patch completely, including encrypted values and sealing metadata?
We need to deploy source safely without applying an unrelated Production secret patch.
We have read the moderator response here: https://station.railway.com/questions/will-skip-deploys-or-railway-up-touch-fc291a96 . That confirms source upload does not commit staged changes, but does not explicitly cover the three variable-resolution phases above. Please provide a supported server-side contract or authoritative reference. No resource modifications or deployment are requested; no secrets or private resource IDs are included.
Status changed to Awaiting Railway Response Railway • about 2 hours ago