Project challenges / verified progress
Beacon: package it so anyone can run it

The engineering notebook

Publish by digest

What really happens when an image is pushed to a registry?

Loading statusStage 6 of 9

  • Workspace not ready
  • Agent not ready
Focus25:00
A small focus ritual

0 focus sessions completed. Every fourth session offers a longer break. Start each phase when you are ready.

Study time never unlocks verified lesson progress.

Loading...

Loading verified progress...

Loading GitHub account...
Phase 3 — Publish, inspect, prove

Step 01 of 06

Learn the concept

A registry is not a deployment system. It is a content store with names, manifests, blobs, and permissions. Push the same tag twice and you may have changed what every future pull receives. That is powerful in the same way a chainsaw is powerful.

ONE PUSH TWO REFERENCESbeacon imagemanifest and layersTagghcr.io/me/beacon:v1can moveDigestsha256 content hashfixedRepositoryaccess and packagesGHCR
The registry stores content once and lets references point at it. Tags make humans productive. Digests make machines repeatable. Use the right one in the right sentence.
Step 01

The ideas this is made of

A repository is a namespace inside a registry

ghcr.io/thesyscoder/beacon names the registry host, owner namespace, and package repository. Inside it, tags point to manifests, and manifests point to layer blobs. Pushing another image with the same tag changes the tag reference. The old blobs may still exist, but new pulls by tag no longer ask for them.

Login grants push rights, not moral authority

GitHub Container Registry accepts a personal access token or gh auth token with package permissions. Docker stores credentials in your local credential helper. Never paste a token into a Dockerfile, compose file, or shell history. Pipe it to docker login --password-stdin so it is not visible in process arguments.

Pull by digest when repeatability matters

docker pull ghcr.io/me/beacon@sha256:... asks for a specific manifest by content hash. If someone moves v1.0.0, the digest pull is unchanged. CI can build and push tags for discovery, but deployment records should include the digest. The tag is a label on the box. The digest is the box.

Immutable tags are policy, not physics

Some registries can refuse overwriting a tag. That is useful, but it is a server-side rule, not part of the tag itself. A different registry, repository, or permission mistake can still move names unless policy is enabled. Digest pinning remains the portable verification habit.

Logging in without exposing the token
gh auth token | docker login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin

docker tag beacon:meta ghcr.io/YOUR_GITHUB_USERNAME/beacon:dev
docker push ghcr.io/YOUR_GITHUB_USERNAME/beacon:dev

Use a fine-scoped PAT if your gh token lacks package write permissions. The image can be public, and public GHCR storage and pulls are free for this course.

Tag and digest behaviour

ReferenceMutableBest use

main

Yes

Latest CI build for humans

v1.4.0

Maybe

Release discovery

Immutable tag

Registry blocks change

Release policy

@sha256:...

No

Deployments and rollbacks

What these are called on the job

  • Registry — A server that stores OCI image manifests and blobs, such as ghcr.io.

  • Repository — A named package collection inside a registry, such as owner/beacon.

  • Manifest — The JSON document that lists config and layer digests for an image.