We can't confirm that any supported operation does exactly this combination: start a CLI-uploaded service with its current saved variables while guaranteeing reuse of a specific existing image, with no rebuild. Treat it as unsupported unless you can verify it yourself.

Here is what we can confirm. serviceInstanceRedeploy(serviceId, environmentId) redeploys the service's latest deployment from that deployment's existing source. It does not upload new code and does not pull a new commit. The CLI equivalent, railway redeploy, redeploys the most recent deployment without uploading new code. Redeploy is the step that applies saved environment variable changes, but it is also described as a fresh deployment of the same code. That means you get the same source, not a promise of the same image.

Redeploying a specific deployment from the deployment menu uses that deployment's source code. Rollback is limited to deployments that are still inside your plan's image retention window.

We can't verify that usePreviousImageTag on deploymentRedeploy guarantees an identical existing image. We also can't confirm that it combines that image with the service's current variables rather than the earlier deployment's snapshot. For CLI-upload deployments specifically, the only thing we can confirm is that redeploy reuses the stored upload instead of asking you to upload again.

There is no read-only plan or dry-run that shows which image and configuration a redeploy will use before it runs. After it runs, you can list deployments with railway deployment list --json and check the result.

Thanks. The original question remains unresolved. Please route this same generic platform-semantics question to a Railway technical team member for confirmation; no account investigation or changes are requested. We need either a documented supported operation that combines current saved runtime variables with the exact pre-existing image digest for a CLI-uploaded deployment, without a rebuild, or explicit confirmation that this cannot be guaranteed. Please clarify whether usePreviousImageTag provides any such guarantee. Do not perform a deployment or other account action. No identifiers, logs, code, files or secret values are provided.

Please route this configuration-semantics issue to a human Railway engineer. Using Railway CLI 5.71.0 and the public GraphQL API, the EnvironmentConfig schema accepts services[serviceId].build.railpackVersion = "0.40.1". environmentStageChanges echoes the exact single-field patch. environmentPatchCommitStaged(skipDeploys: true) returns a commit workflow; the patch becomes COMMITTED, the workflow Complete, and both errors are null. However, the subsequent Environment.config(decryptVariables:false) for that service still omits build.railpackVersion. No deployment occurred. A prior build also selected Railpack 0.43.0 despite the saved RAILPACK_VERSION variable being 0.40.1.

What supported configuration-only operation actually persists an explicit Railpack version and provides authoritative next-build readback without building, deploying, restarting, editing the immutable upload context or relying only on that variable? Is the service-level field unsupported by the commit path despite schema acceptance? Please clarify precedence and the exact safe preflight verification.

This is a generic platform-semantics question only. No account investigation or changes are requested or authorized. No identifiers, code, files, logs, secret values or customer data are supplied.