docker load·save·run으로 보는 이미지 로드와 실행

When transferring images without a registry, use docker save and docker load: they preserve every layer, the full history, and all tag metadata. Use docker export and docker import only when you need a flattened snapshot of a container’s filesystem. Once an image is loaded into the local store, it follows the exact same execution path as a pulled image — docker run picks it up and launches a container. This is part 2 of 4 in the Docker series. Part 1 covered process isolation with namespaces and cgroups; part 3 will cover the overlay2 storage driver in depth.

This article is a general overview based on Docker’s official CLI documentation. Behavior can vary with the engine version and image store configuration (classic storage driver vs. the containerd image store).

What does docker save preserve, and what does docker load restore?

Short answer: docker save packages one or more images into a tar archive that includes all layers, history, and tag metadata. docker load restores that archive into the local image store, reusing any layers that already exist locally.

When you run docker save, Docker writes a tar archive that contains the following information for each image.

Layers: Every filesystem layer that corresponds to a Dockerfile instruction (such as RUN or COPY) is preserved as a separate entry in the archive.
History: The metadata describing which command created each layer is retained, keeping docker history output intact after a load.
Repository and tag information: The image name and tag are recorded in the repositories file and manifest.json inside the archive.

docker load reads a tar produced by docker save (plain or gzip-compressed) and registers all contained images in the local store. If a layer with the same digest already exists locally, it is reused rather than stored again. After a successful load, the image appears in docker images with its original repository name and tag.

The relationship with pull and push: when a registry is accessible, docker pull and docker push are the standard path. When a registry is not available, the docker save → file transfer → docker load path is the recommended approach for moving images.

How do docker export and import differ from docker save and load?

Short answer: docker export and docker import produce a flattened, single-layer image from a container’s filesystem. They do not preserve layer history, and mounted volume data is not included.

The table below summarizes the key differences.

Attribute	`docker save` / `docker load`	`docker export` / `docker import`
Source object	Image	Container (running or stopped)
Layer preservation	✅ All layers preserved	❌ Flattened into a single layer
History preservation	✅ Full Dockerfile history retained	❌ History lost
Tag preservation	✅ Repository and tag included	❌ No tag by default (must be specified at import)
Volume data	N/A (image-level operation)	❌ Mounted volume contents not included (official behavior)
Build cache benefit	✅ Layer cache can be reused	❌ Reduced; single layer means no incremental cache
Primary use case	Image transfer, backup, offline delivery	Container rootfs snapshot, image flattening

Two points are worth emphasizing.

docker export targets a container, not an image. It exports the container’s merged filesystem view as a tar. According to the official documentation, data inside mounted volumes is not included in the export.
docker import creates a single-layer image. Importing a tar — whether from docker export or any other rootfs tarball — collapses everything into one layer. This destroys the multi-layer structure and eliminates the incremental build-cache advantage of the original image.

Rule of thumb: Image transfer → save/load. Container rootfs snapshot or image flattening → export/import. Mixing the two paths breaks reproducibility and build-cache efficiency.

What happens when you docker run a loaded image?

Short answer: An image restored by docker load is treated identically to one fetched with docker pull. docker run adds a writable container layer on top of the read-only image layers and starts the specified process.

Once docker load completes, the image is registered in the local image store. From that point, docker run proceeds through the following steps.

Image lookup: Docker queries the local image store for the specified name and tag. An image restored with docker load is found here without any additional steps.
Container creation: containerd and runc construct a filesystem view that layers a writable container layer on top of the read-only image layers. The detailed mechanics of this layering (overlay2 lowerdir, upperdir, and so on) are covered in part 3 of this series.
Process start: runc applies the namespaces and cgroups configuration and executes the specified command. The isolation and resource-limit model is the same as described in part 1.

In short: docker load is the image-preparation step, and docker run is the process-start step. The path by which the image was prepared — pull, load, or local build — has no effect on how docker run executes it.

Tags, multi-image tarballs, and stdin/stdout pipes: how do you use them?

Short answer: docker save and docker load support stdin/stdout piping, the -o/-i flags, gzip compression, and packing multiple images into a single tar.

