Container registry

[girish]

tl;dr cloudron build is dead. Long live cloudron builder.

With Cloudron 10, we have implemented a new Container Registry app. This merges the previous Docker build service and Docker registry app into a single app and brings it in line with all the modern registries.

Features of this registry:

• Docker/OCI registry (docker push / docker pull)
• Cloudron login (OIDC) for the UI
• App passwords for Docker CLI auth
• Anonymous pull for public repos
• Private repos (login required for pull and push)
• Create repos from the UI (alpine or team/my-app)
• Repo descriptions
• Browsable catalog: tags, digests, sizes, platforms
• Multi-arch images
• Tag detail: pull command, layers, Dockerfile history, raw manifest
• Search across repos, tags, and builds
• Pull counts and last pushed/pulled times
• Immutable tags (cannot be overwritten)
• Remote builds via cloudron builder login / cloudron builder build
• Builds run in-app with BuildKit (not the host Docker daemon)
• Live build logs in the UI, with cancel
• GitHub/GitLab webhooks to build on push
• Access token or deploy key for private git repos
• Branch/tag → image tag mapping (latest, branch name, git tags)
• Tag expiry (keep last N tags per repo)
• Immutable repos skipped by expiry
• Builder concurrency and build-cache cleanup

There is an important change to cloudron install as well. Previously cloudron install could mean local Docker, a server build, or a builder image. Local Docker is gone from the CLI and you can use the docker CLI yourself to build and tag as you want. Bare cloudron install always builds on the server. To install an image from Container Registry, pass --image <image> or --last-image after cloudron builder build.

More details at https://blog.cloudron.io/container-registry/

[girish]

Some screenshots:

[robi]

What about hosting artifacts like CloudronVersions files?

[girish]

@robi seems like a good next step. I guess some cloudron versions upload to go with it to automatically upload the versions file I guess the community authors would have to chime in, if they see this as needed/useful.

[ekevu123]

I have tested the new registry and it works excellently for me. I am quite happy, and have already replaced my older workflows with the builder and the private docker registry as separate apps.

[timconsidine]

Sounds good improvment.
I might be being bit thick, but how does the new registry with build functionality align with the traditional advice "do not build on your primary Cloudron instance" ?
Is the traditional advice now revoked ?

[girish]

@ekevu123 thanks for testing! let us know if you miss a feature, currently the feature set is very much around what we wanted for our own packages. But all of Cloudron packages are now built and hosted on this new registry. I think we will switch the fallback from quay to our selfhosted registry at some point.

[girish]

@timconsidine I should have probably highlighted that aspect since it's hidden in the "Builds run in-app with BuildKit (not the host Docker daemon)" line. Previous registry used to build using the host docker (the host docker socket was exposed to the app). If you build some mega app, it will bring down the server.

With this new registry, the builds are sandboxed to the app - so the app's cpu and memory limits apply. The host docker storage is not polluted.

[timconsidine]

@girish thanks for the explanation.

Currently I do dev work on my Mac laptop, use docker build --context build-server ... to run builds and registry pushes on a small VPS, avoids impact on my laptop and on my Cloudron box.

I will get brave and try out container registry sometime