1.2.2.2 Application Binary Packaging

Application binary packaging is the process of including a compiled, executable artifact inside a Docker image, so that the image's container can run the application directly without needing to compile it on the target machine.

Compiling Once, Running Anywhere the Image Goes

For compiled languages such as Go, Rust, or C++, the application exists as a binary file produced by a build step. Packaging that binary into an image means the compilation step happens once, at build time, and every machine that later runs the image executes the same already-compiled binary rather than recompiling from source.

FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o app .

FROM scratch
COPY --from=build /src/app /app
ENTRYPOINT ["/app"]

Using scratch as the final base image produces an image containing literally nothing except the compiled binary, since a statically linked Go binary has no further runtime dependencies.

Why Binary Packaging Produces Small, Fast Images

Because the final image does not need a language runtime, a package manager, or any build tooling, it can be extremely small and starts almost instantly, which is valuable when many container instances need to start quickly, such as during autoscaling.

docker images myapp
docker run --rm myapp

Packaging Binaries With Required Shared Libraries

Not every compiled binary is fully static. If a binary depends on shared libraries, the runtime image must include them, or the binary will fail to start with a missing-library error.

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y libssl3
COPY --from=build /src/app /usr/local/bin/app
ENTRYPOINT ["app"]

Verifying What a Packaged Binary Needs

Before finalizing a runtime image, it is useful to confirm exactly which shared libraries the binary requires, so the runtime base image can be chosen or configured to include them.

ldd app

A binary reporting "not a dynamic executable" is fully static and needs nothing further from the image; a binary listing several .so files needs each of them present in the final image.

Cross-Compiling for the Target Platform

Because the binary must match the architecture and operating system of the container's eventual runtime environment, cross-compilation flags are often used when building on a different platform than the one the container will run on.

GOOS=linux GOARCH=amd64 go build -o app .