Environment Variables

User Managed Variables

Coherence provides a UI for managing environment variables that will be configured for your application. These variables are stored in cloud secrets manager in your cloud (Coherence does not store a copy of them) and cloud integrations into build pipelines and container runtimes are used in order to make them available to your code in the most secure manner possible. This gives you a developer-friendly way to use your cloud secrets manager in all the different contexts you need to, in a developer-friendly way.

Environment Inheritance

There are 2 places that you can configure variables in the Coherence UI:

• The "Variables" tab in Preview/Production: these variables will be inherited by all environments in that cloud project (for example the variables in the "Peview" project will be available in all Branch Previews by default)
• The environment's "Variables" tab: these will only apply to the environment they are configured on. You can also override inherited variables

Nested Variables

We currently do not support reference of one variables from the value of another (you cannot use $VAR1) in the value of VAR2. If you have a use case that requires this, let us know and we will help you find a solution!

• One workaround is the option to set environment in your build or prod command, e.g. doing ["ENV2=foo_${ENV1} yarn", "build"] instead of ["yarn, "build"].
• You can also use docker build-arg's (see below) to alias variables for your service by doing something like ENV VAR2=$VAR1 in the Dockerfile.

Coherence Managed Variables

There are different kinds of environments that Coherence will execute your application under. It is important to distinguish between them for various purposes such as connecting to a database or generating appropriate URLs within your application (e.g. for the frontend to talk to the API). These environments are:

• Development (A Workspace/Cloud IDE)
• CI/CD when building a frontend service's resources
• CI/CD when executing a service's test command
• A deployed cloud environment (either a branch preview environment, or a production environment)

In each environment, Coherence auto-populates several environment variables.

• COHERENCE_DEV will be set to true when running in a Workspace
• COHERENCE_CI will be set to true when running in a CI Pipeline
• COHERENCE_TEST will be set to true when running a service's test commands in CI/CD
• COHERENCE_ENVIRONMENT_NAME will be set to the name of the environment in all environments
• COHERENCE_ENVIRONMENT_DOMAIN will be set to the URL of the running environment in Development and in a deployed cloud environment
• COHERENCE_BUILD_SHA will be set to the full git SHA of the commit being built in a CI pipeline. This includes passing as a build-arg to docker build
• If a custom domain is set up for an environment, COHERENCE_CUSTOM_DOMAIN will also be present and set to the environment's custom domain.

Additionally, based on the configuration of your application in coherence.yml, environment variables relevant to accessing these resources are injected into the running application by Coherence. These can be found on the Variables tab of each environment in coherence, and will be in the Auto-generated section:

Within this section the workspace variables will be present in a development environment, and the environment variables will be present in a cloud deployment.

Build Args for Docker Builds

All environment variables that apply to a service will be added as build-arg's (docs) to the docker build command for that service's container.

• As per the docker docs, you'll need to add the ARG commands to your dockerfile for them to be made available in your build.