Containers Guide
By now you should have a good understanding of which services (and repositories) are required to successfully model your services in Release. For each of these services, we recommend running through the following steps:
  • Creating a Dockerfile to create a container
  • Creating a docker-compose to run the container
  • OR Creating each of an Application and Environment Variables Template file in your repository(ies)
Every application is different enough that we cannot give you pre-canned files to use here, we can at least walk you through what this would look like at a high level.


To run services that are not static in Release they need to be run within containers. This means writing a “Dockerfile”, a set of instructions on how to build your service within a container. There’s many great resources available to help you write dockerfiles, such as:
To have the best experience in Release, your resulting containers should:

Be Isolated

This means a container should contain everything required to run. A common pattern for people using containers for development is to mount files from the local filesystem into the container to make it function. For Release to work it needs to be possible to bring up a container with no references to local files. This means it should build everything required inside the container.

Be Configurable

In Release you’ll find yourself using the same container image in multiple environments. That means you need to have the ability to pass in configuration information, such as the hostname of the generated database to use, for example.

Environment Variables

Traditionally this is done through “environment variables”, key value pairs set within a UNIX shell. An example of this might be:
DATABASE_HOST=<generated hostname>

Environment Files

We support environment variables as the primary way to pass in configuration. Some frameworks and systems will automatically look for and apply environment variables, but in some cases you may have to:
  1. 1.
    Change your source code to look for environment variables and fall back to defaults if not found.
  2. 2.
    Write an / wrapper script that runs whenever your container starts, this then writes any required configuration files to the container and starts your service.


Secrets should never be checked into your source control (except in rare cases where you can encrypt them securely). Release offers a very powerful way to input secrets into your Environment Variables Template and this ensures that secrets are encrypted at rest and “in flight” during setup.
Alternatively, since Release runs in your own cloud provider account, you also have the option of writing code to integrate with your cloud-native services secrets manager(s), or use an open source or managed service such as Vault.


Your service needs to be “aware” of its surroundings and be able to “change its spots” during execution of the code under different circumstances and in different environments. The methods to do this are as various as the applications and developers who write them.
One final tip: If you’re using an off the shelf framework (django, rails, nextJS), someone has already solved every problem you will ever encounter in docker, you can google your way out of almost any common issue!

Docker Compose

Once you have a working dockerfile, we recommend building a “docker compose file” as the next step. This is a built-in orchestration tool provided by Docker, and allows you to model out multiple containers to be brought up in specific orders. A typical example would be a “django backend” that requires redis and postgres to operate properly.
You would write a docker-compose.yaml that brings up all three services, and provides the environment variables necessary to start the django backend configured to talk to the other two services.
There are multiple tutorials walking through docker compose, such as:
The benefit of writing a docker-compose file will become apparent when we reach the creating an application stage in Release. We’ll scan your git repository and if we find a docker-compose we’ll automatically model out all those services by default, saving time later in the process. (Plus, it's nice to be able to test your application locally with a single command!)
Similar to the dockerfile, you need to make sure the final docker compose configuration is completely self contained and doesn’t mount files or import anything external, as we’re going to use this to create isolated environments later.

Release Application and Environment Variables Templates

Alternatively, if you are an advanced user or if you are already familiar with Release, you can create and/or copy both an Application Template and an Environment Variables Template yaml file into your repository(ies) and Release will pull those in automatically during the scan process. If you have GitOps enabled, the whole process will be completely automated upon every checkin of your code base as well. You can read more about these details in our documentation.