Environment Variables

The environment should be used to configure your application. When your project is deployed and a new container is started, all the variables defined in your environment are automatically injected into it.

Variable Alias

You can define aliases of environment variables:

For example:

  • DATABASE_URL=$SCALINGO_MONGO_URL

In this case the DATABASE_URL becomes an alias of SCALINGO_MONGO_URL value.

Good Practices

Using the environment to configure your application is one of twelve good practices defined in the 12-factor.

You should avoid writing any credentials in the files managed by Git (example: .env files).

Accessing the Environment from your App

The following example is to get the value of the PORT variable.

Ruby

ENV["PORT"]

Go

os.Getenv("PORT")

JavaScript

process.env.PORT

Python

os.getenv("PORT")

PHP

$_ENV["PORT"]

Java

System.getenv("PORT");

Other Languages

The process should not be really different. Refer to the documentation of the standard library of your language.

Multi-Lines Environment Variable

The current web dashboard does not handle well the configuration of an environment variable which spans on multiple lines. There is a couple of workaround you could use to circumvent this limitation.

A first solution is to define this environment variable using our CLI. For instance, if the content of the environment variable is the content of a file:

scalingo --app my-app env-set "MY_VAR=$(cat fichier.key)"

The con of this solution is that the web dashboard becomes unusable to edit environment variables because of this multi-lines variable. If you want to still be able to use the web dashboard to manage your environment variable, the solution is to encode your multi-lines environment variable in Base64, then decode it in your application. First, set the environment variable in Base64:

scalingo --app my-app env-set "MY_VAR=$(cat fichier | base64 -w 0)"

You can now read the content of this environment variable in your application by decoding the content of the variable. For instance, in PHP:

base64_decode($_ENV["MY_VAR"])

Most programming languages offer a way to decode a Base64 content.

Build Environment Variables

When your application is deployed, the build container is containing the environment variables defined in the application configuration and the platform is also injecting the following variable:

  • SOURCE_VERSION: SHA of the currently deployed Git commit.
  • APP: Name of the application the build has been triggered for.

Runtime Environment Variables

When an application container is started, the platform is using the environment variables defined in the application configuration but is also injecting a set of environment variables in its environment. In the case of web containers, an additional variable $PORT is defined.

  • PORT: Port number your server has to bind on.
  • CONTAINER: Type and index of the container, web-1 or worker-1 for instance
  • CONTAINER_VERSION: Version of the container started, usually the Git commit SHA.
  • CONTAINER_SIZE: Name of the size of the container M, L, XL etc.
  • CONTAINER_MEMORY: Available RAM memory of the container (in bytes)
  • APP: Name of the application deployed
  • HOSTNAME: Alias for APP
  • STACK: Name of the stack the application deployed is using
  • REGION_NAME: Name of the region where the application is deployed

One-Off Environment Variables

When starting a one-off container for an application, the platform injects the runtime environment variables plus the following:

  • SCALINGO_USER_ID: Scalingo user ID of the user executing the one-off.

Suggest edits

Environment Variables

©2024 Scalingo