I'm comfortable with Docker now, but I come from a virtualization background and am still figuring out the right production workflow. With virtual machines, I'm used to downloading an ISO directly from a project's official website, verifying it, and installing it on a hypervisor. Docker examples, on the other hand, commonly start with a base image such as `FROM ubuntu:24.04` pulled from a public image registry.
Is it normal to trust and use official base images when building production containers, or should I be creating images from software vendor ISOs or other original distribution files? I'm also curious about the usual approach to supply-chain security: version tags versus image digests, vulnerability scanning, private registries, image signing, and mirroring approved images internally.
I've heard about custom, minimal, and distroless images as well. What would be a sensible workflow for someone who is primarily focused on infrastructure rather than application development?
5 Answers
The deployment platform depends more on scale than on the image source. For a few services on one host, Compose with a reverse proxy may be enough. A small team with several hosts might use another lightweight orchestrator, while larger or more complex environments may justify Kubernetes.
Regardless of the orchestrator, the important production basics are similar: automated image builds, vulnerability scanning in CI, centralized logs, backups, health checks, secrets management, and a tested rollback plan. The image itself is only one part of production readiness.
You’re mostly comparing two different packaging formats. A Linux ISO is still something you have to trust, and it can contain vulnerabilities or be tampered with just like a container image. Official container images are often maintained or published by the same organizations that provide the corresponding operating systems and software.
A common production workflow is to use reputable official images, avoid floating tags such as `latest`, build your application image yourself, scan it for vulnerabilities, and copy the approved result into a private registry. That gives you control over exactly what gets deployed without requiring you to turn an ISO into a container.
If you’re concerned about relying on a public registry at deployment time, mirror the images into a registry you control. Your build pipeline can pull approved base images, verify signatures where available, scan them, and push both the base and application images to the internal registry. Production hosts then pull only from that registry.
Use explicit version tags for readability, but consider recording or pinning the image digest as well. A digest provides stronger reproducibility, although you need to account for platform-specific manifests when supporting architectures such as AMD64 and ARM64.
Image signing and signature verification can add another useful layer of confidence, especially when combined with a private mirror and vulnerability scanning. None of this removes the need to trust a publisher, but it makes the supply chain easier to control and audit.
Container images are made of fixed layers. Once an image has been built, it doesn’t silently install a newer dependency just because a newer version exists somewhere upstream. You can use a versioned base image, or pin it to an immutable digest when you need highly reproducible builds.
For application images, a multi-stage build is usually a good pattern: use a larger builder image to compile or package the application, then copy only the runtime files into a small final image. The final image might use a minimal Debian or Ubuntu base, a distroless image, or `scratch` if the application can run without operating-system files. Also consider running as a non-root user and publishing SBOMs and build attestations.
So the builder image and the runtime image can be separate, with only the application artifacts copied into the final stage. I’m going to experiment with that approach before worrying about building from an ISO.
Minimal images are useful, but don’t treat “smallest possible” as the only security goal. A distroless or `scratch` image can reduce the attack surface, but it may also make debugging and certificate or timezone management more complicated. Start with a well-maintained minimal runtime image, run the service as a non-root user, and make it smaller once you understand its runtime requirements.
That clears up the main thing I was unsure about. Using official images with explicit versions, scanning them, and keeping an approved copy internally sounds much more practical than trying to build containers from vendor ISOs.