Environment Variables

This page outlines the Environment Variables available to Runway services.

We differentiate between two types of environment variables: Platform Variables and Service Variables.

Constraints

Environment variables cannot use the same name as secrets, otherwise an overlap error will be raised.

Platform Variables

Platform Variables are defined by the platform, i.e. Runway. They can be dynamic, e.g. holding information about the region in which the application is running.

Cloud Run

Runway uses Cloud Run to execute services, which define a few environment variables. Most notably:

PORT

The port your HTTP server should listen on.

Reference: https://cloud.google.com/run/docs/container-contract#env-vars

Runway

Runway defines the following Platform Variables:

RUNWAY_REGION

The GCP region in which the application is running, e.g. us-east1.

Service Variables

Service Variables can be set in two ways: by adding a YAML file to your repository, and by adding a secret to Vault.

Repository

Environment variables are defined in two deployment environment specific YAML files:

.runway/env-production.yml for the “Production” environment.
.runway/env-staging.yml for the “Staging” environment.

WARNING: Do not store secrets as plain text in your repository. See Exposing Secrets to a Runway Service for guidance on storing and accessing secrets.

Format

Environment variables must be represented as double-quoted strings in YAML, e.g. "staging", "8080", "true", etc. Environment variables must be use KEY: VALUE convention, e.g. FOO: "BAR".

Example: The following file configures the environment variable EXAMPLE_API_URL for the “Staging” environment of a service.

---
EXAMPLE_API_URL: "https://example.com/api/v1"

Note: To set the same value in the “Production” environment, possibly to a different value, use the .runway/env-production.yml file.

Changes

Service Variables are coupled with a deployment. That means that any changes to environment variables will only take effect after a deployment.