Every instruction in a Dockerfile produces a read-only layer, and layers are stacked to form the final image. When a container runs, a thin writable layer is added on top. Layers are cached: if an instruction and its context are unchanged, Docker reuses the cached layer instead of running the command again. This is why ordering matters, because putting frequently changing instructions late in the file (such as COPY . . near the end) maximizes cache reuse and keeps build times fast. A related tool, the .dockerignore file in the build directory, excludes files and directories from the build context sent to the daemon, preventing large folders like node_modules or sensitive files like .env from inflating the context or leaking into images.
For more demanding builds, Docker provides BuildKit, the next-generation build engine that is enabled by default in recent versions. BuildKit brings parallel build steps, better caching, rootless builds, and three especially useful mount types in RUN instructions: type=cache mounts a persistent build cache at a path inside the build container (great for package-manager caches like /root/.cache/pip), type=secret makes a secret available at build time without baking it into any layer, and type=ssh forwards the host's SSH agent so private repositories can be cloned during the build. The docker buildx command is the extended CLI built on top of BuildKit, supporting multi-platform builds in a single command, advanced caching backends (registry, S3, local), and custom builders.
Multi-stage builds take advantage of BuildKit and the layered model. A Dockerfile can declare multiple FROM instructions, each starting a new stage with its own base image, and copy only the needed artifacts from earlier stages into the final image. This produces much smaller production images: a builder stage with a full toolchain can compile code, and the final stage contains only the compiled binary on a minimal base. Named stages can also be built independently using docker build --target, which is useful in CI pipelines. Multi-platform builds with buildx produce a manifest list (or image index), a single reference that points to platform-specific images so the runtime can pull the right variant for its architecture.
Once an image is built, it is shared through registries that implement the OCI distribution spec. Docker Hub is the official public registry, hosting official images curated in partnership with upstream projects (such as nginx, postgres, python), automated builds from GitHub and Bitbucket, public and private repositories, and vulnerability scanning. Verified publishers add an extra layer of trust, since Docker has confirmed their identity. For private distribution, you can run your own registry with docker run -d -p 5000:5000 registry:2, tag images for that endpoint, and push them after docker login. Because Docker images follow the OCI image format, they are portable to any compliant runtime such as Podman, containerd, or CRI-O. In security-sensitive environments, Docker Content Trust uses Notary to sign image tags so that only trusted publishers' images can be pulled when DOCKER_CONTENT_TRUST=1.