CloudLinux Adds ELS as MariaDB 10.6 Approaches End of Life

CloudLinux says MariaDB 10.6 reaches community end of life on July 6, 2026, and is offering an Extended Lifecycle Support path for hosting fleets that cannot safely move every database server before the maintenance cutoff.

The company announced ELS for MariaDB on June 18, framing the service as a way to keep MariaDB 10.6 systems patched after upstream community maintenance ends. The timing matters for shared-hosting providers, managed WordPress operators, and enterprise teams that standardized on the 10.6 long-term branch years ago and now have only weeks before the community security-patch window closes.

CloudLinux’s date matches the MariaDB Foundation maintenance table, which lists MariaDB Server 10.6 with a July 6, 2021 GA date and a July 6, 2026 community maintenance end date. MariaDB’s current long-term release table also shows newer supported branches, including 10.11 and 11.4, which is why CloudLinux is presenting ELS as a bridge rather than a replacement for an upgrade program.

What CloudLinux is offering

According to CloudLinux, ELS for MariaDB is available now to CloudLinux customers and is built and maintained by TuxCare, the CloudLinux sister company behind KernelCare and Endless Lifecycle Support. The service is designed to deliver patched MariaDB 10.6 packages through the package manager operators already use, without requiring a data migration or major-version change at the same time.

CloudLinux says the patched build remains MariaDB 10.6, with fixes backported into the open-source release line and delivered as signed package replacements. That distinction is important: the pitch is not that operators can ignore modernization forever, but that they can separate emergency security maintenance from the larger, riskier work of database-version migration.

Why the cutoff is operationally awkward

For a single application, a MariaDB major upgrade can be a planned maintenance event. For a hosting fleet, it becomes a compatibility program. Customer applications, stored procedures, backup routines, connectors, replication setups, monitoring checks, and control-panel integrations may all assume the behavior of the installed database branch.

CloudLinux specifically warns that “just upgrade” is rarely simple for hosts because the engine itself is not the only moving part. A rushed migration can turn a security deadline into customer-facing incidents if application queries, extensions, or operational tooling behave differently on the newer branch. That is why the announcement targets hosting providers and other fleet operators rather than small deployments that can test and upgrade quickly.

Where CloudLinux says coverage applies

The initial coverage described by CloudLinux is MariaDB 10.6 on x86_64 for CloudLinux 7, 8, and 9, along with other Enterprise Linux 7, 8, and 9 systems such as CentOS and Oracle Linux. The company says other distributions are available on request.

CloudLinux also separates the CloudLinux 7 case from newer systems. If a CloudLinux 7 ELS customer already installed MariaDB from the CloudLinux ELS repository, CloudLinux says those packages are already on the patched update path. If MariaDB came from a third-party repository, the company recommends moving that server onto the CloudLinux repository path so package-manager updates can pull the supported builds.

Upgrade still remains the strategic answer

ELS changes the immediate risk calculation, but it does not make MariaDB 10.6 a modern target branch. MariaDB’s own maintenance table shows 10.6 leaving community maintenance in July, while later long-term releases continue further into the decade. That gives operators a clear split between short-term patch continuity and long-term platform planning.

The practical reading is straightforward: teams that can complete a tested move to a supported MariaDB branch before July 6 should still do it. Teams that cannot should avoid letting unsupported database binaries sit under production workloads while they finish compatibility testing, customer communications, rollback planning, and staged migrations.

What operators should do before July 6

Hosting teams with MariaDB 10.6 still in production should first inventory exactly where the branch is running and which repositories provide the installed packages. That repository detail matters because two servers can report the same database version while having very different patch paths after upstream maintenance ends.

Second, operators should classify workloads by upgrade risk. Low-risk internal services may be candidates for a direct move to a supported branch. Customer-facing shared-hosting nodes, legacy application clusters, and tightly coupled replication environments may need a staged plan with ELS used as a safety net.

Third, security and compliance teams should document the decision. If a server remains on MariaDB 10.6 after July 6, the evidence should show whether it is covered by an extended-maintenance provider, how updates are delivered, and when the eventual branch upgrade is expected. That turns an unsupported-software exception into a managed transition instead of a hidden liability.

CloudLinux’s announcement is ultimately a reminder that database end-of-life dates are not just calendar entries. They are release-management deadlines for the systems that hold application state. ELS can buy time, but the teams that use it well will spend that time reducing their dependence on a branch whose community maintenance window is closing.

Sources: CloudLinux announcement; MariaDB Foundation maintenance policy.