Docker and Compose
Speed up Docker builds without stale results
Order Dockerfile layers, use cache mounts and narrow build context while preserving reproducibility.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Copy stable dependency manifests before frequently changing source, use a precise .dockerignore, and use supported cache mounts for package managers. Cache is an accelerator, not a source of truth; a clean build must still produce the same application.
What this means in plain English
Docker reuses an earlier build layer when its instructions and inputs have not changed. Good layer order keeps slow dependency installation reusable while letting source-code changes rebuild only later steps. A large build context can spoil that by sending unnecessary changing files.
Use a careful .dockerignore and committed lockfiles. Cache should make a correct build faster, not decide what the build contains. Occasionally compare with a clean build so missing inputs or stale results do not stay hidden.
Which layer invalidates the expensive work?
| Context | Only files the build needs |
|---|---|
| Layer order | Stable expensive steps before volatile source |
| Reproducibility | Lockfiles and clean-build verification |
A simple example
A Dockerfile copies the entire project before npm install, so changing one README file reinstalls every package. Moving package.json and the lockfile into an earlier step lets Docker reuse dependencies until those files actually change.
What to do, step by step
1. Measure layer timing with a cold build.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on context: only files the build needs. Write the result down so you can compare it later.
2. Add a narrow .dockerignore.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Separate dependency install from source copy.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Compare cached and no-cache outputs.
Finish by checking the result against reproducibility: lockfiles and clean-build verification. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Keep .git, local dependencies, logs and secret files out of the build context unless a specific build step truly needs them.
Common mistakes and how to avoid them
Ignoring lockfiles.
This gives a misleading or unsafe result because it leaves out context. A better approach is to measure layer timing with a cold build, then check the result before making the change permanent.
Copying .git and local artifacts.
This gives a misleading or unsafe result because it leaves out layer order. A better approach is to add a narrow .dockerignore, then check the result before making the change permanent.
Letting cache hide a missing build input.
This gives a misleading or unsafe result because it leaves out reproducibility. A better approach is to separate dependency install from source copy, then check the result before making the change permanent.
Quick checklist
- Measure layer timing with a cold build.
- Add a narrow .dockerignore.
- Separate dependency install from source copy.
- Compare cached and no-cache outputs.
Common questions
What is the simple answer?
Copy stable dependency manifests before frequently changing source, use a precise .dockerignore, and use supported cache mounts for package managers. Cache is an accelerator, not a source of truth; a clean build must still produce the same application.
What should I check first?
Start with context: only files the build needs. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Measure layer timing with a cold build. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Ignoring lockfiles. Avoiding that one mistake makes the rest of the comparison much more trustworthy.