Default environment variables
How to create and manage default environment variables for your Release environments
Environment variables hold the environment-specific information that an application needs at runtime.
For instance, a web application deployed in a production environment has to know how to access the production database. The same application running in a staging environment would have to know about a staging database instead.
By storing configuration as environment variables instead of in code, you'll make your applications portable, secure, and easy to deploy on Release environments.
When you create a new application, Release generates a default environment variables file, based on your code.
For example, if your repository has a
docker-compose.yml
file, Release will populate the default environment variables for your new application based on the environment variables in that file.If your repository does not have a
docker-compose.yml
file, you can create your Release application's default environment variables manually, by editing your application's settings.To edit the default environment variables for an application, visit the application's App Settings page, then click the Edit button in the “Default Environment Variables” section.

Edit the default environment variables
This opens a YAML editor, which you can use to edit your default environment variables file.
A Release application's default environment variables file is formatted in YAML, and consists of three sections:
Section | Type | Required | Description |
---|---|---|---|
Hash | false | ||
Array | true | Default environment variables for your app | |
Hash | false | Service-specific environment variables |
Here's an example of a default environment variables file:
mapping:
COMMIT_HASH: RELEASE_COMMIT_SHA
AWS_REGION: RELEASE_CLUSTER_REGION
defaults:
- key: DEFAULT_LANG
value: en
- key: DB_HOSTNAME
value: db
services:
admin:
- key: DB_USERNAME
value: admin_rw
- key: DB_PASSWORD
secret: true
frontend:
- key: DB_USERNAME
value: user_ro
- key: DB_PASSWORD
secret: true
Environment variables consist of a key, a value, and an optional
secret
flag. Mark an environment variable as secret using secret=true
. Secrets are encrypted at rest in a vault and hidden in the UI. You may also import secret environment variables from external secrets managers. See the instructions here for more on secrets.Field | Type | Required | Description |
---|---|---|---|
key | String | True | The environment variable's name.
It is convention to use uppercase names for environment variables.
Example: DB_USERNAME |
value | String or Null | True | The value for this environment variable.
Required if secret is false .
If secret is true , this field is optional, and Release defaults to the previously saved value if this field is omitted. |
secret | Boolean | False |
Here's an example of three environment variables:
defaults:
- key: DEFAULT_LANG
value: en
- key: DB_HOSTNAME
value: db
- key: DB_PASSWORD
value:
secret: true
When you create a new environment, Release uses the application's default environment variables file to generate an environment-specific environment variables file for your new environment.
Think of an application's default environment variables file as the blueprint for each new environment's environment variables.
Apart from the environment variables lifted from your
docker-compose.yml
, and the variables you created yourself, Release provides additional environment variables.You can map Release's environment variables to your app's environment variable names so that you do not need to change your application's code when deploying on Release or elsewhere.
Environment variables provided by Release have names that start with
RELEASE_
.Here's an overview of the variables provided by Release:
Release account ID: Each Release account has a unique numerical identifier.
Release application name: Each Release application has a unique string identifier.
Git branch: The name of the git branch from your repository deployed to this environment.
Release build ID: Each Release build has a unique numerical identifier.
Cloud provider: The cloud provider that hosts this environment. For example,
aws
or gcp
.Cloud provider region: The cloud provider region for this environment. For example,
us-west-2
or us-east-1
.Git hash: The SHA hash of the git commit deployed in this environment. This refers to a commit in your repository.
Short git hash: The short hash of the git commit deployed in this environment. This refers to a commit in your repository.
Release context: Refers to the Kubernetes context for this deployment.
Release domain: If you do not have a custom domain set up on your Release account, this will be
rls.sh
.Release environment ID: Each Release environment has a unique string identifier.
Release random string: This short random string is used to create unique links.
Release also provides environment variables specific to each service in your environment.
When creating these variables, Release converts the service name to uppercase and prepends this to each service-specific environment variable's name.
For example, if you have two services,
admin
and frontend
, Release provides environment variables as follows:Short git hash: The SHA hash of the git commit deployed for this service. This refers to a commit in your repository.
Short git hash: The short hash of the git commit deployed for this service. This refers to a commit in your repository.
Ingress hostname: The hostname of the instance/load balancer for this service, accessible to the internet.
Ingress URL: The public URL for this service.
The equivalent environment variables are provided for the
frontend
service in this example.You can use the
mapping
section to map existing environment variables to new environment variables.By mapping Release's environment variables to your app's environment variables, you do not need to reference Release-specific environment variable names in your code.
In the example below, your code expects an environment variable called
AWS_REGION
. Mapping allows you to pass RELEASE_CLUSTER_REGION
to your application, adding its value to a new environment variable called AWS_REGION
.mapping:
COMMIT_HASH: RELEASE_COMMIT_SHA
AWS_REGION: RELEASE_CLUSTER_REGION
REACT_APP_ADMIN_BASE_URL: ADMIN_INGRESS_URL
REACT_APP_FRONTEND_BASE_URL: FRONTEND_INGRESS_URL
The
mapping
section also allows you to reference your app's environment variables. In the example below, REACT_APP_ADMIN_PATH
gets its value from DEFAULT_ADMIN_PATH
:defaults:
- key: DEFAULT_ADMIN_PATH
value: /admin/
mapping:
REACT_APP_ADMIN_BASE_URL: ADMIN_INGRESS_URL
REACT_APP_ADMIN_PATH: DEFAULT_ADMIN_PATH
Release's
mapping
section allows you to create new environment variables through string interpolation.In the example below,
ADMIN_FULL_URL
is created by concatenating ADMIN_INGRESS_URL
and DEFAULT_ADMIN_PATH
:defaults:
- key: DEFAULT_ADMIN_PATH
value: /admin/
mapping:
ADMIN_FULL_URL: "${ADMIN_INGRESS_URL}${DEFAULT_ADMIN_PATH}"
You can also provide default values if an environment variable is unset or empty.
In the example below, if
MAYBE_EMPTY_BASE_URL
does not exist, or is empty, the default https://example.com
will take its place.mapping:
ADMIN_FULL_URL: "${MAYBE_EMPTY_BASE_URL:-'https://example.com'}/admin/"
The syntax to indicate a default is based on parameter expansion in bash:
${parameter:-defaultvalue}
, but unlike in bash, defaultvalue
is interpreted as a string. defaultvalue
can't reference an environment variable.String interpolation and parameter expansion is limited to the
mapping
section of your environment variables YAML.The
defaults
section contains environment variables that are available to all services in an environment.Here's an example of the defaults section:
defaults:
- key: DEFAULT_LANG
value: en
- key: DB_HOSTNAME
value: db
Use the
services
section to define environment variables for specific services only. Each service in this section has one or more environment variables.Here's an example of service-specific environment variables:
services:
admin:
- key: DB_USERNAME
value: admin_rw
- key: DB_PASSWORD
secret: true
frontend:
- key: DB_USERNAME
value: user_ro
- key: DB_PASSWORD
secret: true
Last modified 1mo ago