Variables
Service variables are provided whenever you build, deploy, or run railway run
.
Together these variables form your Railway environment. Each
database service provides the necessary environment variables needed to use it (such as
DATABASE_URL
for the PG plugin). You can also specify custom variables on the
project variables page.
You can view all variables for the current environment with railway vars
and change the environment with railway environment
.
RAW Editor
Chances are you might already have a .env
file laying around. You can import your existing environment variables via the RAW Editor.
You can click the RAW Editor
link to open up a modal where you can paste in a list of variables separated by new line. This also allows you to bulk edit your variables in a familiar way like you would an .env
file or even edit them via JSON notation.
Automatic Detection of Environment Variables
If you initialize a new project from the CLI- and an .env file is detected, Railway will prompt to see if you'd like to import it into your new project.
Multiline Variables
Railway supports multiline variables/object variables. Just type or paste in the value as you would normally.
Railway-Provided Variables
Railway provides the following additional system environment variables to all builds and deployments.
Name | Description |
---|---|
RAILWAY_STATIC_URL | The public domain, of the form example.up.railway.app |
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 |
RAILWAY_HEALTHCHECK_TIMEOUT_SEC | The timeout length (in seconds) of healthchecks. Example: 300 |
RAILWAY_ENVIRONMENT | The railway environment for the deployment. Example: production |
Templated Variables
Variables can reference other variables using the ${{ MY_VAR }}
templating
syntax. This can help reduce duplication if you need the same value in more than
one variable, or need to present a plugin-provided variable differently.
Construct "Meta" Variables
If you find yourself needing the same value in more than one place, you can create a template to avoid duplication. The following example constructs a URL from an AWS S3 configuration:
"Rename" Plugin Variables
Railway plugins provide a fixed set of variables. If your application requires a variable to be under different name, create a new custom variable that uses a template to reference the original:
Shared Variables
To reduce duplication of variables across multiple services within the same projects, shared variables can be created at the environment level and referenced by the services that need it. Creation of shared variables can be done via Project Settings.
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.
Edit this file on GitHub