if there are some custom image, e.g. additional stuff I added to an existing image, then I backup the dockerfile. you can rebuild the image anytime and the size is smaller than a binary.

Yep. I’ve got a bunch of apps that work offline, so I back up the currently deployed version of the image in case of hardware or other failure that requires me to re-deploy it. I also have quite a few custom-built images that take a while to build, so having a backup of the built image is convenient.

I structure my Docker-based apps into dedicated folders with all of their config and data directories inside a main container directory so everything is kept together. I also make an images directory which holds backup dumps of the images for the stack.

• Backup: docker save {image}:{tag} | gzip -9 > ./images/{image}-{tag}-{arch}.tar.gz
• Restore docker load < ./images/{image}-{tag}-{arch}.tar.gz

It will backup/restore with the image and tag used during the save step. The load step will accept a gzipped tar so you don’t even need to decompress it first. My older stuff doesn’t have the architecture in the filename but I’ve started adding that lately now that I have a mix of amd64 and arm64.

/apps/{app_name}/
    docker-compose.yml
    .env
    build/
        Dockerfile
        {build assets}
    data/
        {app_name}
        {app2_name}  # If there are multiple applications in the stack
        ...
    conf/                   # If separate from the app data
        {app_name}
        {app2_name}
        ...
    images/
        {app_name}-{tag}-{arch}.tar.gz
        {app2_name}-{tag}-{arch}.tar.gz

No. They are cached on the hosts, thats enough for me.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

[Thread #44 for this comm, first seen 30th Jan 2026, 12:50] [FAQ] [Full list] [Contact] [Source code]

Nope. Data directories and compose files only.

Yes I do. I cooked a small python script that runs at the end of every daily backup

import subprocess
import json
import os

# Output directory
OUTPUT_DIR = "/data/dockerimages"
try:
        os.mkdir(OUTPUT_DIR)
except:
        pass

# Grab all the docker images. Each line a json string defining the image
imagenes = subprocess.Popen(["docker", "images", "--format", "json"], stdout = subprocess.PIPE, stderr = subprocess.DEVNULL).communicate()[0].decode().split("\n")

for imagen in imagenes[:-1]:
        datos = json.loads(imagen)
        # ID of the image to save
        imageid = datos["ID"]
        # Compose the output name like this
        # ghcr.io-immich-app-immich-machine-learning:release:2026-01-28:3c42f025fb7c.tar
        outputname = f"{datos["Repository"]}:{datos["Tag"]}:{datos["CreatedAt"].split(" ")[0]}:{imageid}.tar".replace("/", "-")
        # If the file already exists just skip it
        if not os.path.isfile(f"{OUTPUT_DIR}/{outputname}"):
                print(f"Saving {outputname}...")
                subprocess.run(["docker", "save", imageid, "-o", f"{OUTPUT_DIR}/{outputname}"])
        else:
                print(f"Already exists {outputname}")

Yes. I run Harbor and pull all images through its proxy cache.

i selfhost a pullthrough docker repository, so every container I use is stored in there and can be pulled offline.

I do run my own forgejo container repo, and I mirror containers I need there.

But I don’t backup my containers, just the data directories I mount to them. 

I back up everything.

I mean…you have the container right there on your machine. If you’re concerned, just run your own registry and push copies there when needed. This of course is all unnecessary, as you only need the Dockerfile to build a clean image from scratch, and it will obviously work if it’s already been published.

I used to but then I switched out the server I was doing backups to and have been thinking “I’ll get to it later” for many months. If anything goes wrong I’m screwed. I’ll get to it later ¯_(ツ)_/¯

yes. all of the images I use are cached and stored in my locally hosted gitlab registry.

I think I’ve got around 120-140 images. a lot of what I have is just in case of an emergency.

I’ve always imagined I could build and run technological infrastructure after a social collapse or something, so I have a lot of images that could be a good basis to start with. Most OS images, popular DB images, etc. it would probably never work, but I’d rather have the option than not.

I’m kinda confused by all of the people here doing that tbh.

The entire point of dockerfiles is to have them produce the same image over and over again. Meaning, I can take the dockerfile, spin it up on any machine on gods green earth and have it run there in the exact same state as anywhere else, minus eventual configs or files that need to be mounted.

Now, if I’m worried about an image disappearing from a remote registry, I just download the dockerfile and have it stored locally somewhere. But backuping the entire image seems seriously weird to me and kinda goes against of the spirit of docker.

I’ve been looking to do this, but haven’t found a good, easy to use pull thru proxy for docker, ghcr.io and some other registries. Most support docker only.

This one looks promising but overly complicated to set up.

A few times now, I’ve gone to restart a container and the repo’s been moved, archived or paywalled. Other times, I’m running a few versions behind and the maintainer decided to not support it, but upgrading would mean a complete overhaul of my Helm values file. Ugh!

I was considering a docker registry on separate ports for each upstream registry I’d like to proxy/cache.

Just a small number of base images (ubuntu:, alpine:, debian:) are routinely synced, and anything else is built in CI from Containerfiles. Those are backed up. So as long as backups are intact can recover from loss of the image store even without internet.

I also have a two-tier container image storage anyway which gives redundancfor the built images but thats more of a side-effect of workarounds.. Anyway, the “source of truth” docker-registry which is pushed to is only exposed internally to the one who needs to do authenticated push, and to the second layer of pull-through caches which the internal servers actually pull from. So backups aside, images that are in active use already at least three copies (push-registry, pull-registry, and whoevers running it). The mirrored public images are a separate chain alltogether.

This has been running for a while so all handwired from component services. A dedicated Forgejo deployment looks like it could serve for a large part of above in one package today. Plus it conveniently syncs external git dependencies.