Scratch

An application that needs very few runtime files may not need a Linux distribution inside its container image. Docker’s special scratch starting point lets you build an image from an empty filesystem and copy in only the executable and its required files. This can avoid unnecessary packages, but it does not supply libraries, certificates, users or debugging tools for you. Check those requirements explicitly, and remember that vulnerabilities can still exist in the application and its compiled dependencies.

Current guidance

Docker documents it as a reserved name that makes the next image instruction create the first filesystem layer; it cannot be pulled or run like an ordinary image. It suits an executable that can operate with exactly the files copied into the image, not every program that happens to compile successfully.

A dynamically linked executable may require a loader and libraries. TLS clients may require trusted certificates, while applications may need timezone data, user identity files or writable directories. Make these requirements explicit and verify them in the final container. A small filesystem can reduce unnecessary components, but it does not remove vulnerabilities in the executable or its statically linked dependencies.

For adoption, test startup, DNS, HTTPS, file permissions, termination and health checks as a non-root user under the intended Kubernetes security settings. Keep build provenance and an inventory of application dependencies because an operating-system package scan alone provides little visibility. Plan debugging and incident collection separately rather than adding an interactive shell to every production container by default.