07 / 10

What does ENV do in dockerfile?

The ENV instruction in a Dockerfile sets environment variables that persist in the container environment and are available to all subsequent instructions and running containers.

The ENV instruction sets environment variables both during the image build process and in the final running container. These variables are available to all subsequent Dockerfile instructions (such as RUN, CMD, and ENTRYPOINT) and remain available when the container runs. This is essential for configuring applications that read configuration from environment variables, setting PATH modifications, defining default values, or making build-time information available at runtime.

ENV Instruction Examples

Environment variables set with ENV remain in the final image and can be accessed in multiple ways: by running containers, through the docker inspect command, or when executing commands inside a container with docker exec. Users can also override these variables at runtime using the -e or --env flags with docker run, which is useful for adjusting configuration between environments without rebuilding the image.

Important Characteristics of ENV
  1. 1

    ENV variables persist in the final image and are visible to anyone who can run the container, so avoid storing secrets in ENV .

  2. 2

    Each ENV instruction creates a new layer, so combining multiple variables in one instruction reduces image size .

  3. 3

    Variables are interpolated in later Dockerfile instructions, enabling dynamic path construction and configuration .

  4. 4

    ENV values can be overridden at runtime with -e or --env flags, or through an env file with --env-file .

  5. 5

    The scope includes the current build stage and all subsequent stages in multi-stage builds .

Difficulty: 5/10
Topics: environment variables, Dockerfile layering, runtime configuration

Scenario Questions

0-2 years experience
  1. 1

    You need to add a database URL to your container image so the app can read it at runtime. How would you use ENV in the Dockerfile, and what will the container see when it runs?

  2. 2

    If you write ENV APP_ENV=production in a Dockerfile and later run the container with docker run -e APP_ENV=staging …, which value does the app get and why?

  3. 3

    What effect does ENV PATH=$PATH:/app/bin have on subsequent Dockerfile layers?

2-5 years experience
  1. 1

    Your CI builds an image that sets ENV NODE_ENV=production, but when you run the container locally the app behaves as if NODE_ENV is undefined. Walk me through how you'd debug this.

  2. 2

    You added an ENV‑based feature flag, then added a later RUN step that installs a package, and the flag is no longer recognized at runtime. What could cause that and how would you fix it?

  3. 3

    When would you choose ARG over ENV for passing values into an image, and what are the security and caching implications?

5-8 years experience
  1. 1

    Our microservice team wants to standardize configuration via environment variables but also allow per‑deployment overrides without rebuilding images. Design a strategy using ENV, ARG, and docker run flags, and discuss trade‑offs.

  2. 2

    A base image defines many default ENV variables; a downstream service overrides a few, but we notice larger image size and slower startup. Explain why and propose a Dockerfile restructuring.

  3. 3

    What are the risks of storing secrets in ENV variables in production containers, and what secure alternative would you recommend while keeping the Dockerfile simple?

8+ years experience
  1. 1

    We're moving to a multi‑stage build pipeline. How would you evolve the use of ENV across stages to keep configuration consistent yet prevent build‑time values from leaking into the final image?

  2. 2

    Several teams have hard‑coded ENV values, causing configuration drift. As a staff engineer, outline a governance model and tooling to centralize ENV definitions across services, considering CI/CD, versioning, and auditability.

  3. 3

    When migrating legacy apps that rely on many ENV variables to a platform using a configuration service (e.g., Consul), how would you phase out Dockerfile ENV usage without breaking existing deployments?

Follow-up Questions

  • How can you view the ENV values of a built image?
  • What happens if you reference an ENV variable in a later RUN step?
  • Can you change an ENV value without rebuilding the image?