We're initially focusing on private images available on one of the major registries (AWS, GCP, Azure, Docker Hub, etc.). But on-premise is definitely one of the options we want to offer in the future.
How are you loading the data for all of the public repositories? It looks very similar to the front page of https://hub.docker.com/. Assuming you are scraping / using the API to load all of that data?
Great pointer, thanks for that. Now I'm trying to piece together what happened to that project :)
The plan is to integrate with the different registries to support private images and in parallel to expand what contains.dev can do for individual images.
Cool project! I would be cautious with the sentence „See what’s inside your Docker“. Aside from the broader term „container image“, I would think you could get mail from Docker (as I’m the company) for using their name while you’re not Docker.
This is great! I was working on something similar but admittedly didn’t get around to launching it, it wasn’t as nice as this. How do you plan to monetize?
21 comments
[ 3.4 ms ] story [ 83.0 ms ] threadTo get any sort of info about an image we found ourselves pulling them locally and spending lots of time with CLI tools and manual layer exploration.
Much like GitHub is a great way to explore different repositories quickly, we're hoping contains.dev is a step in that direction.
I like the integration with CVEs.. So what's the longer term vision here for contains.dev?
https://github.com/microscaling/microbadger
The plan is to integrate with the different registries to support private images and in parallel to expand what contains.dev can do for individual images.
It'd be great if we couls use this with github1s.com (https://github1s.com/conwnet/github1s).