TL;DR

Minimus announced on 24 August 2026 that it is shutting down. The registry at reg.mini.dev goes offline permanently on 22 October 2026. Images you have already pulled will keep running after that date, and they will stop receiving updates. Minimus has committed to a fair and orderly conclusion to its Enterprise Edition contracts, and CTech reports that customers are being contacted individually, with refunds for contract periods extending beyond 22 October. If you run Minimus images in production, you have roughly 8 weeks to inventory what you are running, choose a replacement, and migrate.

‍

Ninety-eight percent (98%) of applications include open source software, and for many teams the largest concentration of it sits in container images. Many organizations have partnered with vendors to secure them, and that arrangement works, right up until the vendor who assembles them stops.

That is where a number of engineering teams found themselves this week.

The Minimus team built something good. Ben Bernstein, Dima Stopel, and John Morello founded Twistlock, and Morello wrote NIST SP 800-190, which is still the reference document for container security. A 60-day maintenance window and refunds for enterprise customers are a more orderly wind-down than most companies manage. None of that changes the work now sitting on your plate.

The images keep running, which is the part that catches teams out

Nothing breaks on 22 October. That is precisely the risk.

Container images are immutable. Whatever you have pulled into your own registry keeps working exactly as it did the day before, so your pipelines stay green, your deployments stay clean, and nothing pages anyone at 3am. What stops is the upstream maintenance. From 22 October, every Minimus image in your estate is frozen at whatever CVE posture it had that morning, and every vulnerability disclosed afterward accumulates against it with nobody upstream publishing a patched build.

The visible symptom arrives later. Your scanner findings climb through November. Your Q1 audit asks why a set of production images has not received a security update in five months. Seventy-eight percent (78%) of organizations have already failed a compliance audit because of CVEs in their container images, and that’s not accounting for running deliberately frozen ones.

So the deadline that matters is not the day the registry goes dark. It’s the longer timeframe in which your remediation posture quickly declines.

Start with an inventory, not a vendor evaluation

The instinct under time pressure is to find another solution instantly, but most teams don’t have the full picture of what they’re running today.

Before you decide, you’ll want answers to four questions:

• Which Minimus images are in your registries, and which of those are genuinely in production?
• What is layered on top of each one? Language runtimes, application dependencies, internal libraries, configuration.
• Which images were pulled from the public catalog, and which were custom builds produced for you under an enterprise agreement? The second group is harder to replace and should drive your timeline.
• Which of these sit in a regulated workload, where an unpatched image is an audit finding rather than a backlog ticket?

That list is the input to every conversation you are about to have, and building it is work you own regardless of where you land. It is also the single best defense against choosing a replacement that covers your simple images and leaves your three hardest ones stranded in October.

How teams typically replace a hardened image supplier

There are four common paths. Some aren’t relevant to every production environment. 

Go back to public base images and harden them yourself

Cheapest on paper. In practice you are absorbing the build infrastructure, the CVE monitoring, and the remediation cadence that you previously made the decision to offload to your vendor. Ninety percent (90%) of organizations already run lightly modified public images with little to no hardening, which is a fair indication of how often teams have the capacity to do this well.

Switch to another hardened base image provider

The fastest path, and the right one if your requirements really are base-image-shaped. Repoint the registry, update your Dockerfiles, revalidate, done. Check language and component coverage against your actual inventory before you commit,  so you can be assured your images will keep functioning as they do today.

Move to your cloud provider's managed images

Reasonable if you are already consolidated on one cloud and your workloads are mainstream. Less useful for multi-language estates or anything with unusual runtime requirements.

Govern both the base image and the packages within it 

Keep assembling your own images, which you are likely doing already, and change where the components in the base image come from. More disruptive to evaluate, but it addresses more of the problem, i.e., software supply chain security. AI and typo-squatting, malware, and CVEs against EOL components impact software products today, no matter which container they run in. 

The question worth asking while the decision is still open

