Rollback is the option that starts a new deployment from an existing Docker image without rebuilding, and it restores that deployment's custom variables along with the image. You start it from the three-dot menu on the deployment in the service's Deployments tab. The Rollback entry only appears while the deployment's image is inside your plan's image retention window, which is 72 hours on Hobby and starts when a deployment is removed. Before you remove anything, open that menu on the crashed deployment: if Rollback is listed there, it is eligible.

Volumes belong to the service rather than to a single deployment, so a rollback on the same service runs against the same attached volume, and data on a volume is kept between deployments. Only one deployment can have the volume mounted at a time, so expect a short gap while the old container stops and the new one starts.

We have not confirmed whether Rollback is offered on the deployment that is currently active, so checking that menu is the reliable way to know before you remove it.

Thanks. I checked the three-dot menu on the current crashed deployment. It shows View logs, Restart, Redeploy, and Remove, but no Rollback. Can Railway confirm whether there is a supported no-rebuild recovery in this case, with the existing volume left attached? In particular, can eligibility be verified before removing the deployment? Guidance only, please.

Rollback is offered from a previous deployment's menu, not from the service's current one, so Rollback missing on the active crashed deployment does not tell you whether it would become eligible after removal. Our earlier reply suggested that menu check as a test, and that was not a reliable way to confirm eligibility. We have not verified whether Rollback becomes available on a deployment after it is removed, so we can't confirm ahead of time that removing it would leave a no-rebuild path open.

The supported actions that reuse the existing image without rebuilding are Restart, which you have already tried, and Rollback from a previous deployment that is still inside your plan's image retention window (72 hours on Hobby, counted from when a deployment is removed). Redeploy creates a new build. Whichever you use on the same service, the volume stays attached, and only one container mounts it at a time, so the old container is stopped before the new one starts.

Thanks for clarifying. Could a Railway staff member review this? For a current crashed deployment built from a CLI source upload, can Railway verify before removal that its exact image can be reused in a fresh container on the same service, with the existing volume still attached? If there is no supported way to verify that in advance, please confirm. This is a request for guidance only.

We can't confirm ahead of time that this specific crashed deployment will be eligible for Rollback once it's removed. We don't have a supported way to guarantee that before removal.

Here is what we can confirm. Our pricing docs say a removed deployment can be rolled back within your plan's image retention window, which is 72 hours on Hobby and starts at removal. That rollback restores the previous image, settings and variables in a new deployment, with no rebuild. A rollback on the same service runs against the same attached volume. Outside that window, Rollback is no longer offered and the only option left is Redeploy, which rebuilds from the original source.

The public API exposes a canRollback field on deployments, and deploymentRollback only accepts deployments where it is true (docs). You can read that field at any time, but for the deployment that is currently active it reflects present state. We have not verified that it predicts eligibility after removal, or that a CLI source upload makes any difference. So it isn't a reliable check before you remove the deployment.

Restart is the one action we can confirm reuses this exact image without removing anything, and you have already tried it.