If you run MariaDB on your hosting servers, there’s a date worth putting on the calendar: July 6, 2026. That’s when MariaDB Community Server 10.6 reaches end of life. After that, the MariaDB project stops shipping releases, bug fixes, and security patches for the 10.6 branch.
Today we’re announcing ELS for MariaDB, available now to CloudLinux customers. It keeps MariaDB 10.6 patched past its end of life, delivered as drop-in updates through the package manager you already use, so you can stay secure without forcing a database migration across your customers’ sites. ELS for MariaDB is built and maintained by TuxCare, our sister company and the team behind KernelCare and the Endless Lifecycle Support program.
What end of life actually changes
Contents
On July 7, your databases will keep serving queries exactly as they did the day before. Nothing breaks at midnight. The problem is slower and more dangerous than that, and it compounds over the months that follow.
Security patches stop. After July 6, vulnerabilities in MariaDB get fixed only in supported branches. The 10.6 branch goes quiet. When a project patches a supported version, the fix is public, so attackers can study exactly what changed and work out the underlying bug, then hunt for that same flaw in the versions that will never be patched. A database engine is a high-value target: it holds the data and it’s reachable from your application servers. On a shared hosting environment, an unpatched database doesn’t put one site at risk. It exposes every customer site that depends on it.
Compliance risk rises. Most security frameworks expect known vulnerabilities to be patched on a schedule. PCI DSS Requirement 6 calls for critical and high-severity patches within a month of release. SOC 2, HIPAA, and FedRAMP all expect timely, documented patching. An unsupported database can be the single finding that holds up an otherwise clean audit, and cyber-insurance reviews increasingly check for unsupported software too.
The ecosystem drifts away. Once a version reaches end of life, the software around it gradually stops supporting it. Distributions, container images, and third-party repositories move their defaults to newer releases. Six months in, the upgrade you were putting off has quietly gotten harder, not easier.
Why “just upgrade” is rarely simple for a host
Upgrading to a supported release like 11.4 is the right long-term move, and we’ll always tell you that. But on a fleet of hosting servers, a major database upgrade is a real project, not a one-line command.
The engine itself rarely slows you down. What slows you down is everything that assumes the behavior of your current version: customer applications, stored procedures, replication topologies, connector versions, and the surrounding tooling. MariaDB 11.0 even introduced a new optimizer cost model, so some queries can get slower until you tune them. Multiply that testing across thousands of customer databases and a fixed deadline, and the math gets uncomfortable.
Rushed upgrades are expensive in a specific way: they ship bugs, and on a hosting platform those bugs land on customer sites that were running fine for years. That shows up the next quarter as support tickets, refunds, and churn. For some servers, a major upgrade this year isn’t even worth it: a database behind an application that’s being replaced, or one running a fixed workload, may not justify the disruption.
The point isn’t that you shouldn’t upgrade. It’s that the upgrade should happen on a timeline you control, driven by engineering reality rather than a calendar date set by someone else.
How ELS for MariaDB works
ELS for MariaDB decouples security from the upgrade deadline. Here’s the mechanism:
- TuxCare tracks the CVEs. As new vulnerabilities are disclosed in MariaDB 10.6 and the system libraries it depends on, TuxCare backports the fixes to your open-source release.
- Patches arrive as drop-in package replacements. The patched build is the same MariaDB 10.6 version, signed and published to an ELS repository. Your yum or dnf pulls it like any other update. The engine stays 10.6; only the binaries get the fix.
- Your data and workflows stay untouched. No schema changes, no application rewrites, no disruption to replication or backup tooling. This is a binary swap of the same version, not a data migration.
- Coverage goes beyond the engine. ELS patches MariaDB’s dependency graph too: storage engines, system libraries, and crypto components, rebuilt alongside the core.
What this means depending on where you run MariaDB 10.6
ELS for MariaDB covers MariaDB 10.6 (x86_64) on CloudLinux 7, 8, and 9, as well as other EL 7/8/9 systems like CentOS and Oracle Linux. Other distributions are available on request. A few specifics:
On CloudLinux 8 and 9: MariaDB 10.6 loses upstream security patches on July 6 regardless of your OS support status. To keep those servers patched, you’ll want ELS for MariaDB.
On CloudLinux 7: if you’re already on CloudLinux 7 ELS and you installed MariaDB from the CloudLinux ELS repo, those packages are already on the patched update path. If you installed MariaDB from a third-party repository, the cleanest way onto coverage is to repoint to our repo so your package manager can pull the patched builds. Not sure where your packages came from? We can help check.
Anywhere else: if you run MariaDB 10.6 on other Linux distributions, ELS for MariaDB can still keep them secure. Talk to us and we’ll scope it.
The approach we’d actually recommend
Run ELS and your upgrade together. Use ELS to take the deadline off the table, then plan and test your move to a newer LTS release properly. In most environments, a year of coverage costs far less than the incidents, downtime, and emergency work a rushed migration creates.
July 6 is close. The good news is that getting covered is quick and changes nothing about how your databases run.
Existing CloudLinux customer? Enable ELS for MariaDB in the CloudLinux Network portal.
Running MariaDB somewhere else, or not sure what you need? Talk to our team and we’ll figure out coverage for your environment.
ELS for MariaDB is part of CloudLinux’s Endless Lifecycle Support program, in partnership with TuxCare.
