Image Distribution Overview

An image is useful only if you can get it from the machine where you built it to the machine where you need to run it.

That is the problem image distribution solves.

So far, we’ve mostly treated images as local Docker objects:

Docker Host
    |
    +── nginx:latest
    +── my-app:1.0
    +── python:3.14

But real applications rarely stay on one machine. You may build an image on your laptop and need to run it on a server, hand it to another developer, or deploy it to a production environment.

That gives us several ways to move an image around.

What Does Image Distribution Mean?

Image distribution simply means:

Getting a Docker image from one place to another so another Docker host can use it.

There are two broad approaches.

Move the Image as a File

You can turn an image into an archive, move that archive to another machine, and restore the image there.

Machine A
   |
   | image archive
   v
Machine B
   |
   v
Docker image

Docker gives you two related mechanisms for this:

docker save / docker load
docker export / docker import

They look similar at first, but they operate on different things.

We’ll spend time on that distinction in the next lessons because it is one of the easiest Docker concepts to mix up.

Use a Registry

Instead of manually moving an archive:

Machine A
    |
    | file
    v
Machine B

you can put the image in a registry:

             Registry
            /        \
           /          \
        push          pull
         /              \
        v                v
   Machine A            Machine B

Machine A pushes the image to the registry.

Machine B pulls it.

This is how image distribution normally works in real-world Docker workflows.

Why Do We Need More Than One Method?

Because the situations are different.

Imagine you built an image on your laptop.

Situation 1: Move It to an Offline Machine

The destination machine has no access to your registry.

You can create an image archive:

Laptop
   |
   | image archive
   | USB / file transfer
   v
Offline server

docker save and docker load are useful here.

Situation 2: Share an Image with a Team

You don’t want to manually copy a file every time someone needs the image.

A registry is a better fit:

Developer A
     |
     | push
     v
  Registry
     |
     | pull
     v
Developer B

Situation 3: Deploy an Application

A build system creates an image and pushes it to a registry.

A server then pulls that exact image:

Build
  |
  | build image
  v
Registry
  |
  | pull
  v
Production

This is the basic pattern behind container image deployment.

Image Distribution Is About Images, Not Containers

This distinction is important.

A container is a running or stopped instance created from an image.

An image is what you distribute.

Think of it like this:

                    IMAGE
                      |
             +--------+--------+
             |                 |
          Container A       Container B

You don’t normally distribute a running container to another machine.

You distribute the image and create a new container there.

For example:

Machine A

my-app:1.0
    |
    v
container-a

Move the image:

my-app:1.0
    |
    v
Machine B

Then create a new container:

Machine B

my-app:1.0
    |
    v
container-b

The container on Machine B is a new container.

It isn’t the same container that existed on Machine A.

Three Things You Should Keep Separate

At this point, keep these three concepts separate:

Container
    ↓
A runtime instance of an image

Image
    ↓
The artifact you distribute

Registry
    ↓
A place where images can be stored and retrieved

That gives us the overall picture:

    flowchart LR
    Build["Build / existing image"] --> Image["Docker Image"]

    Image --> Archive["Image Archive"]
    Archive --> Load["Load on another host"]

    Image --> Registry["Container Registry"]
    Registry --> Pull["Pull on another host"]

    Load --> NewContainer["Create container"]
    Pull --> NewContainer
  

There are therefore two major distribution paths we’ll follow in this section:

              Docker Image
                   |
          +--------+--------+
          |                 |
       Archive           Registry
          |                 |
       load/import        pull
          |                 |
          +--------+--------+
                   |
             New container

File-Based Distribution vs Registry Distribution

The difference is easiest to remember this way:

This doesn’t mean file-based distribution is obsolete.

It is particularly useful when:

• the destination is offline
• you need a portable archive
• you are transferring an image manually
• you need to move an image between isolated environments

Registry-based distribution becomes more valuable as the number of machines and people increases.

Where Docker Hub Fits

You may already know Docker Hub as the place where you run:

docker pull nginx

Docker Hub is a container registry service.

But it is important not to treat these terms as synonyms.

Registry
   ↓
The general technology/service for storing and distributing images

Docker Hub
   ↓
A specific registry service provided by Docker

We’ll look at this distinction properly later.

For now, just remember:

Docker Hub is a registry, but “registry” is the broader concept.

The Distribution Story We’ll Follow

We’ll build the rest of this section in this order:

Docker Image
    |
    +── File-based distribution
    |       |
    |       +── export / import
    |       |
    |       +── save / load
    |       |
    |       └── export vs save
    |
    +── Registry-based distribution
            |
            +── What is a registry?
            |
            +── Registry vs Docker Hub
            |
            +── commit and push
            |
            └── image version management

The most important thing at this stage is not memorizing commands.

It is understanding why there are different distribution mechanisms in the first place.

What’s Next

We’ll start with the simplest distribution scenario: turning a container’s filesystem into an archive and bringing it back as an image.

That is where docker export and docker import come in.