ARG and ENV instructions in Docker - Step-by-Step Execution

Process Flow - ARG and ENV instructions

Start Dockerfile Build

↓

ARG: Define build-time variable

↓

Use ARG in Dockerfile

↓

ENV: Define runtime environment variable

↓

Use ENV in container runtime

↓

Build completes with ARG values

↓

Run container with ENV variables set

This flow shows how ARG sets variables during build time, and ENV sets variables available when the container runs.

Execution Sample

Docker

ARG APP_PORT=8080
ENV APP_ENV=production
RUN echo "Port is $APP_PORT"
CMD ["sh", "-c", "echo Running in $APP_ENV on port $APP_PORT"]

This Dockerfile snippet defines a build-time ARG and a runtime ENV, then uses them in commands.

Process Table

Step	Instruction	Variable Set	Value	Usage	Output/Effect
1	ARG APP_PORT=8080	APP_PORT	8080	Build-time variable	APP_PORT set to 8080 during build
2	ENV APP_ENV=production	APP_ENV	production	Runtime environment variable	APP_ENV set to production in container
3	RUN echo "Port is $APP_PORT"	N/A	N/A	Uses ARG value	Outputs: Port is 8080
4	CMD ["sh", "-c", "echo Running in $APP_ENV on port $APP_PORT"]	N/A	N/A	Uses ENV at runtime (ARG unavailable)	When container runs, outputs: Running in production on port
5	Build ends	N/A	N/A	N/A	Build completes with ARG applied
6	Container runs	N/A	N/A	N/A	ENV variables available, ARG not available at runtime

💡 Build finishes after all instructions; ARG variables exist only during build, ENV variables persist in container runtime.

Status Tracker

Variable	Start	After ARG	After ENV	Final
APP_PORT	undefined	8080	8080	8080 (build-time only)
APP_ENV	undefined	undefined	production	production (runtime)

Key Moments - 3 Insights

Why can't I use ARG variables inside the running container?

ARG variables exist only during the build steps (see execution_table step 1 and 6). They are not saved in the final image, so at runtime (step 6) they are not available.

Can ENV variables be changed during build time?

ENV variables are set during build and persist in the image (step 2). You can override them at container start, but inside the Dockerfile they remain constant after set.

What happens if I use an ARG variable in CMD without ENV?

ARG variables are not available at runtime (step 6), so using ARG directly in CMD will not work as expected. Use ENV to pass variables to runtime commands.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of APP_PORT during the RUN instruction?

A production

B undefined

C 8080

D null

💡 Hint

Check step 3 in the execution_table where RUN uses APP_PORT.

At which step does the APP_ENV variable become available in the container runtime?

A Step 1

B Step 6

C Step 4

D Step 2

💡 Hint

Look at the exit_note and step 6 in execution_table about runtime availability.

If you remove the ENV instruction, what happens to APP_ENV in the running container?

A It becomes undefined

B It remains 'production'

C It takes the ARG value

D It defaults to 'development'

💡 Hint

ENV sets runtime variables; without it, see variable_tracker for APP_ENV.

Concept Snapshot

ARG sets variables only during build time.
ENV sets variables available when container runs.
Use ARG for build-time config, ENV for runtime config.
ARG values can't be accessed in running containers.
ENV variables persist in the image and container.
Use ENV to pass variables to commands run inside container.

Full Transcript

This visual execution shows how Dockerfile instructions ARG and ENV work. ARG defines variables used only during the image build process. ENV defines variables that exist inside the container when it runs. The example Dockerfile sets APP_PORT as ARG with default 8080 and APP_ENV as ENV with value production. During build, the RUN command can use APP_PORT because ARG is available. At runtime, the container can access APP_ENV but not APP_PORT because ARG does not persist. The execution table traces each step, showing when variables are set and used. The variable tracker confirms APP_PORT exists only during build, while APP_ENV exists at runtime. Key moments clarify common confusions about ARG and ENV scopes. The quiz tests understanding of variable availability and usage. The snapshot summarizes the key differences and usage rules for ARG and ENV in Dockerfiles.

Practice

1. What is the main difference between ARG and ENV instructions in a Dockerfile?

easy

A. ARG defines build-time variables, ENV defines runtime environment variables.

B. ARG defines runtime environment variables, ENV defines build-time variables.

C. ARG and ENV are exactly the same and interchangeable.

D. ARG is used to set default ports, ENV sets user permissions.

Solution

1. Step 1: Understand ARG usage

   ARG defines variables that are only available during the image build process. They cannot be accessed after the image is built.

2. Step 2: Understand ENV usage

   ENV sets environment variables that persist in the built image and are available at runtime inside containers.

3. Final Answer:

   ARG defines build-time variables, ENV defines runtime environment variables. -> Option A

4. Quick Check:

   ARG = build-time, ENV = runtime [OK]

Hint: Remember: ARG is build-time, ENV is runtime [OK]

