Completely blocking the image information page to mobile user agents is completely unnecessary. I'd much rather look at your non optimized page than be told to come back on desktop.
Moreover, even after switching to desktop mode on my phone, there's nothing I see that precludes you from employing a little bit of CSS to make those pages render more nicely on mobile screens.
Seriously. I get the sibling comment seemingly from someone involved talking about eng resources being tight, but blocking it instead of just showing a desktop page feels absurd.
Fair complaint. As with all software development we make tradeoffs to try to balance time and capability. I’ll make sure our front end lead see this though :)
Asking the very obvious question (as it's not apparent from the website): Why would I use this over DHI (Docker Hardened Images) or Chainguard Images, both of which also have a set of free hardened images?
1. These are all >1200 of our images, including FIPS, and all versions… others gate many of their images
2. These are all built continuously from upstream source on a distroless base… this makes a significant difference in attack surface and CVE count re DHI images and you can easily check our word with a few scans
3. These are truly free… no auth wall, no signup, no trial, no limit on numbers of images or pulls or anything like that
4. We have really invested in making these agent ready… we have a CLI (minicli) designed for both humans and agents to easily discover, understand, migrate to, and build on them… for example, check out the AI migration prompts we provide for each image, we’ve refined these across many customer deployments such that you can copy paste into your agent of choice, point it at a Dockerfile and have it do all / nearly all the work to move to these images
2. Isn't there a slight risk of upstream attacks being amplified by this? With the recent number of software compromises providing a way for people to use images X days old may be useful.
3. This ties into 2, if someone downloads and uses an image that is later found to be compromised they mostly have no way of being notified that happened. Not a huge issue, but is something that should be risk assessed.
Not sure what you mean… we have more images than DHI, we have FIPS images available freely, and all our images are built from source on a distroless base. These are just objective facts.
The build from source on distroless approach provides a meaningful advantage re attack surface and CVEs versus DHI images. You don’t have to take our word for it, just pull some images and scan with Trivy or Grype or whatever you prefer.
Re 3, one of the features in Enterprise Edition is integrations with Slack, GitHub, webhooks, etc. a key use case is getting a push notification (or even triggering automation) when an image you’re using gets an update.
It’s simple but pretty granular too… ‘if this python image gets a fix for a critical CVE that’s actively exploited, trigger a GitHub action to rebuild the app with the updated image’
Since we started paying for Chainguard I’ve become super sold on the benefits of minimal and continually patched images. It’s just a shame that the open source community only gets to benefit from the limited free library DHI and Chainguard offer. I understand it costs money though and that needs to come from somewhere.
This is exactly why we’ve made Community Edition free. The value of hardened, well maintained images to the world writ large is huge.
We believe there is sufficient value to enterprises in the SLAs and broader feature set to build a great business while making the core benefit available to everyone without friction.
Currently, yes free as in beer. We build every component directly from source in a SLSA 3 environment we run (mostly in GCP). Making the Dockerfiles available is a fair question, not something we’ve done thus far because it’s not particularly useful if you don’t have all the infrastructure building the components.
Do you have particular scenarios you’d like the Dockerfiles for or is it just for transparency/ trust (which is a totally valid reason of course)?
> Do you have particular scenarios you’d like the Dockerfiles for or is it just for transparency/ trust (which is a totally valid reason of course)?
The latter. You or an attacker could tamper with the images - however even with the Dockerfiles I can't be sure that the provided images are built from the Dockerfiles, so in the end I'd have to trust you anyway. Also I'd be curious how you build the images.
Totally get it… practically if you don’t want to have to deal with constantly updating images you have to have some degree of trust in whomever you get them from… that said, we try to be as transparent as possible with a cryptographically verifiable SBOM for every build of every image, signing every image, providing detailed compliance test results for FIPS, STIG, CIS (see the compliance tab on each image listing)
Your feedback about Dockerfiles is good though and probably something we can easily add to image listings. I opened an issue for us to add.
Note that we also make our package manager freely available in Community Edition as well, which can make the Dockerfile availability more useful.
This is our new Community Edition, which are all the exact same images as the Enterprise Edition product customers around the world already use, just without all the other features like image creator, self hosting, integrations, SSO, etc. Click the discover Enterprise Edition button on lower left and you can see a quick comparison table or go to minimus.io to see all the details.
EE also includes contractually backed CVE remediation and support SLAs. If you’d like to try EE and get pricing details, we’d be happy to help! Just click the button on the lower left to get started.
Just a little bit of feedback: some items on the main page are duplicated, which could be confusing. For example, "nginx-advanced" appears as updated both 3 days ago and 2 hours ago.
One of those is the image, one is a Helm chart using that image. The chart has an label and icon for chart but obviously we need to make this clearer :)
I see this is a packaging service with greater traceability and velocity than the rando images on docker hub.
I believe that they will always supply the bleeding edge stable release, but it will always be your responsibility to monitor and manage issues like CVEs, rather than expecting them to do it for you.
I have no idea what the heck is this, maybe it’s a great product but a very poor website in telling what I am getting into, it this better than the usual containers? How? Supported platforms? Can I run it on arm? The usuals
Moreover, even after switching to desktop mode on my phone, there's nothing I see that precludes you from employing a little bit of CSS to make those pages render more nicely on mobile screens.
2. These are all built continuously from upstream source on a distroless base… this makes a significant difference in attack surface and CVE count re DHI images and you can easily check our word with a few scans
3. These are truly free… no auth wall, no signup, no trial, no limit on numbers of images or pulls or anything like that
4. We have really invested in making these agent ready… we have a CLI (minicli) designed for both humans and agents to easily discover, understand, migrate to, and build on them… for example, check out the AI migration prompts we provide for each image, we’ve refined these across many customer deployments such that you can copy paste into your agent of choice, point it at a Dockerfile and have it do all / nearly all the work to move to these images
2. Isn't there a slight risk of upstream attacks being amplified by this? With the recent number of software compromises providing a way for people to use images X days old may be useful.
3. This ties into 2, if someone downloads and uses an image that is later found to be compromised they mostly have no way of being notified that happened. Not a huge issue, but is something that should be risk assessed.
1 and 2 are not a reason
3. no X, no Y, also not a reason
4. `rg agents`. Right
The build from source on distroless approach provides a meaningful advantage re attack surface and CVEs versus DHI images. You don’t have to take our word for it, just pull some images and scan with Trivy or Grype or whatever you prefer.
It’s simple but pretty granular too… ‘if this python image gets a fix for a critical CVE that’s actively exploited, trigger a GitHub action to rebuild the app with the updated image’
Check out the changelog tab in each image listing and you can see exactly when and why we build each time
We believe there is sufficient value to enterprises in the SLAs and broader feature set to build a great business while making the core benefit available to everyone without friction.
Do you have particular scenarios you’d like the Dockerfiles for or is it just for transparency/ trust (which is a totally valid reason of course)?
The latter. You or an attacker could tamper with the images - however even with the Dockerfiles I can't be sure that the provided images are built from the Dockerfiles, so in the end I'd have to trust you anyway. Also I'd be curious how you build the images.
Thanks for your answer!
Your feedback about Dockerfiles is good though and probably something we can easily add to image listings. I opened an issue for us to add.
Note that we also make our package manager freely available in Community Edition as well, which can make the Dockerfile availability more useful.
This is our new Community Edition, which are all the exact same images as the Enterprise Edition product customers around the world already use, just without all the other features like image creator, self hosting, integrations, SSO, etc. Click the discover Enterprise Edition button on lower left and you can see a quick comparison table or go to minimus.io to see all the details.
EE also includes contractually backed CVE remediation and support SLAs. If you’d like to try EE and get pricing details, we’d be happy to help! Just click the button on the lower left to get started.
Thanks for the feedback!
currently reg.mini.dev does not have AAAA records. Did not check the blob storage endpoints.
reg.mini.dev is really a front end to Google Artifact Registry which already supports v6. I opened an issue for our devops team to enable it for us.
Thanks for the feedback!
I believe that they will always supply the bleeding edge stable release, but it will always be your responsibility to monitor and manage issues like CVEs, rather than expecting them to do it for you.