Here is the part that makes this migration different from an ordinary vendor swap.

A hardened base image secures the operating system layer. That is a real and difficult piece of engineering, and the vendors doing it are doing it well. But your application does not run on the base image. It runs on the Python, Java, Node, and Go packages and dependencies your team layers on top. In most cases those come straight from public registries with no vetting, no provenance, and nobody contractually accountable for them.

Eighty-three percent (83%) of DevSecOps leaders identified outdated base images as the root cause of their most recent vulnerabilities. Seventy-seven percent (77%) say they trust curated catalogs more than public registries. Ninety percent (90%) use lightly modified public images anyway. The gap between the second and third numbers is where most container risk actually lives, and swapping one base image supplier for another does not close it.

You are going to need to rip out and re-select your base image layer over the next 8 weeks whether you want to or not.  So it’s worth spending a moment  asking if you want to solve a larger fraction of the problem this time. 

The question nobody asks their vendors

There is a second question sitting underneath this migration, and most people are too polite to put it to a vendor directly.

If you just watched a well-funded company with excellent founders and a good product wind down 18 months after launch, why would you hand the same trust to another vendor? It is a fair question, and one that you should ask of any vendor  you talk to over the next 8 weeks.

Our answer is that ActiveState has been doing this for almost 30 years. We started in 1997 building and maintaining language distributions, and enterprises have been running our builds in production continuously since then. The work supporting your actual application: building secure open source software from source, tracking upstream CVEs, and shipping supported artifacts to enterprises on a schedule, is what the company has done for its entire existence.

A practical takeaway that applies to every option in front of you: ask what happens to your images if the vendor shuts down for whatever reason. Ask whether you get the build definitions. Ask whether anything you receive is portable. 

What ActiveState covers, and what it does not

ActiveState has been securing open source software for enterprises for almost 30 years, and we have been making the argument for both secured containers and libraries publicly since June 2025, well before this week. 

Start with what we are not. We do not compete on the number of prebuilt images sitting on a shelf. If what you need is a large public catalog you can browse and pull from anonymously, other options will serve you better.

We also will not pretend to hand-build every image you run. Nobody can. Count the permutations of language version, framework, and dependency set across your own estate and the number runs into the thousands at a single company. Any vendor promising a bespoke prebuilt image for all of them is describing something that does not scale.

What we do is govern both layers. ActiveState provides hardened language-core base images, built from source with SLSA level 3 provenance. Your team then builds on top of them the way it already does, except the packages and language libraries going into those upper layers come from the ActiveState Curated Catalog rather than a public registry. That catalog holds millions of vetted components across nine of the major language ecosystems, each built from source rather than pulled as a prebuilt artifact of uncertain origin. Images ship with a build-time SBOM, cryptographic signatures, and VEX advisories, and remediation runs on contractual SLAs of 5 business days for critical CVEs, 10 for high, and 30 for all others.

The practical difference is narrow and it matters. You keep control of image assembly, which you need, because only your team knows what your application requires. What changes is that the components going into it stop being unvetted.

There will still be workloads we cannot cover. We would rather tell you that in week one than in week seven.

What to do this week

Build the inventory. It is useful no matter which direction you go, and everything else depends on it.

If you have it ready to go, contact us. We will map it and come back with a straight read: which of your images map to a language-core base, which layers your team would build on top from the Curated Catalog, which we do not cover at all, and what your images are carrying above the base layer that nobody is currently watching. It takes about a week, it costs nothing, and it does not require a meeting to start.

If your team hasn't put the inventory together yet, talk to a Container Security Engineer who can share timelines and failure points from hardened base-image migrations we've run before, or build the map with you live on the call, whichever is more useful.

If what comes back looks workable, we will run a 30-day POV against your own pipeline so your team can prove nothing breaks before anyone signs anything.

You have until 22 October. The teams that come out of this in better shape than they went in will be the ones who treated it as a decision rather than a replacement.