July 2026 – Effectively the end of the DirectAdmin Legacy License

Please select the option that best reflects your current situation:


  • Total voters
    13
@Richard G is correct . MariaDB 10.5 is EOL, and while AlmaLinux promises support until 2032, that doesn’t mean they’re on the hook for fixing everything. They’ll backport critical updates if MariaDB releases them, but beyond that, AlmaLinux’s support is limited. They’re not legally required to patch every vulnerability or fix every issue, so relying on this isn’t the same as using actively supported software.

-------------------

As for @virtio (the thread starter), their point really hasn’t been addressed yet. The issue wasn’t about our sustainability choices, but how we went about them. Referring to the codebase as "legacy" without offering a clear roadmap was a huge pain-point, especially for large-scale operations.

When you’re dealing with big infrastructure, "maybe" or "you might get more" isn’t enough to make decisions on. It could even get you in hot water with regulators. @virtio we more than accept the premise of your post and thank you for your professionalism and willingness to see things from our side. In return for that, we will do the same, and publicly admit you could of called us "amateur hour" and been justified in doing so. Thanks for being a class act.
 
Once you are done with the mutual flattery, could we please get a precise answer as to how Directadmin will handle the upcoming database issue in the future? If at all?
 
If I remember correctly this was tested, should be even a thread about it somewhere here. Somebody installed MariaDB 10.11 manually and got a notice that this was not allowed.
Maybe it's possible to install some other database, but then the connection with DA is lost again (managerble, user can create databases etc).

So that is why I ask about the idea previously made somewhere, to allow the OS updates for MariaDB once 10.6 is EOL. So users can choose either keep running an EOL version or choose your suggestion of database on another server, or downgrade to 10.5 and have the OS keep doing the updates.
Either way, this should be no issue for DA and no extra development. And would make life easy for people who would like to keep things as they are now for a bit longer. Because with the EOL date of Alma 9 in 2032 it's end of story anyway, probably even sooner depending on which updates are coming (or rather not).

If I remember correctly the idea of giving users choice to have the OS do the updates after EOL of the database was under consideration.
As someone who also maintains my own stack where I have to decide which versions of MariaDB to support, I can see both sides - DA side and legacy end users' sides.

The act of switching MariaDB server versions accounts for only 10% of dev work. 90% is testing and understanding every conceivable configuration and testing all deprecating and newly introduced MariaDB server variables and changes in behaviour that come with different major MariaDB versions and then making sure it fits in with the framework and routines for your stack (DA). That work gets larger as MariaDB major versions keep incrementing from 10.6, 10.11. 11.4. and 11.8 for LTS releases.

I don't have legacy DA license (before my time), but I can guess 10.11 was probably programmatically blocked just to protect end user from screwing up their system as DA folks probably haven't tested every conceivable config and issue with MariaDB 10.11 and legacy software. It's what I do with my own stack to block no-yet tested MariaDB major versions with my stack to prevent users from screwing up their system.

The alternative would be for DA to remove the routine that blocks it, but have a check box that users agree it can break and render their legacy DA's MariaDB unusable and they're on their own without any support from DA to fix anything that breaks for untested MariaDB versions. The legacy DA users who are adventurous can test newer MariaDB major versions and see what breaks etc.

Just my AUD$0.02
 
And somehow I still provide PHP7.4 for customer with warning (EOL) to ensure no complain later when something go wrong. 😒

Like some filter ( filter_var ) can bypass some options.
 
could we please get a precise answer as to how Directadmin will handle the upcoming database issue in the future? If at all?
There will be no changes for the legacy license holders. Without a new license DA will not work with modern MariaDB/MySQL. Servers with legacy licenses can continue using MariaDB 10.6 forever.
 
Servers with legacy licenses can continue using MariaDB 10.6 forever.
Does that mean that legacy licenses will be supported forever, too? Asking for a friend.

NB. I know they won't work with newer OS's (e.g. Debian 13 and beyond), but I'm just trying to figure out the forever part.
 
Does that mean that legacy licenses will be supported forever, too? Asking for a friend.
Define "supported"?

