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 :)
Thank you for this! Super valuable for contribution to all businesses. Suppose I want to add a custom PHP extension such as NewRelic, how would I go about adding that on your distroless images?
I'm interested in using these images on exe.dev. exe supports any oci images and stands it up as a microvm, in which it would be used non-ephemerally from that point. I'm assuming the images don't have any rc/services. How hard would it be to pull that back in after image deployment? (Also looks like I'd want to use the -dev images which include shell/apk, etc)
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.
> 2. Isn't there a slight risk of upstream attacks being amplified by this?
I think the argument would be that consuming Minimus' containers would have a less severe amplification (or even reduction), as all upstream attacks that rely on a combination of third-party vulnerabilities would be rendered infeasible (since they reduce the amount of third-party dependencies in an image).
> 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.
For this you need a consumption-aware scanner anyways (e.g. that lists images running in your Kubernetes). Anything else will be too spammy, as you can't notify for everything for you have at some point in time have used as a base image.
Also note that one of the features of Enterprise Edition is our integrations with Slack, email, GitHub, webhooks, etc. This enables really simple but powerful notification and automation scenarios based on image fixes (amongst other triggers like a version you're using going EOL).
For example, with EE, you can create an action to automatically trigger a webhook or send a Slack message when an image you're using has a critical CVE that's likely to be exploited (we also integrate threat intel from EPSS, KEV, etc).
Definitely still value in having runtime scanning / visibility too, but EE makes it easy to do purely on the 'left' side of things too.
Pull-through cache the images. Sure, they could decide you can't pull anymore, or impose problematic rate limits, but you shouldn't add a runtime dependency on their registry in any case.
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
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.
In the risk reduction tab, it should compare the vulnerability count against the node-slim image. In my eyes, it takes away from the offering when they try to prop up the vuln count for the official images, and nobody deploys `node:latest`.
You may / may not be surprised how many enterprises still run long ago EOL'd versions of various stacks, frequently on full blown OS base layers of similar vintage
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.
What can you say about long-term plans? The bitnami situation burned a lot of people I think, and yes we can cache your images, but switching providers still does not come for free.
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 :)
1. Distroless base. Imagine an effectively empty filesystem that only includes the components needed to run the app. The package manager we use is apk from Alpine and we make our full package universe of >10,000 packages available freely to Community Edition users. If you want a more 'normal' experience with a shell and apk, use the -dev versions of images that are still minimalistic but include a little more tooling like this.
2. For creator, you're basically taking any image from our public gallery and able to add whatever other packages from our universe to it, set env vars, upload files (customers typically use this for adding conf files and certificates). Then we maintain that image 'recipe' for you continuously, under the same SLAs we do all the public images. More details at https://docs.minimus.io/enterprise-edition/image-creator#ima...
3. Nope :) We are building every package across our universe continuously. Whenever there's a new version of any of them, we pull source, build package, compute what images (including creator ones) use that package, rebuild those images, test, sign.
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.
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.
By CVEs I mean the architectural stuff that was discovered after the original ingress-nginx repo was archived, so there is no "official" mitigation and it's not just a matter of bumping dependencies, the fixes are actual code.
Chainguard forked the repo and is maintaining their own distribution now, but it's not free.
Not sure what you mean here. We have many enterprise customers, in industries including government, health care, financial services around the world. The whole value of the product is helping them avoid all the risk and work associated with poorly maintained container images. We publish a full SBOM for every image so you can see exactly what's inside of it. We've worked across the industry and OSS communities to enable scanning support as well, so you can easily use whatever scanning tools you currently use (e.g. Wiz, AWS Inspector, Grype, etc) to check our images.
I truly don't get this. What is the security policy here? Why should I trust images built by minimus.io? How do I know they don't contain malicious software? What's the point?
We build all these images directly from upstream source across thousands of projects and assemble them into standard OCI images for you. We do this continuously, every time there are new versions released upstream.
The point is that you can just use these images instead of what you already have and reduce your vulnerabilities by 97%+ on average.
Think Docker Hub, just without the vulnerabilities.
Pinky promise? How do you prove that what I download from you is actually what you promise you've build (and that SBOM is right)? Is this certified with some digital signature?
From my threat attack model, you're just yet another liability - one single service to hack all your "safe" images.
Sure, but you could make the same argument for literally any software that you're getting that was built by someone else and have not personally inspected each line of source in. For example, you could make the same argument about RHEL or any image on Docker Hub or literally anything you're not building yourself.
Respect your viewpoint and if these images aren't for you, that's totally fine of course. Many others find it useful to have someone else doing the commoditized but hard work of building thousands of components from source continuously, assembling them into ready to run images, signing, and being as open as possible about their state and configuration as possible.
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, is this better than the usual containers? How? Supported platforms? Can I run it on arm? The usuals
Correct, we are not claiming to be auditing the source of every software package in the world. The value we provide is a minimalistic architecture so you start with a significantly smaller attack surface and continuous builds of upstream so you stay at a near 0 CVE state without the substantial work required to do so yourself. Basically, we help you get all the upstream fixes from across the OSS ecosystem as quickly, safely, and easily as possible.
Minimus images support both amd64 and arm64. When you run the docker pull command, it will automatically pull the correct architecture for your system.
Is the cli open source? What about the images themselves?
An easy comparison is wolfi, which is completely open source.
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.
Takes more eng resources to block mobile than not
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 :)
Turning on "Desktop Site" on Firefox Android lets me through. Not that I disagree, just a workaround.
Thank you for this! Super valuable for contribution to all businesses. Suppose I want to add a custom PHP extension such as NewRelic, how would I go about adding that on your distroless images?
I'm interested in using these images on exe.dev. exe supports any oci images and stands it up as a microvm, in which it would be used non-ephemerally from that point. I'm assuming the images don't have any rc/services. How hard would it be to pull that back in after image deployment? (Also looks like I'd want to use the -dev images which include shell/apk, etc)
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
>are all built continuously from upstream source
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.
> 2. Isn't there a slight risk of upstream attacks being amplified by this?
I think the argument would be that consuming Minimus' containers would have a less severe amplification (or even reduction), as all upstream attacks that rely on a combination of third-party vulnerabilities would be rendered infeasible (since they reduce the amount of third-party dependencies in an image).
> 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.
For this you need a consumption-aware scanner anyways (e.g. that lists images running in your Kubernetes). Anything else will be too spammy, as you can't notify for everything for you have at some point in time have used as a base image.
Also note that one of the features of Enterprise Edition is our integrations with Slack, email, GitHub, webhooks, etc. This enables really simple but powerful notification and automation scenarios based on image fixes (amongst other triggers like a version you're using going EOL).
For example, with EE, you can create an action to automatically trigger a webhook or send a Slack message when an image you're using has a critical CVE that's likely to be exploited (we also integrate threat intel from EPSS, KEV, etc).
Definitely still value in having runtime scanning / visibility too, but EE makes it easy to do purely on the 'left' side of things too.
Pausing software updates by X days old is a hack at best for specific distribution platforms (npm), not a general security recommendation.
how can one be sure you don't do rugpull in the future?
Pull-through cache the images. Sure, they could decide you can't pull anymore, or impose problematic rate limits, but you shouldn't add a runtime dependency on their registry in any case.
Yep, these are just normal OCI compliant images served from a normal OCI compliant registry. You can cache them however you'd like.
The question was "why over DHI?"
1 and 2 are not a reason
3. no X, no Y, also not a reason
4. `rg agents`. Right
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.
3 is exactly the reason I've never bothered to try docker's offering; that definitely is a reason
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
Agreed. Also on front page the nginx container is 6 days old, so no daily builds
We build anytime any component within an image has a new upstream version. If there’s no new upstream versions, no reason to build.
Check out the changelog tab in each image listing and you can see exactly when and why we build each time
Where are these built? Can I see the Dockerfiles? How are they licensed? I get that they are free as in beer, but not libre/FLOSS?
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.
Thanks for your answer!
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.
In the risk reduction tab, it should compare the vulnerability count against the node-slim image. In my eyes, it takes away from the offering when they try to prop up the vuln count for the official images, and nobody deploys `node:latest`.
> nobody deploys `node:latest`
Oh how I wish that were true.
Even the :latest is something of a wish :)
You may / may not be surprised how many enterprises still run long ago EOL'd versions of various stacks, frequently on full blown OS base layers of similar vintage
What's the availability story? Docker Hub has pretty severe rate-limiting even if you're not an anonymous user.
No rate limiting or degradation of service for Community Edition. Same images, same registry as Enterprise Edition.
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.
John here (CTO and Co-Founder)… we’d be happy to answer any questions anyone has!
What can you say about long-term plans? The bitnami situation burned a lot of people I think, and yes we can cache your images, but switching providers still does not come for free.
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 :)
Thanks for the feedback!
Is there a single upstream that all images are based on? Debian? Arch? Alpine?
Curious how this plays into customizing images with creator, are you guys responsible for all the packaging?
Would my keester be on the line if say an upstream package got hit with an attack but I use it through creator?
1. Distroless base. Imagine an effectively empty filesystem that only includes the components needed to run the app. The package manager we use is apk from Alpine and we make our full package universe of >10,000 packages available freely to Community Edition users. If you want a more 'normal' experience with a shell and apk, use the -dev versions of images that are still minimalistic but include a little more tooling like this.
2. For creator, you're basically taking any image from our public gallery and able to add whatever other packages from our universe to it, set env vars, upload files (customers typically use this for adding conf files and certificates). Then we maintain that image 'recipe' for you continuously, under the same SLAs we do all the public images. More details at https://docs.minimus.io/enterprise-edition/image-creator#ima...
3. Nope :) We are building every package across our universe continuously. Whenever there's a new version of any of them, we pull source, build package, compute what images (including creator ones) use that package, rebuild those images, test, sign.
Any plans to add IPv6 support? NAT GW are costly and docker hub has full support.
currently reg.mini.dev does not have AAAA records. Did not check the blob storage endpoints.
Certainly something we can add, just not something any customers have wanted thus far.
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!
The free tiers always go away, after they're deep in our infra. I would prefer to price it from the start.
We would be happy to sell it to you today! :)
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.
Is their ingress-nginx-controller image similar to that of Chainguard: a drop-in replacement with the CVEs fixed?
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.
This particular image is a bit different though.
By CVEs I mean the architectural stuff that was discovered after the original ingress-nginx repo was archived, so there is no "official" mitigation and it's not just a matter of bumping dependencies, the fixes are actual code.
Chainguard forked the repo and is maintaining their own distribution now, but it's not free.
yes it is
Supply chain attack waiting to happen
Maybe it's their business model? Sell to bunch of people and hook them in, then "get hacked", whoops sorry.
Edit: honestly I'm flagging this post. This really looks like fishing for customers to make them vulnerable in future.
Not sure what you mean here. We have many enterprise customers, in industries including government, health care, financial services around the world. The whole value of the product is helping them avoid all the risk and work associated with poorly maintained container images. We publish a full SBOM for every image so you can see exactly what's inside of it. We've worked across the industry and OSS communities to enable scanning support as well, so you can easily use whatever scanning tools you currently use (e.g. Wiz, AWS Inspector, Grype, etc) to check our images.
What are you even talking about?
How? If this, then so is DHI.
I truly don't get this. What is the security policy here? Why should I trust images built by minimus.io? How do I know they don't contain malicious software? What's the point?
We build all these images directly from upstream source across thousands of projects and assemble them into standard OCI images for you. We do this continuously, every time there are new versions released upstream.
The point is that you can just use these images instead of what you already have and reduce your vulnerabilities by 97%+ on average.
Think Docker Hub, just without the vulnerabilities.
Pinky promise? How do you prove that what I download from you is actually what you promise you've build (and that SBOM is right)? Is this certified with some digital signature?
From my threat attack model, you're just yet another liability - one single service to hack all your "safe" images.
Sure, but you could make the same argument for literally any software that you're getting that was built by someone else and have not personally inspected each line of source in. For example, you could make the same argument about RHEL or any image on Docker Hub or literally anything you're not building yourself.
Respect your viewpoint and if these images aren't for you, that's totally fine of course. Many others find it useful to have someone else doing the commoditized but hard work of building thousands of components from source continuously, assembling them into ready to run images, signing, and being as open as possible about their state and configuration as possible.
good job!
this space is too crowded now. everyone is copying whatever Chainguard is doing
- Chainguard Images
- Chainguard Libraries
- Chainguard VM
...
Free markets work :)
With Minimus Community Edition, you now have access to 1,000s of built from source, near 0 CVE images without cost or friction
Because Chainguard cost an arm and a leg.
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, is this better than the usual containers? How? Supported platforms? Can I run it on arm? The usuals
It’s a library of near 0 CVE images available to use for free. Think Docker Hub, just without vulnerabilities.
They’re all normal, OCI compliant images. You can pull them, run them, and build on them like you would any other image.
arm64 and amd64 builds for everything
> just without vulnerabilities
You surely mean "without known and reported vulnerabilities". I doubt you're proactively fixing the world across thousands of software packages /s
Correct, we are not claiming to be auditing the source of every software package in the world. The value we provide is a minimalistic architecture so you start with a significantly smaller attack surface and continuous builds of upstream so you stay at a near 0 CVE state without the substantial work required to do so yourself. Basically, we help you get all the upstream fixes from across the OSS ecosystem as quickly, safely, and easily as possible.
Minimus images support both amd64 and arm64. When you run the docker pull command, it will automatically pull the correct architecture for your system.
You can also review the different SBOMs for the amd64 and arm64 images, for example - https://images.minimus.io/gallery/images/python-fips/lines/3...
yes all the images have ARM64 versions as well as x86_64
noice!