4.2.3.2 COPY Dependency Manifests
A focused guide to COPY Dependency Manifests, connecting core concepts with practical Docker and container operations.
Using COPY for dependency manifests specifically — copying only files like package.json, requirements.txt, or pom.xml before the rest of the application source — is a deliberate pattern for maximizing how much of a typical rebuild can be served from Docker's build cache.
Why Copying Manifests Separately Matters
Because Docker's cache invalidates a layer, and everything after it, whenever the files a COPY instruction depends on change, copying only the dependency manifest first means dependency installation is only re-executed when the manifest itself actually changes, not whenever any other application file changes.
COPY package*.json ./
RUN npm install
COPY . .
If only application source files change between builds, this ordering means npm install is served entirely from cache, since package*.json is unaffected.
Contrasting With Copying Everything at Once
Copying the entire application source before installing dependencies forces dependency installation to be invalidated and re-executed on every single source code change, even ones with nothing to do with dependencies at all.
COPY . .
RUN npm install
COPY package*.json ./
RUN npm install
COPY . .
The second ordering is strictly better for cache efficiency, since it isolates dependency installation from unrelated source code changes.
Applying This Pattern Across Languages
The same pattern applies regardless of language ecosystem — copying just the manifest file relevant to that ecosystem's package manager before installing dependencies, then copying the rest of the application afterward.
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src/ ./src/
Why This Pattern Matters for Build Speed
In a typical development cycle, application source code changes far more frequently than declared dependencies do, which means this ordering pattern can produce a substantial, consistently observed reduction in average build time across a project's normal development workflow.