Extracting binary from other images Vs installing from scratch when building Docker images
type
Post
status
Published
date
Feb 11, 2026
slug
docker-binaries-from-other-images
summary
Extracting binary from other images Vs installing from scratch
tags
Docker
development
programming
category
icon
password
Importance
Tweet
Benefits
- Faster builds since I am not compiling or installing packages myself.
- Smaller final image because I can keep the runtime stage minimal and avoid bundling build tools.
- More predictable and reproducible results when the source image is pinned by digest.
Shortcomings
- Compatibility can break, especially when mixing binaries from Alpine (musl) with a Debian or distroless runtime (glibc).
- Hidden runtime dependencies can be missing in the final image, such as shared libraries, CA certificates, timezone data, or small utilities.
- Security updates are easier to miss because I need to track patches in the source images I copy from, not only the final base image.
- Provenance is less explicit, which can make auditing and debugging harder.
- Licensing and notice files can be overlooked when copying only a single binary.
Requirements
- Only works with self-contained binary, binaries with statically linked libraries would require more effort