Table of Contents
Understanding Docker Hub
Docker Hub is the default public registry used by Docker. When you run a command like docker pull nginx or docker run alpine, your Docker Engine contacts Docker Hub if you do not specify another registry. Docker Hub stores images in repositories, and each repository can contain multiple tagged versions of an image.
A repository name on Docker Hub usually looks like user_or_org/image-name. Some images have an official status and can be used without the user or organization prefix. For example, nginx and alpine are official images, and their full names on Docker Hub are effectively library/nginx and library/alpine, but you rarely need to type the library prefix.
Docker Hub also provides a web interface where you can search for images, read their documentation, see available tags, and check how frequently they are pulled. You can create a Docker Hub account, push your own images to your repositories, and decide if they are public or private.
Docker Hub is the default registry. If you do not specify any registry when pulling or running images, Docker will use Docker Hub automatically.
Public and Private Registries
A container registry is any service that stores and serves container images using the registry protocol that Docker understands. Docker Hub is one example, but you can also use other public services or set up your own private registry.
Public registries are accessible over the internet. They often host a large collection of images from many publishers. Some are completely open, and some require authentication even for pulls. Docker Hub, GitHub Container Registry, and some cloud provider registries can all be used as public sources of images.
Private registries are restricted to a specific organization or project. They are useful when you need to store proprietary images, internal tools, or anything that must not be made available on a public service. A private registry can run inside your company network or be provided as a managed service in the cloud. Access is controlled with credentials, and you decide who can push and pull which images.
In practice, many teams mix both types. They pull common base images from public registries, such as official language runtimes or operating system images, and push their own application images to a private registry that is integrated into their development and deployment pipeline.
How Docker Talks to Registries
Whenever you work with images, Docker uses a simple pattern to locate them. An image reference usually includes three parts: a registry address, a repository, and a tag. You will see more about tags in another chapter, so the focus here is on how Docker finds the registry.
If you type docker pull nginx:latest, Docker interprets this as a request for the nginx repository with tag latest from the default registry, which is Docker Hub. If you want to use a different registry, you include its address before the repository. For example, my-registry.example.com/myteam/myapp:1.0 tells Docker to contact my-registry.example.com, then look for the myteam/myapp repository with tag 1.0.
If the registry is not specified, Docker uses Docker Hub. To use a different registry, always prefix the repository with the registry address, for example registry.example.com/myrepo/myimage:tag.
When the registry requires authentication, Docker uses a local credential store. You authenticate with docker login once per registry. Docker then keeps your credentials so that subsequent pull and push commands can access that registry without asking for the password each time.
Hosted Registry Services
Beyond Docker Hub, several popular hosted registry services exist. Each one follows the same core idea: you push images to repositories and later pull them on other machines. They differ in features, integration, and pricing, but to Docker they look similar.
Cloud providers typically offer their own registries. For example, there are services that integrate tightly with their own virtual machines, container orchestration services, and identity systems. These are often used to store images that will run on that provider's infrastructure.
There are also more general hosted registries that focus on integration with source code hosting and CI tools. For example, a registry that lives next to your Git repositories allows you to tag and push images that correspond to particular commits or releases. This is useful when you want a clear link between the code and the image that was built from it.
From a beginner's perspective, the key point is that almost any registry that supports the Docker registry protocol can be used through the same Docker CLI commands, as long as you point Docker to the correct registry address and authenticate if needed.
Self-Hosted Registries
Sometimes you might not want to store images on a public or third-party hosted service. In such cases you can run your own registry inside your infrastructure. This is known as a self-hosted registry.
Self-hosted registries are useful when strict data control is required, such as in environments with tight compliance rules or limited internet access. They can also help with performance by placing the registry close to the machines that use it, reducing latency and bandwidth usage.
A self-hosted registry is usually just another service that stores image layers and metadata in some backend storage. Docker interacts with it through HTTP APIs using the same standard registry protocol. As a result, your developers can keep using docker push and docker pull with only the registry address changed.
Running your own registry brings responsibilities. You must secure it with proper authentication and encryption, maintain its storage, and consider how to back it up. These details are specific to the registry implementation you choose and to your environment, but the general idea stays the same: it is still a registry, and Docker still treats it as a source of images.
Authentication and Access Control
Most registries support push and pull operations with access control. They usually require that write operations are authenticated, and they often allow more flexible rules that specify who can publish and who can only read.
To work with an authenticated registry from your local machine, you typically run docker login registry-address. Docker prompts you for a username and password or token. After a successful login, Docker stores the credentials so that commands like docker pull registry-address/myrepo/myimage:tag and docker push registry-address/myrepo/myimage:tag can succeed without entering credentials each time.
Never bake registry passwords or tokens directly into images or share them in source code. Authentication data must be handled outside images and code.
Registries can expose multiple repositories to different groups. For example, public base images may be readable by anyone, while internal application images are restricted to members of a specific team. The registry enforces these rules at request time when Docker tries to pull or push an image.
Registry Usage in Typical Workflows
In a basic workflow, you might start from a base image pulled from a public registry. You then build your own application image locally and push the result to a registry that your deployment environment can reach. Later, your production or test servers pull that image by its reference and run containers from it.
This pattern separates image creation from image usage. Developers or build systems are responsible for pushing images, while deployment systems are responsible for pulling images and running containers. The registry is the shared place where these images live.
In collaborative teams, the registry becomes a critical part of the toolchain. It allows different environments to use exactly the same container image, which improves consistency and reduces the chance that "it works on my machine" but fails elsewhere. The registry acts as the single source of truth for images, and its ability to store many versions within one repository makes it possible to roll forward or back by referencing different tags or other identifiers that you will see in more detail later.