What does WORKDIR do in dockerfile?
The WORKDIR instruction sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions in the Dockerfile.
The WORKDIR instruction defines the current working directory for all following instructions in the Dockerfile. If the directory doesn't exist, it will be created automatically. This is essential for organizing application files and ensuring that commands execute in the correct location. Once set, all relative paths in subsequent instructions are resolved relative to this working directory.
Using WORKDIR is strongly recommended over using RUN cd ... commands because it provides a cleaner, more maintainable way to set the working directory. Each WORKDIR instruction can be relative to the previous one, and it automatically handles directory creation. The directory path can include environment variables set earlier in the Dockerfile, making it flexible for different configurations.
- 1
Eliminates repetitive cd commands in RUN instructions, making the Dockerfile cleaner and easier to read
- 2
Automatically creates directories if they don't exist, avoiding explicit mkdir commands
- 3
Works consistently with COPY and ADD relative paths, ensuring files land where expected
- 4
Sets the initial working directory for the container when it starts, affecting CMD and ENTRYPOINT
- 5
Can use environment variables, enabling dynamic path configuration
Scenario Questions
0-2 years experience
- 1If you need to copy a config file into /app/config and then run the binary from that directory, how would you use WORKDIR in the Dockerfile?
- 2What happens if you set WORKDIR to /src and later in the same Dockerfile you run a command without specifying a path?
- 3When the container starts, what will its current directory be if the Dockerfile ends with WORKDIR /myapp?
2-5 years experience
- 1We have a multi‑stage build where the builder stage sets WORKDIR /build, but the final stage forgets to set it. The container fails to find the entrypoint script. Walk me through how you would debug this and what role WORKDIR plays.
- 2Suppose you need both a development image that starts in /code and a production image that starts in /app. How would you structure the Dockerfile using WORKDIR, and what trade‑offs should you consider?
- 3If you change WORKDIR after a RUN instruction that creates files, where will those files be located relative to later commands?
5-8 years experience
- 1In a large microservices platform we use a base image that sets WORKDIR /opt/service. Some services need to run as non‑root users and change to a different directory at runtime. How would you design the Dockerfile and entrypoint to handle this without breaking the WORKDIR expectations?
- 2When building an image that mounts a volume at runtime, how does the WORKDIR interact with volume mounts, and what performance or security implications should you be aware of?
- 3Explain how you would refactor a set of Dockerfiles that each set WORKDIR multiple times to a shared base image, considering build‑cache efficiency.
8+ years experience
- 1Our organization is migrating hundreds of legacy Dockerfiles that use absolute paths in RUN commands instead of relying on WORKDIR. What strategy would you propose to standardize WORKDIR usage across teams while minimizing disruption?
- 2Discuss the long‑term maintenance implications of setting WORKDIR in a base image versus letting each service define its own. How does this affect CI/CD pipelines, security policies, and cross‑team onboarding?
- 3If we need to support both Linux and Windows containers, how does WORKDIR behave across platforms, and what architectural decisions must we make to keep Dockerfiles portable?
Follow-up Questions
- What would happen if you omitted the WORKDIR instruction entirely?
- How does WORKDIR interact with the USER directive?
- Can you change the working directory at runtime, and if so, how?