Subject: Clarification of exact-commit deployment and rollback side effects We are planning an API-only Stage deployment for an already GitHub-connected service. Autodeploy is disabled. Before authorizing any deployment, please clarify the current supported behavior of these operations: 1. serviceInstanceDeployV2(serviceId, environmentId, commitSha): Does this change persistent source/branch settings, deployment triggers or autodeploy, affect other services/environments, or consume pending staged configuration? Which configuration is used for the deployment? Does explicit commit selection require any branch/ref change? 2. deploymentRollback(id), targeting a retained older deployment: Does rollback execute a pre-deploy command? If so, which deployment's command, timeout and environment configuration are used? 3. Beyond restoring the old image and custom variables: Which settings are restored versus retained, including source/triggers, start/pre-deploy settings and shared/reference variables? Are references resolved again or restored as historical resolved values? Can rollback consume pending staged configuration? Please distinguish documented guarantees from any behavior that is not guaranteed, and provide authoritative references where available. This is a clarification request only. We do not authorize a deployment, configuration change, rollback or test operation.

Clarification of exact-commit deployment and rollback side effects

nasskam

HOBBYOP

7 days ago

Subject: Clarification of exact-commit deployment and rollback side effects

We are planning an API-only Stage deployment for an already

GitHub-connected service. Autodeploy is disabled.

Before authorizing any deployment, please clarify the current supported

behavior of these operations:

serviceInstanceDeployV2(serviceId, environmentId, commitSha):

Does this change persistent source/branch settings, deployment triggers

or autodeploy, affect other services/environments, or consume pending

staged configuration? Which configuration is used for the deployment?

Does explicit commit selection require any branch/ref change?

deploymentRollback(id), targeting a retained older deployment:

Does rollback execute a pre-deploy command? If so, which deployment's

command, timeout and environment configuration are used?

Beyond restoring the old image and custom variables:

Which settings are restored versus retained, including source/triggers,

start/pre-deploy settings and shared/reference variables?

Are references resolved again or restored as historical resolved values?

Can rollback consume pending staged configuration?

Please distinguish documented guarantees from any behavior that is

not guaranteed, and provide authoritative references where available.

This is a clarification request only. We do not authorize a deployment,

configuration change, rollback or test operation.

$10 Bounty

4 Replies

Railway

BOT

7 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 7 days ago

0x5b62656e5d

MODERATOR

7 days ago

For serviceInstanceDeployV2, the latest configuration is used (rollbacks aren't considered the latest). Also, from my testing, it doesn't look like explicit commit selection requires a branch/ref change.
It uses the old deployment's configuration (you can view this in the details tab of the target deployment).
Answered in 2. Also, staged configurations will stay staged, even when a deployment is rolled back.

0x5b62656e5d

1. For `serviceInstanceDeployV2`, the latest configuration is used (rollbacks aren't considered the latest). Also, from my testing, it doesn't look like explicit commit selection requires a branch/ref change. 2. It uses the old deployment's configuration (you can view this in the details tab of the target deployment). 3. Answered in 2. Also, staged configurations will stay staged, even when a deployment is rolled back.

nasskam

HOBBYOP

7 days ago

Thank you. Two execution details remain unclear:

Does deploymentRollback(id) actually execute the target deployment’s pre-deploy command, if one is configured? We understand that it uses the old configuration, but need to distinguish restoring that setting from executing the command.
For serviceInstanceDeployV2(..., commitSha), does “latest configuration” mean the latest applied configuration, with any pending staged changes left untouched?

Please distinguish documented or Railway-confirmed behavior from observations in your own tests.

nasskam

Thank you. Two execution details remain unclear: 1. Does deploymentRollback(id) actually execute the target deployment’s pre-deploy command, if one is configured? We understand that it uses the old configuration, but need to distinguish restoring that setting from executing the command. 2. For serviceInstanceDeployV2(..., commitSha), does “latest configuration” mean the latest applied configuration, with any pending staged changes left untouched? Please distinguish documented or Railway-confirmed behavior from observations in your own tests.

0x5b62656e5d

MODERATOR

7 days ago

Yes, it will use that deployment's predeploy command (if one was configured).
Latest applied.

0x5b62656e5d

1. Yes, it will use that deployment's predeploy command (if one was configured). 2. Latest applied.

nasskam

HOBBYOP

6 days ago

Thanks for the clarification and for testing this! Your answers clarified configuration selection and pre-deploy behavior, helping us refine our deployment and recovery plan. We haven’t executed the rollout yet, so we can’t confirm end-to-end success, but this resolved an important part of our uncertainty.

Welcome!