---
title: "Discussion on \"What Should Actually Ship in Your Production Docker Image?\" | Hashnode"
description: "Discussion on \"What Should Actually Ship in Your Production Docker Image?\". Try this on the last image you shipped:\ndocker run -it --entrypoint sh <your-image>\n\nNow look around. In many images you'll find a package manager, compilers, your full source code, test files, and so"
url: "https://hashnode.com/posts/what-should-actually-ship-in-your-production-docker-image/6aea1ee27d420db0d8975f27"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [What Should Actually Ship in Your Production Docker Image?](https://pawarvaishnavi.hashnode.dev/what-should-actually-ship-in-your-production-docker-image?utm_source=hashnode&utm_medium=feed)

Try this on the last image you shipped: docker run -it --entrypoint sh <your-image> Now look around. In many images you'll find a package manager, compilers, your full source code, test files, and so

Nov 3 · 8 min read · pawarvaishnavi.hashnode.dev  
Read the article

-   [#docker](https://hashnode.com/tag/docker)
-   [#devops](https://hashnode.com/tag/devops)
-   [#dockerfile](https://hashnode.com/tag/dockerfile)
-   [#docker-security](https://hashnode.com/tag/docker-security)

## Written by

[vaishnavi](https://hashnode.com/@pawarvaishnavi)

@pawarvaishnavi

  
[View profile](https://hashnode.com/@pawarvaishnavi)

## Responses 1

Markdown supported · ⌘↵ to post

[AI Developer](https://hashnode.com/@lycore)

[Nov 4](https://hashnode.com/posts/what-should-actually-ship-in-your-production-docker-image/6aea1ee27d420db0d8975f27/comment/6aeaa0f958a5341faab6ae27)

One addition on the secrets point: a BuildKit secret mount keeps the value out of layers, but it's worth confirming with docker history and by exporting the image that nothing like a .npmrc or pip config got copied in by a broad COPY step, which is where .dockerignore earns its keep. On non-root, a common failure is a read-only root filesystem or volume ownership mismatch once USER is switched, so running the container with --read-only and a tmpfs for the writable paths is a cheap way to find what the app really needs to write. For pinned digests, a CI step that fails when the base image is older than some number of days would stop pinning from quietly turning into never patching. Do you think distroless is worth the debugging cost for teams that don't already have ephemeral debug containers (kubectl debug or docker debug) set up?