Common Mistakes:

• Confusing ARG as runtime variable
• Thinking ENV variables are only for build-time
• Assuming ARG persists in the final image
• Mixing up the purpose of ARG and ENV

2. Which of the following is the correct syntax to declare a build argument named VERSION with a default value 1.0 in a Dockerfile?

easy

A. ARG VERSION : 1.0

B. ENV VERSION=1.0

C. ARG VERSION=1.0

D. ENV VERSION : 1.0

Solution

1. Step 1: Recall ARG syntax

   The correct syntax to declare a build argument with a default value is ARG name=value. So ARG VERSION=1.0 is valid.

2. Step 2: Check other options

   ENV is for environment variables, not build arguments. The colon syntax is invalid in Dockerfile.

3. Final Answer:

   ARG VERSION=1.0 -> Option C

4. Quick Check:

   ARG syntax uses equals sign (=) [OK]

Hint: ARG uses '=' to assign default values [OK]

Common Mistakes:

• Using ENV instead of ARG for build arguments
• Using colon (:) instead of equals (=)
• Omitting the default value syntax
• Confusing ARG and ENV syntax

3. Given the Dockerfile snippet:

ARG APP_VERSION=2.0
ENV APP_VERSION=$APP_VERSION
RUN echo $APP_VERSION

What will be the output of the RUN echo $APP_VERSION command during build if no build argument is passed?

medium

A. Error: variable not found

B. $APP_VERSION

C. empty line

D. 2.0

Solution

1. Step 1: Understand ARG default value

   ARG APP_VERSION=2.0 sets a default build argument value of "2.0" if none is passed.

2. Step 2: ENV uses ARG value

   ENV APP_VERSION=$APP_VERSION sets an environment variable using the ARG value, so it becomes "2.0".

3. Step 3: RUN command output

   RUN echo $APP_VERSION prints the environment variable value "2.0" during build.

4. Final Answer:

   2.0 -> Option D

5. Quick Check:

   ARG default used in ENV, echoed as 2.0 [OK]

Hint: ARG default flows into ENV if no override [OK]

Common Mistakes:

• Expecting empty output if no build arg passed
• Thinking $APP_VERSION is literal string
• Assuming error if variable not passed
• Confusing build-time and runtime variable scopes

4. Identify the error in this Dockerfile snippet:

ARG PORT
ENV PORT=8080
EXPOSE $PORT

medium

A. You cannot use variables in the EXPOSE instruction.

B. The ENV variable PORT overrides ARG but EXPOSE uses $PORT which is not expanded.

C. The ARG variable PORT is not given a default value.

D. The ENV instruction must come before ARG.

Solution

1. Step 1: Check variable usage in EXPOSE

   The EXPOSE instruction does not support variable expansion. Using $PORT will not work.

2. Step 2: Validate other statements

   Not giving a default to ARG PORT is allowed. ENV can override ARG. The order of ARG and ENV is not restricted.

3. Final Answer:

   You cannot use variables in the EXPOSE instruction. -> Option A

4. Quick Check:

   EXPOSE does not expand variables [OK]

Hint: EXPOSE needs literal port numbers, no variables allowed [OK]

Common Mistakes:

• Assuming EXPOSE supports variable expansion
• Thinking ARG must have default value
• Believing ENV must come after ARG
• Confusing build-time and runtime variable scopes

5. You want to build a Docker image that accepts a build argument APP_ENV with default production and sets an environment variable APP_ENV inside the container accordingly. Which Dockerfile snippet correctly achieves this?

hard

A. ENV APP_ENV=production
ARG APP_ENV
ENV APP_ENV=$APP_ENV

B. ARG APP_ENV=production
ENV APP_ENV=$APP_ENV

C. ARG APP_ENV
ENV APP_ENV=production

D. ENV APP_ENV=$APP_ENV
ARG APP_ENV=production

Solution

1. Step 1: Set ARG with default value

   ARG APP_ENV=production defines the build argument with default "production" if none is passed.

2. Step 2: Set ENV using ARG value

   ENV APP_ENV=$APP_ENV sets the runtime environment variable to the ARG value, so it reflects the build argument or default.

3. Step 3: Validate other options

   ENV APP_ENV=production ARG APP_ENV ENV APP_ENV=$APP_ENV sets ENV before ARG which is invalid. ARG APP_ENV ENV APP_ENV=production does not set default for ARG. ENV APP_ENV=$APP_ENV ARG APP_ENV=production uses ENV before ARG which is incorrect.

4. Final Answer:

   ARG APP_ENV=production ENV APP_ENV=$APP_ENV -> Option B

5. Quick Check:

   ARG default then ENV from ARG [OK]

Hint: Declare ARG with default, then ENV using ARG variable [OK]

Common Mistakes:

• Setting ENV before ARG
• Not providing default value for ARG
• Overwriting ENV without ARG reference
• Confusing build-time and runtime variable order