Docker containers need their environment variables at runtime, not baked into the image. This guide shows how to deliver secrets from dotEnv Cloud into a container safely, keeping plaintext out of image layers and your Dockerfile.
Why not bake secrets into the image
Anything copied or set during docker build becomes part of an image layer, which is trivially inspectable. The correct approach is to fetch secrets at container start, or to pull them on the host and inject them with --env-file.
Option 1: an entrypoint that pulls at start
Install the CLI in your image, then have the entrypoint pull secrets and exec your application. The API key is provided to the running container, never the build:
Run the container with the API key supplied at start time:
Option 2: pull on the host, inject with --env-file
If you would rather keep the CLI out of the image entirely, pull a .env file on the host and pass it to docker run:
Dockerfile-format output
The CLI can also emit ENV declarations in Dockerfile syntax with --format=dockerfile, which is handy when generating fragments for a build pipeline:
ENV lines, treat the result as sensitive and never commit it, since the values end up in image layers.
Client-managed encryption
For client-managed projects, provide the key through DOTENV_CLIENT_KEY or mount a key file and pass --client-key=/run/secrets/dotenv.key. Combined with Docker secrets, the key never touches an image layer.
To take this into an orchestrator, continue with Kubernetes.