IMHO in software land "forever" means "as long as it's available and no hard EOL is declared or a company does not go broke or get's sold".
So that's what I learned in the past years what forever or lifetime means.

The legacy DA users who are adventurous can test newer MariaDB major versions and see what breaks etc.
They already can do that, but if they do, the connection with DA will instantly get disconnected. Which of course is logical because DA does not want to fix issues caused by adventurous users.
Which is also the reason I won't post the option on how to do that in public. It has already been mentioned publicly somewhere which is how I know, but I won't repeat that again.
If somebody wants to know, they can pm me. But be aware it will instantly break current database connections with DA and causing a very big chance to mess things up, so use at your own risk!!
 
@LawsHosting Yes, you’re free to keep running the legacy license as long as it works for you. Not too different than those asking how long they can stay on the CentOS 6 or FreeBSD builds. Forever = as long as it works for you.
 
I just checked the backporting of MariaDB 10.5 (which is already EOL) and this was an update of November 7th. And this was a moderate security issue not even a high one. So maybe I was partly mistaken.
While it's ofcourse not as safe as an up to date version, it looks like backporting (which is possible with MariaDB 10.5 on Alma 9) would be slightly safer then keep using 10.6 without a backport option after it's EOL.
Still, not secure, but slightly more secure. Right?
 
Without going into details you can get very misleading results. Let's take the first security fix that was recently released for RHEL8 systems:

Code:
* mysql: High Privilege Denial of Service Vulnerability in MySQL Server (CVE-2025-21490)

It is released with new RPM for RHEL 8 systems at 2025-11-07. However, MariaDB developers fixed this issue CVE-2025-21490 in MariaDB 10.5.28 on 2025-02-05 (almost a year ago). At that time MariaDB 10.5 was not yet EOL, the 10.5 is EOL since 2025-06-16.

So if you would be using MariaDB 10.5 with DirectAdmin (having mariadb=10.5 in CB options.conf), you would have received the fix for this issue on 2025-02-06 if you use alpha release channel (1 day after official release). If you use current release channel you would get it on 2025-03-01 with DirectAdmin 1.674 release.

The fact that distro maintainers released this fix half a year later tricked you into reaching wrong conclusions :).

Please do not get the wrong impression that distro maintainers deliberately wait too long, other fixes in that page came with MariaDB 10.5.29 which was released later.

Summary:
  • CVE-2025-21490 fixed in MariaDB 10.5.28 released 2025-02-06
  • CVE-2023-52969 fixed in MariaDB 10.5.29 released 2025-05-08
  • CVE-2023-52970 fixed in MariaDB 10.5.29 released 2025-05-08
  • CVE-2025-30722 fixed in MariaDB 10.5.29 released 2025-05-08
  • CVE-2025-30693 fixed in MariaDB 10.5.29 released 2025-05-08
I have picked the first one for dramatic effect. But still all the fixes was released in upstream before 10.5 became EOL. And DA users would have gotten them half a year faster.
 
In the past, we provided DirectAdmin licenses to customers primarily to reduce our own management overhead. Effectively, every VPS of around 50 EURO included a license, which allowed us to bring the server under our (cheaper) managed service. If a customer later decided to purchase their own DirectAdmin license, or even move the VPS elsewhere (we are not the cheapest out there after all), we refunded the license cost. As long as the customer committed for a year, this worked well for all parties involved.

From our perspective, this meant a small investment (well under 100 EUR) that typically resulted in three to four times that amount in return, yearly, not because of the license but our work. For customers, it meant they did not have to worry about routine updates or operational decisions such as whether or not to apply them. This model kept infrastructure costs at a reasonable level, often below 15% of a customer’s monthly spend, which is a healthy balance for everyone.

With a license cost of roughly 29 per month, that balance changes significantly. At that point, a full license only makes financial sense if a server generates approximately 200 EUR per month in revenue, excluding the cost of the VPS itself. Inevitably, this might cause a portion of providers to lose some customers or switch to something free-ish again.

