I also run (well, ran) a local registry. It ended up being more trouble than it was worth.

Would you have to docker load them all when rebuilding a host?

Only if you want to ensure you bring the replacement stack back up with the exact same version of everything or need to bring it up while you’re offline. I’m bad about using the :latest tag so this is my way of version-controlling. I’ve had things break (cough Authelia cough) when I moved it to another server and it pulled a newer image that had breaking config changes.

For me, it’s about having everything I need on hand in order to quickly move a service or restore it from a backup. It also depends on what your needs are and the challenges you are trying to overcome. i.e. When I started doing this style of deployment, I had slow, unreliable, ad heavily data-capped internet. Even if my connection was up, pulling a bunch of images was time consuming and ate away at my measly satellite internet data cap. Having the ability to rebuild stuff offline was a hard requirement when I started doing things this way. That’s now no longer a limitation, but I like the way this works so have stuck with it.

Everything a service (or stack of services) needs is all in my deploy directory which looks like this:

/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

When I run backups, I tar.gz the whole base {app_name} folder which includes the deploy file, data, config, and dumps of its services images and pipe that over SSH to my backup server (rsync also works for this). The only ones I do differently are ones with in-stack databases that need a consistent snapshot.

When I pull new images to update the stack, I move the old images and docker save the now current ones. The old images get deleted after the update is considered successful (so usually within 3-5 days).

A local registry would work, but you would have to re-tag all of the pre-made images to your registry (e.g. docker tag library/nginx docker.example.com/nginx) in order to push them to it. That makes updates more involved and was a frequent cause of me running 2+ year old versions of some images.

Plus, you’d need the registry server and any infrastructure it needs such as DNS, file server, reverse proxy, etc before you could bootstrap anything else. Or if you’re deploying your stack to a different environment outside your own, then your registry server might not be available.

Bottom line is I am a big fan of using Docker to make my complex stacks easy to port around, backup, and restore. There’s many ways to do that, but this is what works best for me.

afaik I’m on an older version of https://github.com/distribution/distribution/pkgs/container/distribution

my compose somehow doesn’t have much info … i should have made more notes

image: registry:2

Again, it’s nearly impossible to scrub the entire internet of the code to just run a single command and build a docker image of whatever you were running yourself. If you have the image locally, you can just push it anywhere you want.

Keep Dockerfile, keep checkouts of what you’re running, or push images locally. All very simple.