in Allgemein

Flatten a Docker container or image

Docker containers and respectively images can become fairly large. I recently worked with a Docker image which was over 7 GB big. However, it is pretty easy to flatten an image at the end.

Difference between save and export

As I described in my last post (, there are two ways to persist a Docker images or container:

  • A Docker image can be saved to a tarball and loaded back again. This will preserve the history of the image.

  • A Docker container can be exported to a tarball and imported back again. This will not preserve the history of the container.

No history

We can use this mechanism to flatten and shrink a Docker container. If we save an image to the disk, its whole history will be preserved, but if we export a container, its history gets lost and the resulting tarball will be much smaller.

We can see the history of a image be running docker tag <LAYER ID> <IMAGE NAMEgt;:

So if we export a container (either an already running one or just start a new one from an image) it will lose its history and all previous layers. This will make it impossible to make a rollback to a certain layer, but it will also shrink the image. My >7 GB image is now >3 GB large, which saves more than 50% of disk space.

Flatten a Docker container

So it is only possible to “flatten” a Docker container, not an image. So we need to start a container from an image first. Then we can export and import the container in one line:

What else?

You can use some common Linux tricks to shrink Docker images. One simple trick is to clear the cache of the package manager. So depending on which base image you use you can do something like this (for an Ubuntu/Debian system, for more see here):


Best regards,

  • this is good !!
    I was actually searching how to reduce an image size after having clean the projects that i was building.

  • Bill

    Unfortunately, these steps will cause your flatten docker to forget all of the options specified in the Dockerfile. The user to run as, default command, environmental variables, ports to exports, volumes, etc. Not to say it wouldn’t be possible to restore these values, it would just be a real pain in the neck.

    I have a docker I’m using to run a postscript database. It is build from metadata and api data from There is a sync process I wrote that reinitializes if it is erased. But currently that takes about 18 hours… Once a day I run a process that takes about 10 minutes to sync salesforce data into the database. At that time I do a commit and restart the container running the database. So if the system is rebooted I’m never too far out of sync.

    Now, as you can guess this means slowly the datastore grows with ongoing daily history. It would be nice to have a way to prune that history.

    There are two ways to sort of do what I want.
    1. I could use docker-cp to copy the postgres data folder to local disk, and then load that into a freshly created image, so there would be no extra history.
    2. I could use your import – export method as a parent for a Dockerfile.

    Both of these are more complicated than I would like, especially since I do want to keep the most (1 week) of history.

  • Pingback: Linux containers, Docker and CoreOS | Rui's Blog()


    I just created a script I call docker-rebase, which does the added step of inspecting the container’s original image and setting all the settings from the original Dockerfile.


    Oh, one issue to be aware of when using large images, both docker save and docker export will use a huge amount of /tmp space. So if you are trying to flatten a 7 GB image, and your tmp is a memory mount that is say 4 GB, you’ll simply wait a long time and then watch your operation crash and burn. You might be able to change the directory these commands use with the TMPDIR environmental variable, or you might need to find the appropriate systemctl command. I usually just remount my /tmp folder to a directory that can handle creating much larger files.

  • Pingback: Flatten a Docker container or image | narenbabuin()

  • Pingback: Minimal docker : run your NodeJS app in <25mb of an image | Dinesh Ram Kali.()

  • shaytac

    To add to @disqus_TToLbD5lNi:disqus’s point you wont gain much of space anyways.