Variables

Variables provide a powerful way to manage configuration and secrets across services in Railway.

How it Works

When defined, variables are made available to your application as environment variables 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

In Railway, there is also a notion of configuration variables which allow you to control the behavior of the platform.

Template Syntax

Railway's templating syntax gives you flexibility in managing variables:

  • NAMESPACE - The value for NAMESPACE is determined by the location of the variable being referenced. For a shared variable, the namespace is "shared". For a variable defined in another service, the namespace is the name of the service, e.g. "Postgres" or "backend-api".
  • VAR - The value for VAR is the name, or key, of the variable being referenced.

You can also combine additional text or even other variables, to construct the values that you need:

Types of Variables

In Railway, there is a notion of service variables, shared variables, reference variables, and a few kinds of reserved variables.

Service Variables

Service variables are scoped to a specific service. They can be referenced in other services by using a Reference Variable.

Shared Variables

Shared variables are scoped to a project and environment. They help reduce duplication of variables across multiple services within the same project.

Reference Variables

Reference variables are those defined by referencing variables in other services, shared variables, or even variables in the same service. This is useful for ease of maintenance, allowing you to set a variable in a single place and reference it as needed.

Reference variables use Railway's template syntax.

Railway-Provided Variables

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

NameDescription
RAILWAY_PUBLIC_DOMAINThe public service or customer domain, of the form example.up.railway.app
RAILWAY_PRIVATE_DOMAINThe private DNS name of the service.
RAILWAY_TCP_PROXY_DOMAIN(see TCP Proxy for details) The public TCP proxy domain for the service, if applicable. Example: roundhouse.proxy.rlwy.net
RAILWAY_TCP_PROXY_PORT(see TCP Proxy for details) The external port for the TCP Proxy, if applicable. Example: 11105
RAILWAY_TCP_APPLICATION_PORT(see TCP Proxy for details) The internal port for the TCP Proxy, if applicable. Example: 25565
RAILWAY_PROJECT_NAMEThe project name the service belongs to.
RAILWAY_PROJECT_IDThe project id the service belongs to.
RAILWAY_ENVIRONMENT_NAMEThe environment name of the service instance.
RAILWAY_ENVIRONMENT_IDThe environment id of the service instance.
RAILWAY_SERVICE_NAMEThe service name.
RAILWAY_SERVICE_IDThe service id.
RAILWAY_REPLICA_IDThe replica ID for the deployment.
RAILWAY_DEPLOYMENT_IDThe ID for the deployment.
RAILWAY_SNAPSHOT_IDThe snapshot ID for the deployment.
RAILWAY_VOLUME_NAMEThe name of the attached volume, if any. Example: foobar
RAILWAY_VOLUME_MOUNT_PATHThe mount path of the attached volume, if any. Example: /data
RAILWAY_RUN_UIDThe UID of the user which should run the main process inside the container. Set to 0 to explicitly run as root.

Git Variables

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

NameDescription
RAILWAY_GIT_COMMIT_SHAThe git SHA of the commit that triggered the deployment. Example: d0beb8f5c55b36df7d674d55965a23b8d54ad69b
RAILWAY_GIT_AUTHORThe user of the commit that triggered the deployment. Example: gschier
RAILWAY_GIT_BRANCHThe branch that triggered the deployment. Example: main
RAILWAY_GIT_REPO_NAMEThe name of the repository that triggered the deployment. Example: myproject
RAILWAY_GIT_REPO_OWNERThe name of the repository owner that triggered the deployment. Example: mycompany
RAILWAY_GIT_COMMIT_MESSAGEThe 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.

NameDescription
RAILWAY_DEPLOYMENT_OVERLAP_SECONDSHow long the old deploy will overlap with the newest one being deployed, its default value is 20. Example: 0
RAILWAY_DOCKERFILE_PATHThe path to the Dockerfile to be used by the service, its default value is Dockerfile. Example: Railway.dockerfile
NIXPACKS_CONFIG_FILEThe 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_SECThe timeout length (in seconds) of healthchecks. Example: 300

Support

For information on how to use variables refer to the Variables guide.


Edit this file on GitHub