Podman Save, Load, Export and Import Explained

Podman offers four archive commands that look similar but operate on different inputs. podman save and podman load move complete images. podman export and podman import move flattened container filesystems. Picking the wrong pair is the most common mistake — this page shows both workflows with real output.

Podman save vs export vs load vs import

Image transfer pair:

IMAGE → podman save → image archive → podman load → same image structure

Container filesystem pair:

CONTAINER → podman export → flattened root filesystem tar → podman import → new image

podman export operates on a container filesystem, not an image archive. That distinction drives every command choice below.

Use the image pair when you need the same tag, layers, and history on another host. Use export + import when you want to capture a container's current root filesystem as a new flattened image. For data that requires application-consistent backup, stop or quiesce the workload first and back up persistent storage separately — not when you simply need to copy an existing image.

Save a Podman image to a tar archive

Pull a small test image and inspect its layer history before archiving:

podman pull quay.io/podman/hello

After the pull finishes, read the layer stack you are about to archive:

podman history quay.io/podman/hello

Sample output:

ID            CREATED      CREATED BY                                     SIZE
5dd467fce50b  2 years ago  /bin/sh -c #(nop) CMD ["/usr/local/bin/pod...  782kB
<missing>     2 years ago  /bin/sh -c #(nop) COPY file:dcd0ec8c82666e...  0B
<missing>     2 years ago  /bin/sh -c #(nop) LABEL io.containers.capa...  0B

Write the image to a tar file:

podman save -o demo-image.tar quay.io/podman/hello

Confirm the archive exists:

ls -lh demo-image.tar

Sample output:

-rw-r--r--. 1 root root 776K Aug 22 22:32 demo-image.tar

podman save preserves image layers, configuration, tags, and the build history you saw in podman history. The archive is self-contained: you can copy it to offline media, load it on another machine, and run containers from the restored tag without contacting the original registry.

Load a saved Podman image

Remove the local copy so the next step proves load restores it:

podman rmi quay.io/podman/hello

Import the archive back into local storage:

podman load -i demo-image.tar

Sample output:

Getting image source signatures
Copying blob sha256:2114fc8b70586b9325dde6fd26066d9951414dcdfb3995f41d51d1995cf3bd9d
Copying config sha256:5dd467fce50b56951185da365b5feee75409968cbab5767b9b59e325fb2ecbc0
Writing manifest to image destination
Loaded image: quay.io/podman/hello:latest

The tag quay.io/podman/hello:latest returned with the image. History is intact:

podman history quay.io/podman/hello

Sample output:

ID            CREATED      CREATED BY                                     SIZE
5dd467fce50b  2 years ago  /bin/sh -c #(nop) CMD ["/usr/local/bin/pod...  782kB
<missing>     2 years ago  /bin/sh -c #(nop) COPY file:dcd0ec8c82666e...  0B
<missing>     2 years ago  /bin/sh -c #(nop) LABEL io.containers.capa...  0B

The layer stack matches what you saved — that is the practical difference from podman import.

Podman save formats

podman save supports several output formats:

The default is docker-archive. Save in OCI archive format when a downstream tool expects OCI layout inside the tar:

podman save --format oci-archive -o demo-oci.tar quay.io/podman/hello

Check the OCI archive size:

ls -lh demo-oci.tar

Sample output:

-rw-r--r--. 1 root root 340K Aug 22 22:32 demo-oci.tar

Use docker-dir or oci-dir when you need an unpacked directory tree instead of a single tar file.

Save multiple Podman images in one archive

Bundle more than one image into a single tar for air-gapped transfer:

podman save --multi-image-archive -o images.tar quay.io/podman/hello registry.access.redhat.com/ubi9/ubi-minimal:latest

Multi-image archive mode works with docker-archive only. Load restores every image in the bundle:

Remove both images locally so the reload is visible:

podman rmi quay.io/podman/hello registry.access.redhat.com/ubi9/ubi-minimal:latest

Restore the bundle with one load command:

podman load -i images.tar

Sample output:

Loaded image: quay.io/podman/hello:latest
Loaded image: registry.access.redhat.com/ubi9/ubi-minimal:latest

Both tags reappear in podman images after a single load.

Transfer images to an air-gapped host

On a host with registry access, pull the image first:

podman pull quay.io/podman/hello

Write it to a portable tar archive:

podman save -o hello.tar quay.io/podman/hello

Copy hello.tar to the isolated host with your approved transfer method (USB, internal file share, etc.). On the air-gapped host:

podman load -i hello.tar

