The annoying thing about trying to implement a Docker registry on Workers and R2 is that it's so close to having everything you need, but the 500MB request body limit means Workers is unable to accept pushes of layers larger than 500MB. The limit is even lower at 100MB on the Pro plan[0].

We are running a registry that does store content on R2[1], and today this is implemented as the unholy chimera of Cloudflare Workers, AWS CloudFront, Lambda@edge, regular Lambda, S3, and R2.

Pushes go first to CloudFront+Lambda@edge, content is saved in S3 first, then moved to R2 in background jobs. Once it's transited to R2, then pulls are served from R2.

I would so love for Workers + R2 to actually be able to accept pushes of large layers, unfortunately I have yet to talk to anyone at Cloudflare who believes it's possible. Especially in this era of AI/ML models, some container images can have single layers in the 10-100GB range!

[0] https://developers.cloudflare.com/workers/platform/limits/#r...

[1] https://depot.dev/docs/guides/ephemeral-registry

If you are a CloudFlare employee reading this, you should get involved with the OCI Distribution group that develops the standards for the registry: https://github.com/opencontainers/distribution-spec

I would love if the container pull protocol stopped using custom headers or content-type, so we could use any dumb http server.

How's the pricing with low usage? I suspect this is great. I wanted an image registry so that I can use it to deploy with Kamal, but the $5 plan is overpriced, given I push an image maybe once every 3 months. This could solve that

I think this is wonderful. I’m running a Gitea instance in one of our dev machine just for private registry. Keeping the instance only had been extra workflow for us.

But 500MB limit of layer size is a dealbreaker for AI related workflow.

Have any container running tools just implemented basic S3 compatibility for pushing/pulling images? If your registry doesnt accept pushes from untrusted sources, it doesn't seem like there is a ton of value in having "smarts" in the registry server itself.

When you push, the client could just PUT a metadata file and an object for each layer in the object store, and pulling would just read the metadata file, which would tell it where to get each layer. And could use etags to skip downloaded layers that have already been downloaded.

For auth just use the standard S3 auth.

Would be compatible with S3/r2/any other S3-compatible storage.

I built a similar PoC using Workers+R2, before Cloudflare released theirs, in case you find it useful: https://github.com/chainguard-dev/crow-registry

We eventually built our own registry in Go running on Cloud Run, which now serves all our images on cgr.dev.

Zero egress fees is really a game changer.

This is pretty nice. Does it support an API for deleting images (and having it properly garbage-collected)? It looks like maybe this does it? https://github.com/cloudflare/serverless-registry/blob/13c4e...

We have a managed docker registry and could have definitely used this project!

Slightly unrelated, but we've been experimenting with using SSH for authenticating with a docker registry if anyone is interested: https://github.com/picosh/tunkit?tab=readme-ov-file#why

I'm using this registry with regctl[0] to chunk uploads (to circumvent 100MB limit), works just fine for huge layers with models. With regctl you will also get 'mount' query parameter for upload initialization with the proper blob name so you can skip additional R2 copy when multi-part upload finalisation which speeds up the upload (and avoids crashes on larger blobs). This is not part of docker registry API, so I never got to PR that.

[0] https://github.com/regclient/regclient

When you switch to private Docker or Github registry to Cloudflare, are you effectively just trading one vendor lock in to another, or is there more into this?

Great feat.

However I am ever more confused now on what Cloudflare does and builds. They have everything from CDN, DNS to Orange Meets and this now?

Is there a registry that would work on extremely cheap disk storage if the use case if only push and very infrequent pulls?

Nice. I been seriously thinking about building exactly this (but Im glad someone smarter made it already)

Looks like a neat idea, does anyone know any open source version that does just this?

using this same architecture, it would be cool to build a serverless-git

Interesting. Just wish it handled larger image layers a bit better!

Interesting approach when running one of these on your 'LAN' is relatively easy

Though, to be fair, the pull-through mechanism in the reference registry been kind of goofy for years. Ask me how I know /s

> regitry