> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/account-settings/build-settings/build-args.md).

# Build arguments

Docker build arguments and static service environment variables

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 [our guide to static service deployment](https://docs.releaseapp.io/static-service-deployment) 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.

## Add account-level build arguments

Navigate to **Configuration**. Select **Build Arguments**.

![Build Arguments Setting](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-44c407f8aee4eefdb4284e10909a41397e49532b%2Fbuild-args.png?alt=media)

An example use case for global build arguments is an API key for a static build.

## Using secrets as build arguments

{% hint style="success" %}
Read about how secrets are referenced from SSM or the Release Secrets Manager in [Secrets vaults](/reference-documentation/environment-settings/environment-specific-environment-variables/secrets.md#referencing-cloud-secrets).
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

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.

* [ ] 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 managers](/reference-documentation/environment-settings/environment-specific-environment-variables/secrets.md). Secrets stored in secrets managers cannot be retrieved from the UI, which adds a layer of security over your secrets.
* [ ] Click the padlock icon to convert the secret or secret reference to a Docker secret. Release will mount the value at a file location you can specify later.
* [ ] The Docker secret will be available with the same ID as the key you specified, and will be mounted under `/var/secrets/ID` in the file system. For example, in your Dockerfile, locate your build argument access code, which will look something like this:

```docker
ARG API_TOKEN
RUN API_TOKEN=$API_TOKEN start_server.sh
```

Now change it to look like this:

```docker
RUN --mount=type=secret,id=API_TOKEN API_TOKEN=$(cat /run/secrets/API_TOKEN) \
    start_server.sh
```

* [ ] (Optional) In some cases, startup scripts can automatically read build arguments as environment variables if you use the `_FILE` convention. In this [documentation example](https://docs.docker.com/compose/use-secrets/#advanced) 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.

## Add application-level build arguments

Navigate to the Settings tab within an application. Select **Build Arguments**. The application-specific build arguments will override the account-wide build argument settings.

![Navigating to App-Level Build Args under Application Advanced Settings](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-0659a4d8981d93ddc900f55cebf2e9d39fc04776%2Fapp-level-build-args.png?alt=media)

Notice how `USERNAME` is inherited from the account-level build arguments, while `API_TOKEN` is overridden by this application.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.release.com/reference-documentation/account-settings/build-settings/build-args.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.