Inspect the files and layers in a Docker image

Choose the method according to what you need: the merged filesystem, the image's configuration, or the changes stored in individual layers. These are different views of an image.

Open a shell when the image contains one

docker run --rm -it --entrypoint /bin/sh myimage:1.2

Then inspect paths such as /app or /etc/os-release. Overriding the entrypoint matters: appending sh after the image name can otherwise pass it as an argument to the image's existing entrypoint. The image must contain the selected shell, and executing it runs code from that image.

The temporary container's writable layer is removed when it exits because of --rm. Its mounted storage has its own lifecycle; do not attach production data casually for image inspection.

Inspect without starting a process

Create a container, export its merged filesystem, then remove the inspection container:

cid=$(docker create --entrypoint /__inspect_only__ myimage:1.2) || exit 1
docker export --output fs.tar "$cid"
docker rm -v "$cid"
tar -tf fs.tar

The placeholder executable is intentionally never started; it supplies a command even for images with no default startup command. docker create does not require it to execute. Use a fresh output location and check export success before relying on the archive. The -v removes anonymous volumes created for this temporary inspection container.

For a trusted archive, extract into a new inspection directory:

mkdir image-files
tar -xf fs.tar -C image-files

Export excludes mounted volume data. If a volume obscures an image directory, export exposes the underlying directory's filesystem view, not the mounted contents. It also omits image history and much configuration; it is not an image-preserving substitute for docker save.

Inspect history and layers

docker image history myimage:1.2
docker image history --no-trunc myimage:1.2

History helps explain build steps and size, but it is not a complete file inventory or a guaranteed reconstruction of the original Dockerfile. Metadata-only instructions do not necessarily create filesystem layers, and imported or squashed images can have different histories. A file deleted in a later layer may remain in earlier layer content even when it is absent from the final filesystem.

For an interactive layer view, the independent dive tool can show changes and potential wasted space:

dive myimage:1.2

Install a reviewed release compatible with your image source. docker image save also lets you inspect image layer archives and metadata, but archive layout varies by format/version. Correctly combining layers requires honoring deletion markers and ordering; simply extracting every tar file on top of another is not a reliable generic reconstruction algorithm.

Inspect configuration only

docker image inspect myimage:1.2

This reports image metadata such as environment, entrypoint and declared ports. Treat output as potentially sensitive if credentials were mistakenly baked into the image.

FAQ

What if there is no sh? Use create/export, copy selected files from a created container, or another tool that understands the image format. Choosing --entrypoint cannot create an executable absent from the image.

How do save and export differ? Save preserves image layers and configuration for loading as an image. Export emits a flattened container filesystem, including its writable changes if any, while excluding volume contents.

How do I see one layer's additions? Use a layer-aware explorer or examine the saved layer archives with their metadata. History gives context but does not list every added or removed file.

See Creating a container without starting it, Container filesystem export, Image history, dive image explorer.