Build arguments
Docker build arguments and static service environment variables
Last updated
Was this helpful?
Docker build arguments and static service environment variables
Last updated
Was this helpful?
Build arguments are key-value pairs that are used to initialize a build with either docker-compose or static service environment variables. A static service is any service that doesn't require a container. Visit for more details.
Build arguments can be global and used for all your applications, or specific to a single application.
You can add global build arguments to your global Configuration under the Builds tab. Add secret environment variables only relevant to a single application to App Settings in the "Advanced Settings" section to prevent exposing them to other containers.
Navigate to Configuration. Select Build Arguments.
An example use case for global build arguments is an API key for a static build.
Environment variables and environment-specific variables are not accessible in the docker build step, so you need to use build arguments as explained in this guide.
In Docker, regular build arguments using the ARG=SOMEVAL format are stored in the Docker image and can be retrieved if someone has access to your image or repository. This may not be a problem for private images unless you store private keys or sensitive information that should not be exposed, even internally.
To safely access secrets in Docker builds, Release recommends using Docker secrets. To access the secret, you need to make some changes to your Dockerfile.
Now change it to look like this:
Navigate to the Settings tab within an application. Select Build Arguments. The application-specific build arguments will override the account-wide build argument settings.
Notice how USERNAME is inherited from the account-level build arguments, while API_TOKEN is overridden by this application.
Read about how secrets are referenced from SSM or the Release Secrets Manager in .
You can enter your secret directly as a string (Release stores all values encrypted in the database for you), but it's preferable to create a secret or use an existing secret in one of the supported . Secrets stored in secrets managers cannot be retrieved from the UI, which adds a layer of security over your secrets.
(Optional) In some cases, startup scripts can automatically read build arguments as environment variables if you use the _FILE convention. In this from Docker, the startup script knows to access the value of API_TOKEN from the file location pointed to by API_TOKEN_FILE. However, this convention only applies under certain circumstances, so be sure to check if it will work in your case.
