5.1.1.2 Directory Build Context

A directory build context is the most common form of build context: a local directory path supplied to docker build, whose contents (minus anything excluded by .dockerignore) are packaged and transferred to the daemon as the files available to the build.

Specifying a Directory Context

The simplest and most familiar form of build context invocation points directly at a local directory.

docker build -t myapp .

docker build -t myapp ./backend

Both forms use a local directory as the context, differing only in which directory is chosen.

What Happens Internally

Docker walks the specified directory, applies any .dockerignore exclusions, packages the remaining files into an archive, and transfers that archive to the daemon before the build's instructions begin executing.

docker build -t myapp .

Sending build context to Docker daemon  45.2MB

This reported size reflects exactly what was packaged and transferred from the local directory context.

Using a Different Dockerfile With a Directory Context

The Dockerfile itself does not need to reside directly within the context directory; its location can be specified separately from the context path.

docker build -f docker/Dockerfile.prod -t myapp:prod .

Here, the context remains the current directory, but the actual Dockerfile is read from a different, specified location.

Why Directory Context Is the Default Choice

For the overwhelming majority of typical builds, a local directory context is the simplest, most predictable choice, directly reflecting the project's own file structure without requiring any additional setup beyond an accurate .dockerignore.

docker build -t myapp .

Why Understanding Directory Context Matters

A solid understanding of exactly how a directory context is determined and transferred is foundational to diagnosing build context-related issues, such as unexpectedly slow builds or unexpectedly large context transfers, that are otherwise easy to misattribute to unrelated causes.