9 days ago
I’m trying to make a deployment recovery flow fail safely and I’m looking for clarification on two Railway API behaviours. I’m not asking anyone to change anything in my project, just trying to understand the guarantees.
First, is there currently any Railway API field or event that definitively means every container/process belonging to a specific deployment has fully exited and cannot restart or execute more code?
I know about deploymentStopped, deployment.status, and Deployment.instances[].status. I have also seen the recent Railway staff response saying those fields can be stale after deploymentStop. Is there a stronger lifecycle signal today, or is there genuinely no authoritative process-death signal exposed through the API?
Second, can someone confirm the exact semantics of:
deploymentRedeploy(id: ..., usePreviousImageTag: true)
Does usePreviousImageTag: true guarantee that Railway reuses the exact previously built image rather than rebuilding from source? In particular:
- Should the resulting deployment have the same
meta.imageDigestas the selected historical deployment? - Does it use the historical deployment’s configuration and variables, or current service configuration?
- Does the mutation return the newly created
Deployment, so the resulting image digest and deployment ID can be read back directly? - How does this differ from
deploymentRollback(id), which appears to return only a Boolean?
I’m specifically trying to distinguish exact artifact reuse from rebuilding the same Git commit, since those are not equivalent for my use case.
Thanks. I’m mainly looking for the documented or guaranteed semantics rather than what normally happens in practice.
1 Replies
9 days ago
On the stop signal: deploymentStop writes no status change, so the deployment keeps reporting SUCCESS and its instances keep reporting as running. The signal you want comes from deploymentRemove. It drains each instance with SIGTERM, sends SIGKILL once the draining period ends (the default is 0 seconds), and then destroys the container, so every process inside it dies. The deployment moves to REMOVING and then to REMOVED, and its instances follow. REMOVED is only written after teardown has finished for every replica. If the host was already gone, REMOVED means the container was confirmed absent rather than just terminated. Nothing recreates a REMOVED deployment. A new workload can still start in that service through a new deployment or a platform-initiated host migration.
On image reuse: our docs say a rollback restores both the Docker image and the custom variables of the selected deployment. A redeploy creates a new deployment with the same code and build/deploy configuration. We don't publish guarantees for the usePreviousImageTag flag specifically. That covers whether meta.imageDigest will match, whether historical or current variables apply, and what the mutation returns. If your flow needs exact artifact reuse, compare the digest on the resulting deployment rather than assuming it. Rollback is also limited to deployments within your plan's image retention policy.
Status changed to Awaiting User Response Railway • 9 days ago
2 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 1 day ago