Before it runs, an application was written in a forge, built with dependencies that came from an artifact repository, then stored as an image in a registry, from which the platform pulls it at startup. These three families form the software supply chain: they are not on the path of requests, but nothing gets deployed without them. This lesson teaches you to tell them apart, to separate what is used to build from what is used to run, and to answer an outage question: the registry goes down, does a service that is already running keep going?
What you will learn
- Tell a forge, an artifact repository and an image registry apart
- Separate what is used to build from what is used to run
- Predict whether a running service survives a registry outage
- Explain why a registry is a trust boundary
Forge, artifact repository, registry: who does what?
The forge keeps the source code and its history, the artifact repository keeps the packages the code depends on and those it produces, and the registry keeps the container images ready to run. A forge such as GitLab, GitHub or Gitea adds code review and, often, continuous integration to the Git repository. An artifact repository such as Nexus, Artifactory or Pulp serves npm, PyPI, Maven or RPM packages. A registry such as Harbor, or the one from a cloud provider, serves images in the OCI format.
The diagram follows the path of a change to the shop, from code to execution.
The diagram shows a clean break. The first four arrows are used to build: they only play at delivery time. The last one, from the registry to the platform, is used to run: it plays every time a replica starts. This break is what answers the outage questions, and it makes the registry the only brick of the chain that production depends on.
The registry goes down: does a running service keep going?
Yes: a replica that is already running has its image on the machine and keeps serving; what fails is every new start on a machine that does not have the image. The runtime keeps the downloaded images in a local cache. A replica that restarts on the same machine finds its image again; a replica placed on a fresh machine has to download it, and fails.
The situations hit are precisely those where you need the platform. A
deployment cannot pull its new version. A scale-out adds replicas that
do not start, with the ImagePullBackOff state on Kubernetes. A machine that
fails sees its replicas rescheduled elsewhere, where they do not start. A
registry outage therefore cuts nothing as long as all is well, and prevents you
from reacting as soon as something goes wrong.
The table extends the same reading to the other two families.
| Brick down | What keeps running | What fails |
|---|---|---|
| forge | all of production | shipping a fix; GitOps synchronization, which keeps the last state |
| artifact repository | all of production | building: continuous integration no longer finds its dependencies |
| registry | the replicas already running | deploying, scaling out, rescheduling a replica on another machine |
Why a local mirror?
A mirror keeps a local copy of public dependencies and images, so that the shop depends neither on the availability nor on the limits of a service it does not control. Docker Hub limits the number of anonymous downloads; a package can be removed from npm overnight; a public registry can be unavailable during an incident. An artifact repository configured as a proxy serves the copy it has already downloaded.
The mirror moves the dependency rather than removing it: it becomes in turn a brick to keep available, to back up and to monitor. But it is a brick the shop controls, inside its own failure domain, and it keeps what the outside world can make disappear.
Why is the registry a trust boundary?
Whoever can push an image to the production registry can run their code in
production: the registry is therefore one of the most sensitive trust
boundaries of the architecture. An image replaced under the same name, with
a reused tag such as latest or 1.4, is pulled at the next start without
anyone noticing. This is the principle of supply chain attacks.
Three protections can be read in the configuration. Reference the image by its
digest, a sha256: that designates precise content and cannot be
reassigned. Have continuous integration sign the image, and refuse any
unsigned image at startup. Restrict the right to push to continuous
integration alone, never to the accounts of developers. These three
gestures make the registry a verified boundary rather than an open door.
| Grid question | What to look at |
|---|---|
| State held | the code (forge), the packages produced (repository), the images (registry) |
| To back up | the forge and its settings; the artifacts you can no longer rebuild |
| If it goes down | nothing stops, nothing can be delivered anymore; registry: nothing restarts elsewhere anymore |
| Trust | right to push, signatures, references by digest |
| Signal to monitor | download failures, disk space, unsigned images refused |
What the artifact chain changes in the shop
The shop now only deploys images built by its continuous integration, signed, stored in its own registry and referenced by digest. On V4 of the running example, the registry is attached to the runtime platform, not to the application: it is the platform that pulls the image, at startup. The table lays out the trade-off.
| What you gain | What you pay |
|---|---|
| known images, signed, traced back to the commit | a registry that every start depends on |
| dependencies that no longer disappear from the outside | a mirror to keep available and to back up |
| a right to push limited to continuous integration | a forge and continuous integration that become first-rank targets |
On the responsibility side, the forge, the registry and continuous integration often belong to a platform team, which is not the one answerable for the shop. Their outage nevertheless blocks the shop's emergency fix: their availability must be agreed between the two teams, not discovered during the incident.
Who takes over to install a forge or a registry?
This lesson describes the architectural role of these families; their installation and hardening belong to the specialized guides of the site. The Artifact management guide compares the repositories, including Nexus and Harbor, a registry with proxy-cache. Container registries explains the storage and distribution of images, and Gitea (in French) presents a self-hosted forge.
Common reading traps
These mistakes keep coming back around the artifact chain, and almost all of them come from a confusion between building and running:
- Believing that a registry outage stops production: it prevents you from changing it.
- Believing that it has no consequence: the next machine failure can no longer be repaired.
- Referencing an image by a tag that can be reassigned.
- Letting developers push directly to the production registry.
- Depending directly on public registries without a mirror.
Key points
- The forge keeps the code, the repository the packages, the registry the images.
- Building depends on the whole chain; running depends only on the registry.
- Registry down: what runs keeps going, nothing restarts elsewhere.
- A mirror replaces an external dependency with a controlled one.
- Whoever pushes to the registry runs in production: it is a trust boundary.
- Digest, signature and limited rights protect this boundary.
Knowledge check
The questions cover the roles of the forge, the artifact repository and the registry, what a registry outage breaks, the local mirror and the registry as a trust boundary.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Container registries: understanding image storage and distribution
A new full quiz with random questions
Work again only on the questions you missed