an hour ago
We are coordinating a logging credential rotation for two staging services using Railway CLI 5.45.7 and the public GraphQL API. Please confirm these supported server-side behaviors; this is a technical question, not a request to modify our account.
-
With an unapplied environment stage affecting only service B, does variableUpsert with exact projectId, environmentId, serviceId=A, name, value and skipDeploys:true update A's saved configuration while preserving B's staged contents, STAGED status and appliedAt:null, without creating a deployment?
-
Does a subsequent railway up targeting only service A use A's newly saved variables without applying B's pending stage? Changes to stage ID or timestamp alone are acceptable; contents and application state are what matter.
-
Alternative: if both services' approved changes may be combined, what is the supported path to merge only those changes into one staged changeset, commit it without starting any deployment, then upload exact source to service A, verify A, and only then upload exact source to B? Specifically, does environmentStageChanges(merge:true), followed by environmentPatchCommitStaged(skipDeploys:true), persist that changeset without deploying either service? How should actual variable unsets be represented and verified when decryptVariables:false returns opaque staged values?
We need to preserve unrelated configuration and cannot use a normal Deploy/Apply all action that starts deployments. No new resources or plan changes are requested.
Please point to the authoritative contract, or explicitly confirm the existing-stage and no-deploy behavior. We have reviewed the manage-variables documentation, staged-changes documentation and CLI 5.45.7 source. This public question intentionally contains no project, service or deployment identifiers, site names, local paths, private repository information, credential values, logs or attachments.