{"id":4909,"date":"2026-08-24T13:21:04","date_gmt":"2026-08-24T13:21:04","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/24\/minio-end-of-life-how-to-stay-patched-and-audit-ready-with-docker-els\/"},"modified":"2026-08-24T13:21:04","modified_gmt":"2026-08-24T13:21:04","slug":"minio-end-of-life-how-to-stay-patched-and-audit-ready-with-docker-els","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/24\/minio-end-of-life-how-to-stay-patched-and-audit-ready-with-docker-els\/","title":{"rendered":"MinIO End of Life: How to Stay Patched and Audit-Ready with Docker ELS"},"content":{"rendered":"

MinIO reached end of life in February 2026. Docker Extended Lifecycle Support (ELS) keeps end-of-life software like it patched, compliant, and audit-ready for up to five years, covering versions upstream no longer supports all the way up to entire projects.<\/em><\/p>\n

On February 13, 2026, the MinIO open-source project was archived upstream. A project with more than a billion Docker pulls<\/a> stopped shipping releases, bug fixes, and security patches overnight. From that day forward, every environment running MinIO is exposed. New CVEs in MinIO and its Go dependency tree now arrive with no upstream patch behind them, and an audit reads that as unsupported software in production.<\/p>\n

And MinIO is only the newest instance of a wider problem. Black Duck\u2019s 2026 Open Source Security and Risk Analysis report<\/a> found that 93% of commercial codebases carry components with no development activity in at least two years. The same pattern runs across the stack. Node 18, Python 3.8, and older Airflow releases still run in production long after upstream support ended, and frameworks like FedRAMP, DORA, and the Cyber Resilience Act treat unpatched end-of-life software as an audit finding. The migration deadline ends up set by the audit calendar instead of the roadmap.<\/p>\n

Docker Hardened Images<\/a> Extended Lifecycle Support exists to hand that schedule back to you. The model is simple. Request an ELS image, and Docker builds and maintains it for up to five years past upstream end of life. The maintained MinIO image is the newest proof of that model.<\/p>\n

\n MinIO lives on as the newest ELS update<\/strong>\n<\/h2>\n

The archive lands on the storage layer, where migrations are measured in petabytes. Moving a production object store to a different system is slow, expensive work, and the CVE exposure keeps growing while that work runs.<\/p>\n

Teams running MinIO have three options<\/p>\n

    \n
  1. Move to a commercial replacement and take on new licensing and lock-in.<\/li>\n
  2. Carry the patches yourself, which means staffing sustained Go security engineering for a project that no longer ships fixes.<\/li>\n
  3. Keep what you run and put a vendor on the hook for it.\u00a0<\/li>\n<\/ol>\n

    Doing nothing is not a fourth option.\u00a0<\/p>\n

    Docker identified the archive as a live exposure across its customers\u2019 software supply chains and built the answer into the catalog, where MinIO lives on as a maintained, hardened image. Docker tracks new CVEs across MinIO and its full Go dependency graph, transitive dependencies included at no extra cost, then backports the fixes, rebuilds, and ships. Your object store stays supported and your audits stay clean.<\/p>\n

    \n Extended Lifecycle Support for your whole fleet
    \n <\/h2>\n

    \n<\/p>

    What ELS does for MinIO, it does for any end-of-life component you need to keep. An EOL finding forces a choice between two bad projects. Rush the migration and risk breaking production, or file the exception and watch the list grow every quarter. ELS removes that deadline. Patches and audit evidence keep flowing on the images already in production while the migration happens on the roadmap\u2019s schedule.<\/p>\n

    The entitlement is built for how end of life actually arrives, on staggered dates across a fleet. Applied to a repository, it covers every available ELS version there. When one migration completes, you re-point it at the next repository, and the coverage moves with the risk.<\/p>\n

    Coverage is not limited to a fixed list either. Docker watches the end-of-life calendar and builds ahead of it, and anything you don\u2019t see in the catalog, you can request. The span runs from end-of-life versions of supported software all the way up to entire archived projects. Nginx, Node, and Python ELS images are already there.<\/p>\n

    ELS is a paid add-on to a Docker Hardened Images subscription, and it runs on the same rails as the rest of DHI:<\/p>\n