iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Deleting or replacing a file in a later Dockerfile instruction does not remove the bytes recorded in an earlier image layer. The container’s merged filesystem may show only the new state, while the image still contains the old content. To keep temporary files out of the image, create and remove them in the same filesystem-changing instruction; use a multi-stage build to leave build-only tools and artifacts out of the runtime image.
Why a later deletion does not shrink an image
A Docker image is composed of filesystem layers. Each layer records changes made during the build, and Docker combines those changes into a merged filesystem view when a container runs. If one instruction adds a file and a later instruction deletes it, the later layer records the deletion, so the file is no longer visible in the merged view. But the earlier layer still contains its bytes; the deletion does not rewrite that layer. Docker describes this behavior in its storage-driver documentation.
Replacing a large file has the same underlying issue: if the old version was added in an earlier layer and the replacement in a later one, both versions can contribute to the image’s stored layer data even though the merged filesystem exposes only the replacement. That is the “twice” cost in the title: old content remains recorded, and new content is added. The exact space consumed depends on the image and its layers; Docker’s cited documentation does not give a general savings figure for avoiding this pattern.
Free tools Windows power users keep installed
One-click scans. No signup required.
Keep temporary files and their cleanup in one instruction
If an operation creates temporary package indexes, caches, or other files that should not remain in the resulting image, perform the operation and cleanup in the same RUN instruction. If cleanup is deferred to a separate instruction, the temporary files remain in the earlier layer even when they disappear from the merged filesystem.
#1 Best Overall
RUN apt-get update 626 apt-get install -y --no-install-recommends <packages> 626 rm -rf /var/lib/apt/lists/*Replace <packages> with the packages the image actually needs. The important part is the boundary: update, install, and removal happen within the same filesystem-changing instruction. This example illustrates the pattern; it is not a recommendation to use a particular package manager or package list.
That does not mean every Dockerfile instruction should be collapsed into one enormous RUN. Combine operations when their temporary files must disappear together, but keep useful boundaries around stable inputs and frequently changing source so Docker can reuse cached work.
Order instructions for useful cache reuse
Image size and build-cache reuse are separate concerns. Docker’s cache guidance explains that when a layer changes, following layers may need to be rebuilt. Copying relatively stable dependency manifests and installing dependencies before copying frequently edited application source can let Docker reuse dependency work when only the source changes, if the project’s dependency model allows it.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →- Copy stable dependency files first. Use a
COPYinstruction for the manifests or lockfiles that determine dependencies. - Install dependencies next. Keep this work in a layer that can remain cached while those manifests stay unchanged.
- Copy frequently changing source afterward. Source edits then invalidate later work rather than the earlier dependency-installation layer.
Docker illustrates this ordering in its build-cache guide; its broader cache documentation explains invalidation. This ordering can reduce repeated build work, but it does not erase bytes already recorded in image layers.
Keep build tools out of the runtime image with stages
A multi-stage build separates the environment that compiles or prepares an application from the final image used to run it. Build in one stage, then copy only the required executable, assets, or other runtime artifacts into a later stage. Compilers, development dependencies, and intermediate outputs then need not be part of the final runtime image. Docker’s building best practices describe this approach.
Use this when a build needs tools or dependencies that the running application does not. It addresses final-image contents, whereas dependency ordering primarily helps cache reuse; the two techniques can be used together.
When COPY --link can help
In supported BuildKit and Dockerfile-syntax workflows, COPY --link can keep copied files in a layer independent of preceding layers, which can make that copied layer reusable across changes to earlier layers. It does not remove bytes from an earlier layer or replace same-instruction cleanup for temporary files. Check the builder and Dockerfile syntax support used by the project before relying on it; Docker documents the behavior in its Dockerfile reference.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Build-time layers are not runtime OverlayFS copy-up
A separate behavior can matter after a container starts. With OverlayFS, the first time a container writes to a file that exists in a lower, image-backed layer, OverlayFS copies that entire file into the writable upper directory; the write then affects the upper copy. A small edit to a large file can therefore incur a full-file copy on that first write, while subsequent writes use the upper copy. This is a runtime copy-up cost, not the reason a build-time deletion leaves earlier image bytes behind. It is specific to OverlayFS and should not be assumed for every storage driver. See Docker’s OverlayFS storage-driver documentation.
Best Value
Choose the fix for the problem you have
| Technique | What it addresses | What it does not do |
|---|---|---|
Clean up temporary files in the same RUN |
Keeps those temporary additions from remaining in an earlier image layer. | Does not by itself improve cache reuse for frequently changing source. |
| Copy stable dependency manifests and install dependencies before copying changing source | Can preserve cache reuse for dependency work when source changes. | Does not erase existing image-layer bytes. |
| Use a multi-stage build | Keeps build-only tools and intermediate artifacts out of the final runtime image when they are not copied into it. | Does not automatically optimize cache ordering in every stage. |
Use COPY --link in a supported workflow |
Can make copied-file layers independent of preceding layers and reusable across changes to them. | Does not clean up files already recorded in earlier layers. |
These techniques solve different problems: retained image contents, rebuild reuse, or separation of build and runtime environments. Docker’s cited official documentation does not publish a general numeric estimate for image-size or build-time savings specifically attributable to avoiding layer duplication.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
