What Should Actually Ship in Your Production Docker Image?

vaishnavi — Tue, 03 Nov 2026 17:50:26 GMT

Try this on the last image you shipped:

docker run -it --entrypoint sh

Now look around. In many images you'll find a package manager, compilers, your full source code, test files, and sometimes a stray .env. None of it helps your application run, and all of it helps an attacker.

Your application may work perfectly on your machine and pass every test. But a production-ready Dockerfile is about more than getting the application to run. It is about deciding what gets built, what gets shipped, and how the application runs.

Here are nine practices that help you make those decisions well. They apply to any language or framework, so you can use them with whatever stack you build on.

1. Use Multi-Stage Builds

Building an application often requires tools that running it does not: compilers, build dependencies, and package managers. These belong in the build process, not necessarily in production.

Multi-stage builds separate these concerns. One stage builds the application, while another contains only what is needed to run it.

# Build stage
FROM  AS build
WORKDIR /app

COPY   ./
RUN 

COPY . .
RUN 

# Runtime stage
FROM 
WORKDIR /app

COPY --from=build  
CMD ["", ""]

Anything left in the build stage does not reach the final image unless you explicitly copy it. This keeps build tools and other unnecessary components out of the runtime image.

The image names, commands, and paths above are placeholders. Replace them with the values your application needs.

2. Choose Minimal, Pinned Base Images

Your base image provides the environment your application runs in. Choose a trusted image that includes the runtime and libraries your application needs, without unnecessary tools or packages.

Use trusted sources: Prefer Docker Official Images, verified publisher images, or Docker Hardened Images.
Prefer smaller variants: A slim or alpine image has fewer components to patch than a full OS image.
Consider distroless for the final stage: Distroless images contain only the runtime and its dependencies, without a shell or package manager. This reduces the attack surface, but makes debugging harder.
Pin the version: Floating tags like latest can change between builds. Pin a specific version or digest for predictable builds.

FROM :@sha256:

The digest is a placeholder. Use the real digest of your chosen image. When both are specified, Docker uses the digest to select the image; the tag is there for readability.

A pinned image won't receive security fixes automatically. Use tools like Dependabot or Renovate to open pull requests when a new version or digest is available, and rebuild regularly.

3. Use Layer Caching Effectively

Docker stores the result of build steps in a cache and can reuse them when their instructions and inputs remain unchanged. If a step changes, the steps after it may need to run again.

To avoid unnecessary rebuilds:

Order instructions carefully: Place steps that change less often before steps that change frequently.
Keep expensive steps early: Steps such as installing system packages or dependencies can take time. Arrange the Dockerfile so unrelated changes do not invalidate them unnecessarily.
Keep the build context focused: Use .dockerignore to exclude files that the build does not need. Unnecessary files can cause cache invalidation when they change.

For example, copy dependency manifests and install dependencies before copying frequently changing source code. This way, changing application code does not normally trigger dependency installation again.

Effective caching reduces repeated work and makes builds faster.

4. Ship Only What the Application Needs at Runtime

The final image should contain what the application needs to run, not everything used to build it.

Include only runtime files: A compiled application needs its binary or JAR. An interpreted application needs its source code and production dependencies.
Leave build tools behind: Compilers, test frameworks, and development dependencies are needed to build the application, not to run it.
Copy only what is required: In a multi-stage build, use COPY --from=build to bring specific files into the final stage, rather than the whole build directory. Everything else stays behind.
Clean up installation files: Package managers leave downloaded package lists and caches behind. Remove them in the same RUN instruction that creates them.

The goal is to keep the final image focused on what the application actually needs to run.

5. Run as a Non-Root User

Containers run as root unless you configure another user. If an attacker compromises your application while it runs as root, they may have more permissions inside the container than the application needs.

Create an unprivileged user and switch to it:

# Debian-based image
RUN useradd --system --uid 10001 appuser

# Alpine-based image
RUN adduser -S -u 10001 appuser

USER 10001

The commands above are alternatives for different base images, not instructions to run together. Make sure the user exists and has permission to access the application files before switching to it. Some Distroless and hardened images already provide a non-root user, so check the image before creating another user.

Running as non-root does not replace other security controls, but it helps limit the impact of a compromised application.

6. Handle Secrets Securely

Passwords, API keys, and tokens should never be written directly into a Dockerfile or included in the image. A secret stored in an image layer can be extracted by anyone who can pull the image, even if a later instruction deletes it.

At build time: Avoid passing secrets through ARG or ENV. If a build step needs a secret, such as a private registry token, use a BuildKit secret mount. It makes the secret available to that step without storing it in the image.
At runtime: Store production secrets, such as database credentials, in a secret manager and provide them to the container when it runs. For example, AWS ECS can retrieve secrets from AWS Secrets Manager.

Keep secrets separate from the image, give each service access only to the secrets it needs, and never log them.

7. Use a .dockerignore File

When you run docker build, Docker sends the build context to the builder. Without a .dockerignore file, it may include Git history, local environment files, and dependency folders from your machine.

A broad COPY . . can then copy unwanted files into the image.

.git
.env
.env.*
node_modules
target
dist
coverage
*.log

This is an example, not a universal list. Adapt it to your project and make sure you do not exclude files the build actually needs.

A good .dockerignore keeps the build context focused, reduces unnecessary data transfer, and helps prevent local files from being included by mistake.

8. Use Exec Form for CMD and ENTRYPOINT

RUN executes commands while building the image. CMD and ENTRYPOINT define what starts when the container runs.

Use CMD when you want to set a default command that can be replaced when the container starts.
Use ENTRYPOINT when the image should always start with a particular application or command. You can use CMD to provide its default arguments.

Both support shell form and exec form:

# Exec form
CMD ["", ""]
ENTRYPOINT ["", ""]

# Shell form
CMD  
ENTRYPOINT

With exec form, the application runs directly as PID 1 inside the container. When you run docker stop, Docker sends SIGTERM to PID 1, giving the application a chance to finish active requests and close connections before it exits.

With shell form, the command runs through a shell, which becomes PID 1. The application runs as a child process, and the shell does not forward Docker's stop signal to it by default. As a result, the application may not receive SIGTERM, so the application may not shut down gracefully.

For production, use exec form for the startup command and ensure the application handles SIGTERM properly.

9. Scan the Image for Vulnerabilities

Even a well-written Dockerfile can include software with known security vulnerabilities. Scan your Docker image before deploying it to identify vulnerable operating-system packages and application dependencies.

Review scan findings based on their severity, whether a fix is available, and whether the affected component is relevant to your application. Updating the base image or application dependencies can often resolve vulnerabilities.

Scanning is not a one-time task. Include it in your CI pipeline and rebuild images regularly, as new vulnerabilities and security fixes are discovered.

Conclusion

Remember the image you explored at the start of this article? Run the same command on your next build and look around again. A well-written Dockerfile should leave much less unnecessary software and fewer security risks behind.

A production-ready Dockerfile is about choosing what your application needs to build, what it needs to run, and what permissions it should have. Multi-stage builds, minimal pinned images, secure secret handling, and regular scanning help make your containers safer and easier to maintain.

You don't need to apply everything at once. Pick one habit your current Dockerfile is missing and fix it today. Each one makes your image a little smaller, safer, and easier to maintain, and they add up quickly.