What is a container registry? Where container images live

The plain idea

A container image is the packaged, runnable blueprint for a container — application code, dependencies and configuration bundled into layered files, as explained in the what-is-docker article, which this piece does not repeat. A container registry is simply where those images are kept: a repository, much like a code repository, except it stores images instead of source files.

Each image in a registry is identified by a name and a tag — commonly a version number, such as v2.1 — so a registry can hold many versions of the same application image side by side, and a deployment can pin to an exact one rather than "whatever is newest".

Public versus private registries

Docker Hub is the best-known public registry: a shared catalogue of images, including official base images for popular languages and databases, that anyone can pull from. It is often the starting point for a Dockerfile — "build on top of this official base image" — and a convenient place to publish open-source images for others to use.

Most organisations also run, or subscribe to, a private registry for their own application images. A private registry restricts who can push and pull, keeping proprietary code and internal images out of a public catalogue while still giving every developer, build server and deployment target a single, consistent source to fetch from.

How it fits the container workflow

The everyday sequence is: build an image from a Dockerfile, push that image to a registry, then something else pulls it and runs it. That "something else" is usually not a single manual docker run — at any real scale it is Kubernetes (or a managed container service) pulling the image onto whichever cluster node needs to run it, exactly as described in the what-is-kubernetes explainer. The registry is the handoff point between building software and running it: build once, push once, then pull that same, unchanged image everywhere it is deployed.

Why it matters

A registry gives a team several things a shared network folder of image files never would.

• Versioning — tags let you track exactly which build is running where, and roll back to a previous tag if a new one causes problems.
• Sharing — every developer and every environment pulls from the same source of truth, instead of copying files around by hand.
• Security scanning — many registries scan images for known vulnerabilities as they are pushed, catching problems before they reach production.
• Access control — who may push new images and who may pull existing ones is enforced by the registry, separate from application-level permissions.

Cloud registries

Each major cloud provider offers a managed private registry alongside its container services: Amazon ECR (Elastic Container Registry) on AWS, Azure Container Registry, and Artifact Registry on Google Cloud. All three do the same core job — store and serve images with access control — while integrating tightly with that provider’s compute and container-orchestration services, so an image pushed to the registry can be pulled straight into a managed Kubernetes cluster or container-running compute service without extra configuration.

The security angle

An image pulled from an untrusted source can carry outdated libraries or known vulnerabilities straight into your environment, so treating a registry as a trust boundary matters. Good practice is to scan images for vulnerabilities before they are deployed, sign images so consumers can verify they came from a trusted source and were not tampered with in transit, and avoid pulling arbitrary public images directly into production without review.

Where it appears in certification study

Developer and DevOps-leaning certifications expect familiarity with the build-push-pull workflow and where a registry sits within it — the AWS Developer Associate exam covers deploying containerised applications, which assumes comfort with ECR as the image source, and the Kubernetes and Cloud Native Associate exam expects you to understand how a cluster pulls images from a registry to run workloads. Foundational exams generally do not test registries directly.