Verify:

podman images quay.io/podman/hello

save + load moves the complete image without a registry. When both hosts can reach a registry, pushing to a registry is usually simpler than shuttling tar files.

Export a Podman container filesystem

podman export archives a container's root filesystem, not an image. Create a container and change its filesystem:

podman run --name export-demo registry.access.redhat.com/ubi9/ubi-minimal:latest /bin/sh -c "echo marker > /tmp/export-marker.txt"

Export the container to a tar archive:

podman export -o container-filesystem.tar export-demo

List the archive contents — this is a root filesystem tree, not an image manifest:

tar -tf container-filesystem.tar | head

Sample output:

afs/
bin
boot/
dev/
dev/null
etc/
etc/GREP_COLORS
etc/X11/

Export flattens the filesystem into a single tar stream. Image layer history and tags are not preserved as image metadata — only the files that existed in the container root at export time.

Remove the container when you no longer need it; export does not delete the original container or image:

podman rm export-demo

Import a container filesystem as a new image

Turn the exported tar into a new image:

podman import container-filesystem.tar localhost/imported-demo:v1

Sample output:

sha256:e07684c1fa46f8c18db4f59ccded1ace5b7c69914151c4ac3e928ad2c63d702c

Compare history with the original UBI image:

podman history registry.access.redhat.com/ubi9/ubi-minimal:latest

Sample output:

ID            CREATED     CREATED BY                                     SIZE
b07998aa2396  5 days ago  /bin/sh -c #(nop) LABEL "org.opencontainer...  109MB
<missing>     5 days ago  /bin/sh -c #(nop) COPY dir:65a3d9e22af3e56...  0B

Now the imported image:

podman history localhost/imported-demo:v1

Sample output:

ID            CREATED        CREATED BY                                     SIZE
e07684c1fa46  2 seconds ago  /bin/sh -c #(nop) ADD file:3acd912dcb0649b...  109MB       imported from tarball

One layer labeled imported from tarball — the original build steps are gone.

Add image configuration during podman import

The tar contains only a filesystem. Set runtime configuration with --change:

podman import --change 'CMD ["/bin/cat", "/tmp/export-marker.txt"]' container-filesystem.tar localhost/imported-demo:v2

Run the new image to confirm the marker file survived export:

podman run --rm localhost/imported-demo:v2

Sample output:

marker

Supported --change directives include CMD, ENTRYPOINT, ENV, EXPOSE, LABEL, STOPSIGNAL, USER, VOLUME, and WORKDIR. Add only what the imported filesystem needs to run.

Podman save vs export

If you want to move the same container image to another Podman host, use save + load. Do not use export + import as a substitute for image transfer.

Podman load vs import

Feeding a container export tar to podman load fails with a format error:

podman load -i container-filesystem.tar

Sample output:

Error: payload does not match any of the supported image formats:
 * oci: open container-filesystem.tar/index.json: not a directory
 * docker-archive: loading tar component "manifest.json": file does not exist

Running podman import on a podman save tar may appear to succeed but produces a wrong single-layer image, not the original tagged image. On the lab host, importing a docker-archive save created a 794 kB image instead of restoring quay.io/podman/hello with its full history. Always match the command to how the tar was created.

What these commands do not back up

Image and container filesystem archives do not include everything an application needs:

• Named volumes and their data
• Bind-mounted host directories
• External databases or object stores

A database in a named volume survives container deletion but is not inside podman save output. Bind mounts point at host paths that are never part of the image tarball. Plan separate data backup for persistent storage — see Podman volumes for volume concepts.

Checkpoint and restore, registry signing, and Skopeo-based registry copies are separate transfer mechanisms outside this save/load versus export/import scope.

References

• podman-save man page
• podman-load man page
• podman-export man page
• podman-import man page

Summary

podman save and podman load form the image-transfer pair. They preserve layers, tags, and podman history output across hosts — including air-gapped systems that cannot reach a registry. podman export and podman import form the container-filesystem pair. Export captures a flattened root tree; import wraps it in a new single-layer image with no original build history.

The comparison table at the top is the decision guide: image in, image out → save/load; flattened container filesystem → export/import. Default save format is docker-archive; use --multi-image-archive to bundle several images for one transfer. Neither pair backs up volume data — image archives and application data are separate concerns.

When both hosts have registry access, push and pull are usually easier than tar shuttling. When they do not, save + load is the correct complete-image workflow. For a single modified container you want to turn into a reusable image without its build chain, export + import with --change is the right tool — just expect a flat history afterward.