Application configuration with environment variables

Divio Cloud projects allow you to maintain separate configuration for each of the Live, Test and Local environments.

Environment variables are dynamic values that can be used by the processes or applications running on the server. One of the advantages in using them is that you can isolate specific values from your codebase.

Environment variables are a good place for storing instance-specific configuration, such as Django settings that you don’t wish to hard-code into your project.

Cloud (Live and Test) environments

On Cloud sites, environment variables for a project are managed via the command line, or via the Control Panel. The variables for the Live and Test sites are wholly independent.

Via the command line

The Divio CLI allows you to set and check values from the command line with the divio project env-vars command, as long as you are within the path of the local version of the project. For example, to see the variables of the Live server:

divio project env-vars -s live

If any exist, they will be displayed thus:

Key                  Value
-------------------  -------
SECURE_SSL_REDIRECT  True

See the divio project env-vars reference for more.

Via the Control Panel

In the project, select Environment Variables. Enter the keys and values, and Save.

'Managing environment variables'

Local environment

Your local site also uses environment variables, contained in the .env-local file.

By default these are:

DEBUG=True
STAGE=local
DATABASE_URL=postgres://postgres@postgres:5432/db

Formatting

Lines should not contain spaces or quotation marks (see Docker’s documentation).

Environment variables and Django settings

As you can see from the local environment examples above, environment variables can also be used to apply Django settings, such as DEBUG.

To access the environment variable in your own Python code, you could use something like this:

import os
my_variable = os.environ.get('MY_ENVIRONMENT_VARIABLE')

It’s important to note that if your variable represents anything other than a string, you will need to interpret the variable appropriately, as os.environ.get will only return a string.

You can also use env() (from the getenv package), which will parse the variable as Python code.

Where and when environment variables are applied

Environment variables should apply only to environments, and not to states or processes that are independent of a particular environment.

  • When a project is running, it runs in a particular environment, so you can expect environment variables to apply.
  • When a project is being built (i.e. in the deployment phase), it should not be subject to any particular environment conditions. Even Django operations that take place during deployment (such as collectstatic) should be environment-agnostic - under all environment conditions, you should expect the same result from collectstatic.

Forcing environment variables in the build phase

Though it’s not generally recommended, if for some reason you need to specify environment variables in the build phase, you can provide them in the Dockerfile, with:

RUN <key>=<value> <command>

For example:

RUN SOMEVAR=some_value ./manage.py collectstatic

However, it’s usually better to find another solution.

Commonly-used environment variables

Many of the applications packaged for Divio Cloud deployment recognise a number of environment variables for your convenience.

See Key Divio Cloud addons for lists of settings that can be provided as variables in some Divio Cloud addons.

They do this in their Application configuration with aldryn_config.py files. To see precisely how they are handled, refer to the aldryn_config.py file of key addons (important: make sure you are looking at the correct version of the addon, as different versions of the packages will assume different variables and settings):

Our uWSGI application gateway also recognises environment variables that commence UWSGI_.