Deployment Actions

Various actions can be taken on Deployments from within the Service -> Deployments tab and clicking on the three dots at the end of a previous deployment.

Rollback

Rollback to previous deployments if mistakes were made. To perform a rollback, click the three dots at the end of a previous deployment, you will then be asked to confirm your rollback.

A deployment rollback will revert to the previously successful deployment. Both the Docker image and custom variables are restored during the rollback process.

Note: Deployments older than your plan's retention policy cannot be restored via rollback, and thus the rollback option will not be visible.

Redeploy

A successful, failed, or crashed deployment can be re-deployed by clicking the three dots at the end of a previous deployment.

This will create an new deployment with the exact same code and build/deploy configuration.

Note: To trigger a deployment from the latest commit, use the Command Palette: CMD + K -> "Deploy Latest Commit". This will deploy the latest commit from the Default branch in GitHub.

Currently, there is no way to force a deploy from a branch other than the Default without connecting it in your service settings.

Cancel

Users can cancel deployments in progress by clicking the three dots at the end of the deployment tab and select Abort deployment. This will cancel the deployment in progress.

Remove

If a deployment is completed, you can remove it by clicking the three dots at the end of the deployment tab and select Remove. This will remove the deployment and stop any further project usage.

When a Deployment is Crashed, it is no longer running because the underlying process exited with a non-zero exit code - if your deployment exits successfully (exit code 0), the status will remain Success.

Railway automatically restarts crashed Deployments up to 10 times (depending on your Restart Policy). After this limit is reached, your deployment status is changed to Crashed and notifying webhooks & emails are sent to the project's members.

Restart a Crashed Deployment by visiting your project and clicking on the "Restart" button that appears in-line on the Deployment:

Restarting a crashed Deployment restores the exact image containing the code & configuration of the original build. Once the Deployment is back online, its status will change back to Success.

You can also click within a deployment and using the Command Palette restart a deployment at any state.

Deployment dependencies - startup ordering

When multiple services deploy together, Railway uses reference variables to determine the deploy order. A service that references another service waits for that service to finish deploying before it starts, so it never boots with a stale or missing value from a dependency.

For example, if your API service has DATABASE_URL=${{Postgres.DATABASE_URL}} referencing a PostgreSQL database, Railway will:

Deploy the Postgres service first
Then deploy the API service (since it has a reference variable to Postgres)

When ordering applies

Ordering takes effect when multiple deploys are triggered together as a batch:

Template deploys — deploying a stack of services at once.
Applying staged changes — for example, a variable edit that redeploys multiple services.
Duplicating an environment.
PR environments — services in an auto-created environment for a pull request.

When ordering does not apply

When services deploy independently, no ordering is performed:

GitHub push deploys — even in a monorepo where one push triggers multiple services, each service deploys independently.
Single-service redeploys — there is nothing to order against.

Transitive dependencies

Ordering follows the full chain of references. If service A references B and B references C, then A waits for both B and C to finish.

Circular references

If two services reference each other (for example, A references B and B references A), Railway breaks the cycle and deploys them in parallel rather than waiting indefinitely.