Hey Florian, I think it’s great that you are investigating this topic. I have been thinking along very similar lines. Yes, we should offer users the possibility of deploying a private registry, and yes we should almost certainly offer them the possibility of hosting on MinIO/S3.
The one part that is missing, as far as I am concerned, is the image building component. Where should it run? With tutor local we can assume that users will run tutor images build commands on the same server. What about k8s users? ideally, they should build their images on Kubernetes itself. This is what I am doing as part of the Tutor CI, but it’s very clunky because it’s difficult to build Docker images from within Docker.
On the other hand, having a dedicated image building worker is probably not an absolute pre-requisite for all tutor k8s users, so we should be able to make do without it. Users should be able to run tutor images build all locally, then tutor images push all, which will push to the k8s registry.
So I think we should take this opportunity to build this tutor-registry plugin! Would you like to create and maintain it? The rules for 3rd-party-maintained plugins to be officially supported are here: Maintainers meeting I like to encourage 3rd-party developers to maintain their own plugins because it’s 1. more publicity for you 2. less work for me. But I would totally understand if you told me that you’d rather not commit to a plugin maintenance. In which case it would be developed under the overhangio umbrella.