WORKDIR instruction for directory in Docker - Commands & Configuration

Introduction

When building a Docker image, you often need to set the working directory where commands run. The WORKDIR instruction sets this directory inside the container, so you don't have to type full paths every time.

When you want to organize files inside the container in a specific folder.

When you need to run commands like COPY or RUN in a certain directory.

When your application expects to start in a particular folder.

When you want to avoid repeating long directory paths in multiple commands.

When you want to make your Dockerfile cleaner and easier to read.

Config File - Dockerfile

Dockerfile

FROM alpine:3.18
WORKDIR /app
COPY . .
RUN ls -l
CMD ["sh"]

FROM alpine:3.18 sets the base image.

WORKDIR /app sets the working directory inside the container to /app.

COPY . . copies files from your current folder on the host to /app in the container.

RUN ls -l lists files in /app to verify the working directory.

CMD ["sh"] starts a shell when the container runs.

Commands

Builds the Docker image named example-workdir using the Dockerfile in the current directory.

Terminal

docker build -t example-workdir .

Expected Output

Sending build context to Docker daemon  2.56kB

Step 1/5 : FROM alpine:3.18

 ---> 3f53bb00af94

Step 2/5 : WORKDIR /app

 ---> Running in 1a2b3c4d5e6f

Removing intermediate container 1a2b3c4d5e6f

 ---> 7f8e9d0c1b2a

Step 3/5 : COPY . .

 ---> 9a8b7c6d5e4f

Step 4/5 : RUN ls -l

 ---> Running in 0f1e2d3c4b5a

total 12

-rw-r--r--    1 root     root          123 Apr 27 12:00 Dockerfile

-rw-r--r--    1 root     root          456 Apr 27 12:00 somefile.txt

Removing intermediate container 0f1e2d3c4b5a

 ---> 1a2b3c4d5e6f

Step 5/5 : CMD ["sh"]

 ---> Running in 7e8f9a0b1c2d

Removing intermediate container 7e8f9a0b1c2d

 ---> 3b4c5d6e7f8a

Successfully built 3b4c5d6e7f8a

Successfully tagged example-workdir:latest

Runs the container and prints the current working directory to confirm WORKDIR is set to /app.

Terminal

docker run --rm -it example-workdir pwd

Expected Output

/app

→

--rm - Automatically remove the container after it exits

→

-it - Run container interactively with a terminal

Runs the container and lists files in the working directory to verify files were copied there.

Terminal

docker run --rm -it example-workdir ls -l

Expected Output

total 12

-rw-r--r--    1 root     root          123 Apr 27 12:00 Dockerfile

-rw-r--r--    1 root     root          456 Apr 27 12:00 somefile.txt

→

--rm - Automatically remove the container after it exits

→

-it - Run container interactively with a terminal

Key Concept

If you remember nothing else from this pattern, remember: WORKDIR sets the folder where all following commands run inside the container.

Common Mistakes

Not using WORKDIR and instead typing full paths in every command.

This makes the Dockerfile longer, harder to read, and error-prone if paths change.

Use WORKDIR once to set the directory, then use relative paths in later commands.

Setting WORKDIR to a path that does not exist and expecting it to fail.

Docker automatically creates the directory if it does not exist, so this is not an error but can confuse beginners.

Know that WORKDIR creates the directory if missing, so you can safely set any valid path.

Summary

WORKDIR sets the working directory inside the container for all following commands.

It helps organize files and simplifies command paths in the Dockerfile.

You can verify WORKDIR by running commands like pwd or ls inside the container.

Practice

1. What does the WORKDIR instruction do in a Dockerfile?

easy

A. Runs a command when the container starts

B. Deletes files in the container

C. Sets the working directory for commands inside the container

D. Specifies the base image for the container

Solution

1. Step 1: Understand the purpose of WORKDIR

   The WORKDIR instruction sets the folder where subsequent commands run inside the container.

2. Step 2: Compare with other options

   Options A, B, and C describe other Dockerfile instructions or actions, not WORKDIR.

3. Final Answer:

   Sets the working directory for commands inside the container -> Option C

4. Quick Check:

   WORKDIR sets folder for commands [OK]

Hint: WORKDIR sets folder for commands inside container [OK]

Common Mistakes:

• Confusing WORKDIR with CMD or ENTRYPOINT
• Thinking WORKDIR deletes files
• Assuming WORKDIR sets base image

2. Which of the following is the correct syntax to set the working directory to /app in a Dockerfile?

easy

A. WORKDIR /app

B. WORKDIR: /app

C. WORKDIR = /app

D. WORKDIR(/app)

