This document outlines the more advanced concepts of Railway. It covers things like build and deploy options, networking, integrations, and observability.
Out of the box, many defaults are applied to builds and deployments. However, there are several ways to tailor things to your project spec.
Railway uses Nixpacks to build and deploy your code with zero configuration. When your needs require adjustments to the defaults, we make it easy to configure things like install, build, and start commands.
Deployments are created with some default options that can be overridden. Some of the options available are -
- Replicas: By default, your deployment will go out with a single instance. With replicas, you have the ability to scale up your deployment instances.
- Deployment Region: Deployments are pushed to the
us-west1region unless a different region is specified.
- Scheduled Executions: Your deployment will be run once by default. If the service is intended to be a scheduled task of sorts, you can create a cron schedule.
- App Sleep: Services are serverful and always-on. You can control this behavior, to spin down resources when they're not being used, by enabling App Sleep.
Networking can be tricky and time-consuming. We wanted to provide the best-in-class experience when it came to wiring things up. There are two basic ways we accomplish this.
Private Networking is a feature within Railway that will open network communication through a IPv6 wireguard mesh only accessible to your Railway services within a project.
All projects have private networking enabled and services are assigned a DNS name under the
railway.internal domain. This DNS name resolves to the internal IPv6 address of the services in a project.
With the click of a button, Railway will expose your service to the internet and provide you with a domain. In order to make this work, you must configure your application appropriately to ensure we know the IP and port it is listening on. Instructions for how to do this can be found in the Public Networking guide.
If you have a custom domain, you can easily add it to your Railway service.
A CLI and API are available to wire your Railway projects into any workflow.
The Railway Command Line Interface (CLI) lets you interact with your Railway project from the command line, allowing you to do things like:
- Trigger deployments programmatically.
- Run services locally using environment variables from your Railway project.
- Create new Railway projects from the Terminal.
The Railway public API is built with GraphQL and is the same API that powers the Railway dashboard. Similar to the CLI, you can interact with your Railway project programmatically by communicating with the API.
Railway environments give you an isolated instance of all databases and services in a project. You can use them to
- Have development environments for each team member that are identical to the production environment
- Have separate staging and production environments
Within a service and environment, you can specify which branch to auto-deploy to that environment when a change is merged.
Any build or deployment logs emitted to standard output or standard error
( eg. console.log(...)) is captured by Railway so you can view or search for it later.
Logs for a specific service deployment are available from a service's view in your project, useful when debugging build or deployment failures.
Logs for all of the services in a project can be viewed together in our Observability tool within a project. This is useful for debugging more general problems that may span multiple services.
Edit this file on GitHub