While painful for legacy users, this move does have parallels with the Vmware/Broadcom licensing changes in 2023–2024. Vmware was not fundamentally harmed by this, largely because it already had a deeply vendor-locked enterprise customer base and vmware was never chosen for being inexpensive. However, this did not prevent alternatives such as XCP-ng and Proxmox from rapidly maturing into enterprise-grade solutions, including straightforward migration paths away from vmware. DA itself offers import tools from competing panels, which illustrates how dynamic this market can be.

From a purely commercial standpoint, discontinuing legacy licenses is understandable. Recurring monthly revenue is generally more attractive than one-time payments, and in that sense the decision is rational.

That said, it also effectively reframes the market. What was once an unbeatable user base of ~890K per 10K full licenses that would never leave DA, becomes, in revenue terms, a multi-million annual market. This is a substantial shift that has not gone unnoticed by everyone capable and willing to grap a piece of that cake.

For many of us, DA was appealing because it offered stability without mandatory subscriptions and that is an important factor when building a business, a side project, or even a hobby site. That sense of long-term predictability was a key part of the platform’s value proposition.

I would hate to see that disappear and I would also hate to see low hanging fruit switching to every jack&jill's 'hey, I want this free controlpanel'.

Allowing those people to compile their own mysql or whatever, without da preventing to do so, would fill a gap for the little McGuyver users. Any selfrespecting hoster will most likely easily pay 29 bucks a month if it prevents them from compiling stuff for hours every once in a while.
 
I have picked the first one for dramatic effect. But still all the fixes was released in upstream before 10.5 became EOL. And DA users would have gotten them half a year faster.
Thank you very much for enlightening this to me/us. I was just wondering if and how many fixes there would be released and how many already were released in the meantime for an EOL MariaDB to get a small insight of how often this might happen.

As stated in my previous post, iit still is a security risk, one is not safe, but I was just looking if it was worth it to get a slighly minimal better security. In the sense of any update (even late) is better than none at all.
But if it even takes almost a year for an update on a database which wasn't even EOL at the time, then this is good to know. And to me it's not worth the effort in that case.

Allowing those people to compile their own mysql or whatever, without da preventing to do so, would fill a gap for the little McGuyver users
They still can, but as said then the connection with DA will be lost instantly. If the blockage would be removed, than as happened before, there will be customers complaining about their systems not working and DA won't support that on legacy, so a lot of whining and complaining will be the result, no single company would want that.

With a license cost of roughly 29 per month, that balance changes significantly.
For datacenters it would be less as there are discounts for more licenses. And I don't know if they also can make use of the 15/month conversion. For us at this time even that is a whole lot too as there is no pause option.
I do agee that also this 15/month especially for small hosters is a significant change which hits us hard.
But that decision is made and as far as I understood, it won't roll back. As you said, the change is understandable and maybe it was needed, because knowing DA from the beginning, that was not their intention with those licenses.
However, compared to other licenses, DA is still way cheaper.
And at this moment I didn't see Hetzner loosing a lot of money after stopping to provide all servers/vps with cPanel and Plesk licenses. So customers take their loss. Some will buy a ilcense themselves and then for the hobbyists those 5/month for the personal license is still very cheap.
For sure there will be some going to free licenses too, but there is no way of stopping this.
Since servers and VPS systems always will be required to get things online, we have to see if it would be indeed a big loss of income for datacenters with the new prices, but I guess not.
The licenses cost nothing anymore so one can still sell/rent the servers/vps without license, so the only change for the customers is to either see what he chooses for panel (free or commercial) or he wants to go with ancient unsupported EOL stuff.
 
Everything is different if you buy 100 of anything, well maybe not with paperclips.

My point is that legacy licenses also meant keeping that user base 'DA hooked'. Might not have the best revenu, but it prevented them from shopping somewhere between free and 350 a year, in the end this had a marketing longtail that businesses often only dream about.
 
My point is that legacy licenses also meant keeping that user base 'DA hooked'.
But in who's interest would that be? Not for DA in anyway because it's not "not the best revenu" but "no revenu at all" as these licenses are all long payed for, many more than a decade ago.
And all the new development must come from somewhere, so not from all lifetime licenses or al customers coming over from CP renting servers and VPS systems with lifetime licenses.
 
Back
Top