morellonet

We did this because we believe this market is becoming more about the integration and enterprise capabilities rather than just selling the images. The more people know about, use, and benefit from the images the more potential Enterprise Edition customers we can help.

Correct they do not have any rc

I’m not personally familiar with exe.dev but if it can run normal OCI images it should be pretty simple to use ours. If you want a shell and package manager and some common busybox applets, -dev variants are the best option.

Depends on your preferences but probably easiest approach is to take the -dev version of our PHP image and run a build from that to add whatever you need on top of that hardened base.

You can even do a multi step build if you want to use the fully minimalistic image at runtime. Details at https://docs.minimus.io/foundations/going-distroless

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

Yep, these are just normal OCI compliant images served from a normal OCI compliant registry. You can cache them however you'd like.

No rate limiting or degradation of service for Community Edition. Same images, same registry as Enterprise Edition.

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

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.

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.

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.

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.

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.

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.

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

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

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 :)

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.

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.

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.

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!

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)?

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.

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!

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

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

John here (CTO and Co-Founder)… we’d be happy to answer any questions anyone has!

It's on the roadmap :)

It's a good feature, just hasn't been prioritized so far because customers haven't really had trouble with the current basic approach.

Nope - we're early stage so we're really flexible not just on pricing but licensing terms too. We have many customers that are smaller startups, not just typical F500 types.

If you’re looking for an alternative here, we (the team that built Twistlock) launched Minimus a few months ago to provide near zero CVE images built continuously from source. We have long experience in this space (we even wrote NIST SP 800-190) and I’d love to talk if we could help anyone. We also have drop in replacement images and charts for Bitnami, as we describe here: https://www.minimus.io/post/the-bitnami-pricing-changes-what...

If anyone has tech questions about how it all works, tools we use, customer scenarios, etc I’d be happy to discuss.