Service Deployments are attempts to build and deliver your application.
All deployments will appear in the deployments view on your selected service. Clicking on the deployment will bring up the build and deploy logs. Each deploy has the option to configure a a Railway provided domain as well as attaching a custom domain.
Deployments can be in any of the following states:
Every Deployment in Railway begins as
Initializing - once it has been accepted into our build queue, the status will change to
While a Deployment is building, Railway will attempt to create a deployable Docker image containing your code and configuration (see Builds for more details).
Once the build succeeds, Railway will attempt to deploy your image and the Deployment's status becomes
Deploying. If a healthcheck is configured, Railway will wait for it to succeed before proceeding to the next step.
If an error occurs during the build or deploy process, the Deployment will stop and the status will become
Once the Deployment is live and running, the status will change to
Success. A Deployment will remain in this state unless it crashes, at which point it will become
When a new Deployment is triggered, older deploys in a
Success state are eventually removed - first having their status updated to
Removing before they are finally
Removed. Deployments may also be removed manually.
If you get a Bad Gateway when you attempt to visit the deployment URL, it could
be that your
PORT variable is misconfigured. Railway needs an explicit port to
listen on to expose the application to the internet. You can provide a
variable under the Variables page in your project. For more information, see Exposing Your App.
You can configure additional deployment triggers such as when a new PR is created using the GitHub Trigger's integration.
A start command is the process used to run a Deployment's code. For example, a Python project may have a start command of
python main.py, or a NodeJS project may have a start command of
npm run start.
Railway automatically configures the start command based on the code being deployed. If your code uses a Dockerfile, the start command defaults to the ENTRYPOINT and/or CMD defined in the Dockerfile. Otherwise, the buildpack used to create the image will determine the start command - see Builds for more details.
Start commands may be overridden for advanced use-cases such as deploying multiple projects from a single monorepo.
When specifying a start command, the behavior of the image depends on type of build:
- Dockerfile: the start command overrides the Docker image's ENTRYPOINT in exec form
- Buildpack: the start command is inserted as a buildpack launch process
The root directory defaults to
/ but can be changed for various use-cases like monorepo projects. When specified,
all build and deploy commands will operate within that root directory. Additionally, files changed outside the root directory will not
trigger a new build.
Watch paths are gitignore-style patterns that can be used to trigger a new deployment based on what file paths have changed.
For example, a monorepo might want to only trigger builds if files are changed in the
/packages/backend directory. When specified, any changes that don't match
the patterns will skip creating a new deployment. Multiple patterns can be combined, one per line.
Note, if a Root Directory is provided, patterns still operate from
/. For a root directory of
/app/**.js would be used as a pattern to match files in the new root.
Here are a few examples of common use-cases.
Note, negations will only work if you include files in a preceding rule.
By default, Railway maintains only one deploy per service.
Users can rollback to previous deploys if mistakes were made. A deployment rollback will revert to the previously successful deployment. Both the Docker image and custom variables are restored during the rollback process.
To perform a rollback, click the three dots at the end of a previous deployment, you will then be asked to confirm your rollback.
Railway allows users to see running logs of your application to help with monitoring. Railway displays the last 10,000 lines of logs available for a deployment.
We maintain logs for inactive deployments as well as active. Under the logs pane, you can search within your logs for certain keywords.
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.
If a deployment is completed, you can delete a live deploy by clicking the the three dots at the end of the deployment tab and select Remove. This will remove the deployment and stop any further project usage.
Restart a Crashed Deployment
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
Railway automatically restarts crashed Deployments up to 10 times. After this limit is reached, your deployment status is changed to
Crashed and notifying webhooks & emails are sent to the project's members.
You can 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
You can also click within a deployment and using the Command Palette restart a deployment at any state.
Configurable Restart Policy
Within the Service settings, a user is able to configure a restart policy of either
On-Failure with an optional maximum number of restarts.
How come my GitHub PR wont deploy?
Railway will not deploy a PR branch from a user who is not in your team or invited to your project without their associated GitHub account.
Edit this file on GitHub