Container registry
Container Registry
A private registry for Docker images and Helm charts, with vulnerability scans, retention rules and webhooks.
What a registry is
A container registry is where your built images live. Your CI builds an image of the application and pushes it to the registry. Every server that runs the application pulls the image from there. Helm charts are kept the same way.
Docker Hub is fine for public images. Your own code needs a registry that only your team and your servers can reach. That is what you get here: a private registry on its own server, which we run and keep updated for you.
Why ours
Its own server
Every registry runs on a server of its own in your private network. Your images never share a machine with another customer, and your servers pull them over the private network instead of going out to the internet.
Scanned on every push
Each image is checked for known vulnerabilities the moment you push it, and the recent tags again every day. A webhook can tell your CI about it, so a vulnerable build is stopped before it reaches production.
Release tags you can trust
A pushed tag can be locked, so nobody overwrites a release by accident.
It grows with you
Every package has every feature, packages differ only in space. When the registry fills up, it moves to the next package by itself and a push never fails for lack of room.
Space under control
CI pushes a new tag on every build, and without cleanup a registry fills up with images nobody will run again. Set retention rules per repository: delete tags older than a number of days, or keep only the last few. The rules run every night.
Release tags can be locked, so cleanup and people never touch them. A layer that many images share is stored once, and the space of deleted tags and unused layers is freed in the same nightly run.
The panel shows how much space your images take and how big the disk is.
How to start
- Create a registry in the Cloud Panel and pick a package. It gets its own address and a login.
- Log in and push, the same way as with any other registry.
- Add users for your team and your CI, each with read or write access to the repositories it needs.
Example usage
# once per machine
docker login acme.registry.serverscamp.com
# build, tag and push
docker tag api:1.4.2 acme.registry.serverscamp.com/team/api:1.4.2
docker push acme.registry.serverscamp.com/team/api:1.4.2
# Helm charts too
helm push chart-0.3.0.tgz oci://acme.registry.serverscamp.com/chartsAccess and control
Users by repository
Each user logs in with its own password and reaches only the repositories you allow, by a name like app or a pattern like team/*.
Public repositories
Repositories you list can be pulled by anyone without logging in. Pushing still needs a user.
Login guard
Addresses that keep guessing passwords are blocked for a while. Your office and your CI can be listed so they are never blocked.
Audit log
Every push, pull, delete and login, with the user, the address and the image.
Webhooks
A signed POST with JSON on every push or delete, for your CI to react to.
Metrics
Requests, errors, response time and the space your images take.
Questions
Does it work with Kubernetes?
Yes. It is a standard OCI registry. Add the registry login as an image pull secret and point your deployments at the registry address.
Can some images be public?
Yes. List the repositories anyone may pull without logging in, by name or by a pattern like public/*. Pushing always needs a user.
How do I move from Docker Hub or another registry?
Pull your images, tag them with the new address and push them. Tools like skopeo or crane copy a whole repository in one command.
What happens when the registry is full?
It moves to the next package by itself, and you pay for the larger package from that moment.
Can I see who pushed what?
The audit log keeps every push, pull, delete and login: who did it, from which address, and which image.
Do I need a network first?
Yes. A registry lives in a private network behind a router, the same way your servers do.