MariaDB 10.6 EOL Checklist for cPanel and CloudLinux Hosting Servers

MariaDB 10.6 reaches community end of life on July 6, 2026. Here is the cPanel and CloudLinux checklist for backups, upgrade paths, ELS planning, and post-change verification.
MariaDB 10.6 EOL database upgrade checklist for cPanel and CloudLinux hosting servers

MariaDB 10.6 Community Server reaches end of life on July 6, 2026. If your cPanel, CloudLinux, shared-hosting, agency, or application server still depends on MariaDB 10.6, this is the maintenance window to plan now instead of during a failed update later.

The short version: inventory the database version, take real backups, choose an upgrade or extended-support path, test customer applications, and verify database health after the change. Do not treat this like a normal package refresh.

What changes on July 6, 2026

MariaDB Foundation lists MariaDB 10.6 with a community end-of-life date of July 6, 2026. After a release is end of life, MariaDB Foundation says it will not provide community security updates for that release line. CloudLinux also published a hosting-focused notice warning that the MariaDB project stops shipping releases, bug fixes, and security patches for the 10.6 branch after that date.

That matters for web hosts because the database engine is shared infrastructure. WordPress, WooCommerce, Joomla, Drupal, WHMCS, Magento, Laravel, billing portals, control-panel tooling, and custom PHP apps can all be tied to the same database service.

Who should check this now

  • cPanel and WHM servers still running MariaDB 10.6.
  • CloudLinux 7, 8, or 9 servers with MariaDB 10.6 packages.
  • Shared-hosting and reseller nodes where many customer sites share one database engine.
  • Standalone LAMP or LEMP servers that were built around MariaDB 10.6.
  • Agencies managing older WordPress, WooCommerce, Joomla, Drupal, WHMCS, or custom PHP sites.

Version inventory

Start by recording the current database engine and where the packages come from. In WHM, check Database Services > MySQL/MariaDB Upgrade or the renamed Upgrade Database Version interface on newer cPanel builds. On CloudLinux, also confirm whether MySQL Governor is installed because cPanel documents that the WHM upgrade interface will not handle database upgrades when CloudLinux MySQL Governor exists on the server.

For fleet work, build a small tracking table: hostname, operating system, cPanel version, database engine, database version, CloudLinux status, MySQL Governor status, backup status, application owners, maintenance window, and planned target version.

Upgrade target planning

For many cPanel servers, MariaDB 10.11 is the practical long-term target because cPanel currently lists MariaDB 10.11 as an available version and says it will only support long-term MariaDB releases after MariaDB 10.6. cPanel version 136 also added MariaDB 11.8 support in WHM’s database upgrade flow, but a newer database branch should be tested against real applications before it becomes the default fleet choice.

If you cannot upgrade before the deadline, CloudLinux is offering ELS for MariaDB 10.6 through the CloudLinux ecosystem. Treat that as a bridge for servers that need more compatibility testing, not a reason to skip the migration plan entirely.

Backup and rollback reality

cPanel’s database upgrade documentation tells admins to back up server databases before upgrading or changing to MariaDB. It also warns that database downgrades are not supported through the interface. That means rollback planning needs to be more than a hopeful note in the ticket.

  • Take a provider snapshot if your platform supports it.
  • Confirm remote backup jobs completed recently and can restore.
  • Export critical databases before the maintenance window.
  • Check free disk space and inode headroom before the upgrade.
  • Document replication, remote MySQL profiles, custom applications, and cron jobs that touch databases.

cPanel and WHM upgrade notes

Use WHM’s normal database upgrade workflow for supported cPanel servers. Choose interactive upgrade for higher-risk servers so you can read warnings, run checks, and stop before the final change if the environment is not ready. cPanel stores MySQL and MariaDB upgrade logs under /var/cpanel/logs with names like mysql_upgrade_log.YYYYMMDD-hhmmss.

After the upgrade, verify the database service, control-panel access, representative customer sites, WooCommerce checkout, WHMCS billing functions, backups, monitoring, and mail-related apps that write to MySQL or MariaDB.

CloudLinux and MySQL Governor note

If CloudLinux MySQL Governor is installed, do not force the cPanel database interface around it. cPanel specifically points admins back to CloudLinux’s MySQL Governor documentation. Plan that work as a CloudLinux maintenance item with customer-impact review, package-source verification, and database service monitoring.

Application compatibility checks

  • Update WordPress core, WooCommerce, plugins, and themes before testing database behavior.
  • Check Joomla, Drupal, Magento, PrestaShop, WHMCS, Laravel, and custom PHP apps for supported MariaDB versions.
  • Test PHP database extensions and site health after the database change.
  • Look for old SQL modes, deprecated database behavior, strict-mode surprises, and broken reporting queries.
  • Run checkout, login, search, form, and admin workflows on representative production sites after the upgrade.

Customer communication

For shared-hosting nodes, tell customers the maintenance is a database lifecycle update, not a site redesign or account migration. Give the maintenance window, expected service impact, what you will verify, and how customers should report post-change errors. Ecommerce and membership sites should get extra attention because database changes show up quickly in carts, orders, logins, and subscriptions.

Fix I.T. Phill recommendation

If the server is already on MariaDB 10.11 or a newer supported branch, document that and move on to normal patching. If it is still on MariaDB 10.6, pick one of two paths: upgrade through a tested cPanel/CloudLinux maintenance window, or use a supported extended-maintenance bridge while you finish application testing. The weakest option is leaving a shared database engine on an unsupported branch with no owner and no dated upgrade plan.

Related Fix I.T. Phill guides

Sources checked

Validation marker: fixitphill-mariadb-106-eol-20260618.

Picture of admin

admin

Leave a Reply

Sign up for our Newsletter

Get the latest information on what is going on in the I.T. World.