Write Docker build artifacts outside temporary bind mounts

Bottom line: Decide where the generated artifact must survive before introducing a temporary build mount. Keep the mounted input path and intended output path visibly separate in the Dockerfile review and in the proposed verification.

Source fact: documented behavior

The Optimize cache usage in builds documentation is the primary reference.

The documented build bind mount exposes source files only for the RUN instruction; the example writes its generated artifact outside the mounted target. Build bind mounts are read-only by default, and adding rw does not preserve writes inside the mount after the instruction ends. A build mount temporarily hides existing contents of its target directory; those original contents return after the RUN instruction.

What the source does not establish

This article concerns temporary build inputs and output placement. It does not change the runtime bind-mount review, choose which final-stage files should be exported or prove that a generated executable works. Treat application acceptance, packaging and host-path access as separate requirements.

Applicability questions

• Which directory is the temporary input target?
• Where should the generated artifact remain after the instruction?
• Does the proposal write inside the mounted directory?
• Could existing target contents complicate what the build instruction sees?

DSE recommendation: mark the input and output paths explicitly

DSE recommends annotating the proposed build instruction with three paths: source input, temporary mount target and generated output. Have the build owner identify the required surviving file before changing the mount. Use the actual tool’s output configuration rather than assuming that its default output directory is suitable.

Compare the output path with the mount boundary. If the proposal enables writing inside the input mount, require a reason and keep that decision distinct from the artifact-retention requirement. Do not treat a writable mount option as a retention fix. Keep the intended surviving output at a reviewed location outside that temporary input target.

Inspect any pre-existing files at the target as part of the design review. Record which view the build step should consume and which files should be visible afterward. Avoid putting unrelated generated files and source inputs under one ambiguous path merely to shorten the command.

Reconcile artifact creation with later packaging in a separate step. Identify the next instruction that consumes the generated file and the intended final deliverable. Keep the temporary-mount test focused on whether the required output survived its instruction; use the existing exporter or runtime-dependency procedure for later acceptance. Preserve failures without changing several path decisions at once.

Verification and evidence

Proposed verification, not performed: use a disposable build context with harmless marker inputs. Create one controlled case that attempts a write under the temporary mount and another that writes the intended output outside it. Predict which files should remain after each instruction before inspecting the actual next-stage view.

Add a separate case with a harmless existing file beneath the target to inspect the mounted and restored views. Keep all locations confined to the disposable build. Retain the Dockerfile, mount options, output configuration and actual file observations. Check the generated artifact’s application behavior only through its separate approved acceptance plan.

Official references

• Optimize cache usage in builds — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.