Solution

1. Step 1: Recall Dockerfile syntax for WORKDIR

   The correct syntax is WORKDIR /path without any symbols like colon, equals, or parentheses.

2. Step 2: Check each option

   Options A, B, and D use invalid syntax for Dockerfile instructions.

3. Final Answer:

   WORKDIR /app -> Option A

4. Quick Check:

   WORKDIR uses space, no symbols [OK]

Hint: WORKDIR uses space before path, no symbols [OK]

Common Mistakes:

• Adding colon or equals sign after WORKDIR
• Using parentheses around path
• Forgetting the space between WORKDIR and path

3. Given this Dockerfile snippet:

FROM alpine
WORKDIR /app
RUN touch file.txt
WORKDIR /app/data
RUN echo "hello" > message.txt

Where will the file message.txt be created inside the container?

medium

A. /app/data/file.txt

B. /app/message.txt

C. /message.txt

D. /app/data/message.txt

Solution

1. Step 1: Follow WORKDIR changes

   The first WORKDIR sets directory to /app. The second WORKDIR changes it to /app/data.

2. Step 2: Locate where message.txt is created

   The command RUN echo "hello" > message.txt runs in /app/data, so the file is created there.

3. Final Answer:

   /app/data/message.txt -> Option D

4. Quick Check:

   Last WORKDIR sets folder for commands [OK]

Hint: Last WORKDIR sets current folder for commands [OK]

Common Mistakes:

• Assuming files created in first WORKDIR folder
• Confusing file paths with root directory
• Ignoring multiple WORKDIR instructions

4. You wrote this Dockerfile snippet:

WORKDIR /app
RUN ls
WORKDIR app/data
RUN ls

Why does the second WORKDIR cause an unexpected result?

medium

A. Because WORKDIR cannot be used twice

B. Because relative path 'app/data' resolves to /app/app/data instead of /app/data

C. Because RUN ls is invalid syntax

D. Because /app directory is not created automatically

Solution

1. Step 1: Understand relative paths in WORKDIR

   The second WORKDIR uses a relative path app/data, which is relative to the current directory /app. So it tries to set /app/app/data.

2. Step 2: Understand relative path resolution

   Docker creates /app/app/data automatically if needed, but this nested path is usually unintended if /app/data was desired.

3. Step 3: Identify actual issue

   Relative path app/data is a mistake; use data or absolute /app/data instead.

4. Final Answer:

   Because relative path 'app/data' resolves to /app/app/data instead of /app/data -> Option B

5. Quick Check:

   Relative WORKDIR paths resolve from current dir [OK]

Hint: Relative WORKDIR paths are inside current folder [OK]

Common Mistakes:

• Thinking WORKDIR cannot be used multiple times
• Assuming RUN ls is invalid
• Believing /app is not auto-created

5. You want to create a Dockerfile that:
- Sets working directory to /app
- Creates a subfolder logs
- Changes working directory to logs
- Creates a file app.log

Which Dockerfile snippet correctly does this?

hard

A. WORKDIR /app
RUN mkdir logs
WORKDIR logs
RUN touch app.log

B. WORKDIR /app/logs
RUN mkdir logs
WORKDIR /app
RUN touch app.log

C. RUN mkdir /app/logs
WORKDIR /app/logs
RUN touch app.log

D. WORKDIR /app
RUN touch app.log
WORKDIR logs
RUN mkdir logs

Solution

1. Step 1: Set working directory to /app and create logs folder

   WORKDIR /app RUN mkdir logs WORKDIR logs RUN touch app.log sets WORKDIR to /app and runs mkdir logs to create the subfolder.

2. Step 2: Change WORKDIR to logs and create app.log

   Then it changes WORKDIR to logs (relative to /app) and creates app.log inside it.

3. Step 3: Verify other options

   WORKDIR /app/logs RUN mkdir logs WORKDIR /app RUN touch app.log sets WORKDIR incorrectly and creates logs folder in wrong place. RUN mkdir /app/logs WORKDIR /app/logs RUN touch app.log creates logs folder but misses initial WORKDIR. WORKDIR /app RUN touch app.log WORKDIR logs RUN mkdir logs creates app.log before logs folder and changes WORKDIR before folder exists.

4. Final Answer:

   WORKDIR /app RUN mkdir logs WORKDIR logs RUN touch app.log -> Option A

5. Quick Check:

   Create folder before changing WORKDIR [OK]

Hint: Create folder before changing WORKDIR into it [OK]

Common Mistakes:

• Changing WORKDIR before folder exists
• Creating files in wrong directory
• Using absolute path incorrectly