Stdout pipe with gzip compression

docker save writes a tar stream to stdout by default. You can pipe it through gzip before saving to disk.

# Save and compress in one step
docker save myimage:latest | gzip > myimage.tar.gz

# Load a gzip-compressed tar (docker load detects compression automatically)
docker load < myimage.tar.gz

According to the official documentation, docker load automatically detects whether the input is gzip-compressed. You can pass a .tar.gz file directly without decompressing it first.

The -o and -i flags

Use these flags when you prefer an explicit file path over shell redirection.

# Explicit output file (save)
docker save -o myimage.tar myimage:latest

# Explicit input file (load)
docker load -i myimage.tar

Multiple images in a single tarball

docker save accepts multiple image arguments, packing all of them into one archive.

# Save three images into one tar
docker save -o multi.tar ubuntu:22.04 alpine:latest nginx:stable

# Load all three at once
docker load -i multi.tar

Running docker load on a multi-image tar restores all contained images to the local store in a single operation.

Saving by image ID instead of name

If you save using an image ID rather than a named tag (for example, docker save <IMAGE_ID>), the repository and tag fields in the archive may be empty. After loading, the image appears as <none>:<none>. See the next section for how to resolve this.

When an image appears to be “missing”: how to check load, tag, and run in order

Short answer: If a loaded image shows up as <none>:<none>, find its ID with docker images, assign a proper name with docker tag, and then run it.

Symptoms

After running docker load, attempting docker run myimage:latest results in Unable to find image 'myimage:latest' locally, or the image appears in docker images with <none> for both the repository and tag columns.

Root causes

Mixing up docker import and docker load: If an export-produced tar was loaded with docker import without specifying a tag, the resulting image has no name.
Saving by image ID: Using docker save <IMAGE_ID> instead of docker save <name>:<tag> results in a tar that carries no repository or tag metadata. After loading, the image appears as <none>:<none>.

Resolution steps

List images to find the ID
```
docker images
```
Locate the <none>:<none> row and note the value in the IMAGE ID column (for example, a1b2c3d4e5f6).
Assign a name with docker tag
```
docker tag a1b2c3d4e5f6 myimage:latest
```
Run the image
```
docker run myimage:latest
```

Prevention

Specify the full image name and tag when saving.

# Recommended: always save by name:tag
docker save -o myimage.tar myimage:latest

When using docker import, append the repository and tag at the end of the command.

docker import payload.tar myimage:latest

FAQ

Short answer: Common questions about docker save, docker load, docker export, and docker import.

Question	Answer
Can I specify a repository and tag when running docker import?	Yes. Append `repository:tag` at the end: `docker import payload.tar repository:tag`. Without it, the image is created as `<none>:<none>`.
Does docker export include data from mounted volumes?	No. According to the official documentation, data inside mounted volumes is not included in a `docker export`. Volume data must be backed up separately.
Are `docker load -i file` and `docker load < file` equivalent?	Yes, the result is the same. The `-i` flag explicitly names an input file; the `<` redirection connects stdin to the file in the shell. Both forms detect gzip compression automatically.
Is stdout redirection without `-o` acceptable for saving?	Yes. `docker save myimage:latest > myimage.tar` and `docker save -o myimage.tar myimage:latest` produce the same result. The pipe form is more convenient when gzip compression is also needed.
Can I load only one image from a multi-image tar?	The standard `docker load` command loads all images in the archive at once. To load selectively, extract individual image layers from the tar manually or save images into separate archives from the start.

References

Short answer: Facts in this article are drawn from Docker’s official CLI documentation checked on 2026-09-14.

docker image load — Docker Docs — Used to verify input format, gzip auto-detection, and the -i option for docker load.
docker image save — Docker Docs — Used to verify layer, history, and tag preservation behavior, the -o option, and multi-image saving.
docker image import — Docker Docs — Used to verify the single-layer image creation behavior and repository:tag specification.
docker container export — Docker Docs — Used to verify that mounted volume contents are not included in an export.
Run containers — Docker Docs — Used to verify the docker run workflow and container creation path.