Variables

Service variables are provided whenever you build, deploy, or run railway run. When defined, they are made available to your application at runtime as environment variables.

Variables are made available in the following scenarios:

• The build process for each service deployment.
• The running service deployment.
• The command invoked by railway run <COMMAND>
• The local shell via railway shell

Defining Variables

Variables can be added via the Railway Dashboard by navigating to a service's "Variables" tab.

You can view all variables for the current environment using the Railway CLI with railway variables and change the environment with railway environment.

Raw Editor

If you already have a .env file, or simply prefer to edit text, the Raw Editor can be used to edit variables in either .env or .json format.

Variables can be defined as simple key/value pairs or as Templated Variables (eg. ${{Postgres.DATABASE_URL}}), which can dynamically reference other variables, shared variables, or plugin variables (more on this below).

Multiline Variables

Variables can span multiple lines. Press Control + Enter (Cmd + Enter on Mac) in the variable value input field to add a newline, or simply type a newline in the Raw Editor.

Railway-Provided Variables

Railway provides the following additional system environment variables to all builds and deployments.

Name	Description
RAILWAY_PUBLIC_DOMAIN	The public service or customer domain, of the form example.up.railway.app
RAILWAY_PRIVATE_DOMAIN	The private DNS name of the service.
RAILWAY_TCP_PROXY_DOMAIN	(Beta-only; see TCP Proxying for details) The public TCP proxy domain for the service, if applicable. Example: roundhouse.proxy.rlwy.net
RAILWAY_TCP_PROXY_PORT	(Beta-only; see TCP Proxying for details) The external port for the TCP Proxy, if applicable. Example: 11105
RAILWAY_TCP_APPLICATION_PORT	(Beta-only; see TCP Proxying for details) The internal port for the TCP Proxy, if applicable. Example: 25565
RAILWAY_PROJECT_NAME	The project name the service belongs to.
RAILWAY_PROJECT_ID	The project id the service belongs to.
RAILWAY_ENVIRONMENT_NAME	The environment name of the service instance.
RAILWAY_ENVIRONMENT_ID	The environment id of the service instance.
RAILWAY_SERVICE_NAME	The service name.
RAILWAY_SERVICE_ID	The service id.
RAILWAY_REPLICA_ID	The replica ID for the deployment.
RAILWAY_DEPLOYMENT_ID	The ID for the deployment.
RAILWAY_SNAPSHOT_ID	The snapshot ID for the deployment.
RAILWAY_VOLUME_NAME	The name of the attached volume, if any. Example: foobar
RAILWAY_VOLUME_MOUNT_PATH	The mount path of the attached volume, if any. Example: /data

Git Variables

These variables are provided if the deploy originated from a GitHub trigger.

Name	Description
RAILWAY_GIT_COMMIT_SHA	The git SHA of the commit that triggered the deployment. Example: d0beb8f5c55b36df7d674d55965a23b8d54ad69b
RAILWAY_GIT_AUTHOR	The user of the commit that triggered the deployment. Example: gschier
RAILWAY_GIT_BRANCH	The branch that triggered the deployment. Example: main
RAILWAY_GIT_REPO_NAME	The name of the repository that triggered the deployment. Example: myproject
RAILWAY_GIT_REPO_OWNER	The name of the repository owner that triggered the deployment. Example: mycompany
RAILWAY_GIT_COMMIT_MESSAGE	The message of the commit that triggered the deployment. Example: Fixed a few bugs

User-Provided Configuration Variables

Users can use the following environment variables to configure Railway's behaviour.

Name	Description
RAILWAY_DEPLOYMENT_OVERLAP_SECONDS	How long the old deploy will overlap with the newest one being deployed, its default value is 20. Example: 0
RAILWAY_DOCKERFILE_PATH	The path to the Dockerfile to be used by the service, its default value is Dockerfile. Example: Railway.dockerfile
NIXPACKS_CONFIG_FILE	The path to the Nixpacks configuration file relative to the root of the app, its default value is nixpacks.toml. Example: frontend.nixpacks.toml
RAILWAY_HEALTHCHECK_TIMEOUT_SEC	The timeout length (in seconds) of healthchecks. Example: 300
RAILWAY_REGION	(Beta-only; see Regions for details) The name of the region to be used for the deployment. Example: europe-west4 available options

Reference Variables

Variables can use the ${{VAR}} or ${{NAMESPACE.VAR}} syntax to reference other service variables, shared variables, or plugin variables.

The Railway dashboard provides an autocomplete dropdown in both the name and value fields to help create these references.

You can also reference the Railway provided variables of other services. For example, in your "frontend" service you can create the variable

and then use it to make requests to your backend. This prevents the need to hardcode the URL in your frontend code.

Plugin Variables

Railway plugins offer a number variables that can be referenced by Railway services. To include a plugin variable, create a reference to the variable using the ${{<PLUGIN_NAME>.<VARIABLE_NAME>}} syntax.

NOTE: Railway's autocomplete will help create these references so you don't need to remember the exact syntax.

Shared Variables

Shared variables help reduce duplication of variables across multiple services within the same project. They are defined at the project environment level and can be added in Project Settings > Shared Variables.

To use a shared variable, either click the Share button and select the desired services, or visit the Variables tab within the service itself and click "Insert Shared Variable".

Under the hood, adding a shared variables to a service creates a new variable that references the shared variable using Railway's templating syntax (eg. NAME=${{shared.NAME}}). This means that shared variables can be combined with additional text or even other variables, like the following examples illustrate.

Import Variables from Heroku

You can import variables from an existing Heroku app using the command palette on the service variables page. After connecting your Heroku account you can select any of your Heroku apps and the config variables will be added to the current service and environment.

Service Discovery

You can reference other services' public URL via a service variable. Use RAILWAY_SERVICE_{ServiceName}_URL to get the public URL of a service within your project. For example, if you have a service named Backend API, you can reference it from another service by using RAILWAY_SERVICE_BACKEND_API_URL.