Container Registry
for Docker and Kubernetes images

You run docker login against your Container Registry endpoint with your credentials, then push and pull as normal. For Kubernetes, you store those credentials as a pull secret and reference it from your deployments, so the cluster can fetch private images during a rollout. The same credentials cover both.

Yes. The Container Registry is private to your account and reached with your own credentials, so images aren't exposed publicly. This is vital for container images, which often bundle application code, dependencies and sometimes configuration you wouldn't want readable by anyone who finds the URL.

Yes. Pull each image from the old registry, retag it for your Krystal endpoint and push it, or use a tool like skopeo to copy between registries directly. Your images arrive unchanged, with the same layers, and same digests.

Since you pay for the image storage you use, prune tags you no longer need through the console or the API. Registries share layers between images, so deleting a tag only frees space once no remaining image references those layers. Cleaning up old build tags regularly is the simplest saving.

Your build pushes an image to the registry when a job succeeds, and your deployment step pulls it by tag or digest. Pinning deployments to a digest rather than a moving tag like latest gives you reproducible rollouts, so you always know exactly which build is running in each environment.

It can. Images are stored in London, Amsterdam or New York, and pulls are quickest when the registry is in the same region as the cluster or VMs deploying from it. For rollouts that pull large images across many nodes, keeping registry and workloads in one region noticeably cuts deploy time.