Dockerfile cheatsheet

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Dockerfile cheatsheet

Dockerfile Cheatsheet summarizes common instructions used to build a container image. A Dockerfile describes a sequence of build steps and metadata, while the build context determines which local files are available to copy. Layering, cache behavior, working directories, and build-versus-runtime variables influence the resulting image. A cheatsheet works best as a memory aid while you practice a concrete task. Read the command or syntax together with its arguments, placeholders, and surrounding context. Similar-looking options can have very different meanings, and an example written for one platform or version may need adjustment elsewhere. Keep the reference beside a small test case, use read-only examples first when possible, and check the relevant help output before applying an unfamiliar command to valuable files or a running service.

Guide updated October 13, 2026

How to use this tool

1. Identify the operation you want to perform and find the matching section of the reference. Read the whole example before copying any part of it.
2. Locate the instruction you need and test it in a minimal build context with a deliberately small set of files.
3. Review the example below and compare its expected behavior with a small sample of your own input before continuing.
4. Try the adapted example on a small test case, compare the result with the explanation, and save the command with a note about the context in which it works.

SEE IT IN PRACTICE

A worked example

WORKDIR /app

Subsequent relevant Dockerfile operations use /app as their working directory

An explicit working directory makes relative COPY, RUN, and command assumptions easier to understand.

Build context determines what can be copied

COPY instructions refer to files available in the build context, not arbitrary paths on the developer's machine. A context that is too broad can accidentally include large generated directories or private files. Review the ignore rules and the build invocation together with the Dockerfile. Working-directory instructions affect subsequent relative operations, so an explicit directory makes a small build easier to reason about. If a copy fails, check the context boundary and path before changing unrelated build steps.

Layers and runtime intent

Build steps create image layers, and cache reuse depends on how the steps and their inputs change. Separate frequently changing application files from stable dependency setup when that fits the project, but do not trade clarity for clever caching without a reason. Distinguish build-time arguments from runtime environment values and keep secrets out of ordinary layers. Finally, inspect the command and entrypoint behavior together: a successfully built image can still start the wrong process or handle supplied arguments unexpectedly.

When this tool is useful

• Understand common Dockerfile instructions
• Review a small image build
• Compare build-time and runtime configuration

Tips for a better result

• Review the base image, copied paths, working directory, final command, and unnecessary context files before building.
• Replace example paths, identifiers, and names deliberately. Copying a reference command unchanged can target a different file, branch, service, or environment from the one you intended.
• Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.

Frequently asked questions