What does the RUN instruction do in dockerfile?
The RUN instruction executes commands in a new layer on top of the current image and commits the results, permanently incorporating the changes into the image.
The RUN instruction is one of the primary workhorse commands in a Dockerfile, responsible for executing commands during the image build process. Each RUN command creates a new layer in the image, capturing the filesystem changes made by the command as a permanent part of the image. This is fundamentally different from CMD and ENTRYPOINT, which define what happens when a container runs—RUN commands shape the image itself by installing packages, configuring software, creating directories, or any other build-time setup required for your application.
The RUN instruction has two forms: shell form and exec form. The shell form (RUN command param1 param2) invokes the command through /bin/sh -c, which provides shell processing like variable substitution and command chaining. The exec form (RUN ["executable", "param1", "param2"]) executes the command directly without shell processing, which is more precise and avoids shell string munging. The exec form is particularly useful when running on base images without /bin/sh or when you need exact control over command arguments.
- 1
Each RUN instruction creates a new image layer, so chaining multiple commands with
&&is recommended to reduce the number of layers and final image size . - 2
Commands in RUN are executed at build time, not when the container runs, making them ideal for installation and configuration that shouldn't change .
- 3
The working directory for RUN commands can be set with the WORKDIR instruction, which affects all subsequent RUN, CMD, COPY, and ADD instructions .
- 4
Environment variables set with ENV are available during RUN execution, allowing dynamic configuration based on build arguments .
- 5
Commands that create large temporary files or caches should clean up in the same RUN instruction to avoid bloating the final image .
Scenario Questions
0-2 years experience
- 1You need to add curl to an Alpine‑based image. What Dockerfile line would you write using RUN?
- 2If you place a RUN apt‑get update before installing packages, how does that affect later builds?
- 3During a docker build, a RUN command fails with exit code 1. What does Docker do and how would you see the error?
2-5 years experience
- 1Your CI pipeline rebuilds a large image and the RUN apt‑get install step is slow each time. How would you refactor the Dockerfile to speed it up?
- 2You added a RUN echo 'debug' > /tmp/file but later stages can't see the file. Explain why and how to fix it.
- 3A new RUN line caused the image size to increase by 200 MB. Walk me through how you'd investigate and reduce that size.
5-8 years experience
- 1Design a Dockerfile for a service that needs to compile code and then run with only runtime dependencies, minimizing final image size. Explain your use of RUN and multi‑stage builds.
- 2You want a heavy compilation step to be cached across builds on different branches. What strategies involving RUN and Docker's build cache would you use?
- 3Discuss the trade‑offs of splitting a long RUN command into multiple RUN statements versus chaining them with && in terms of layer caching and image size.
8+ years experience
- 1Our org is migrating hundreds of services to a new base image. How would you coordinate changes to RUN instructions across repositories to ensure security patches, consistency, and minimal downtime?
- 2Explain how RUN‑generated layers impact container registry storage costs at scale and propose a policy for managing them.
- 3When adopting BuildKit, what changes would you make to existing Dockerfiles' RUN usage to leverage parallel builds and secret handling while keeping backward compatibility?
Follow-up Questions
- What happens if a RUN command exits with a non‑zero status during a build?
- How does Docker decide whether to reuse a cached layer for a RUN step?
- Why might you combine several commands into a single RUN using &&?