UPDATE 6/18: Shortly after this was posted and one of the major hosting companies I’m affiliated with removed BetterLinux from their servers due to stability problems, BetterLinux announced that they are shutting down, effective July 1st.

Customers ask us all the time whether they should use CloudLinux or BetterLinux on their servers, and what differences exist between the two.  I want to clarify that TCA has not done any structured or scientific benchmarking or testing between the two, nor are we partnered with or endorsing either company.  We do have quite a bit of experience with both though and may be able to help you decide which on, if either, may be best for you.

What you should know about both…

CL and BL were both developed to address two major problems with shared hosting: resource hogging and privacy.  On a typical server, there is little you can do to prevent a single customer from launching a process that can potentially over-use resources and adversely affect other users and/or crash the system. While today’s servers are pretty beefy and accommodating toward temporary spikes in resource usage, we see single users cause problems on servers all the time.  There’s also a general lack of privacy – users can see any process running on the server as well as certain files that expose the presence of other users (for example, /etc/passwd).  CL and BL, when configured properly, address both of these problems pretty well.

Both solutions work off of the concept behind cgroups, which is a native kernel feature of CentOS 6 (and newer) kernels that allows you to allocate resources to groups of processes.

As far as recommending these over a base CentOS installation, we do so when all of the following are true:

• Your environment is physical, a.k.a, not a VPS or VM
• You are hosting strangers, not your own websites
• You are running CentOS 6 or newer

While CL backports cgroups functionality to a CentOS 5 “hybrid” kernel, the feature is much more stable and tested on newer versions.

You should also keep in mind what a reasonable capacity is for your server. While both BL and CL promise to improve user density, that doesn’t mean you can cram 1,000 high traffic sites on a cheap dedicated server and expect everything to run well.  We find that most hosting providers don’t really increase their density at all, but rather use CL or BL as a safety blanket to help their servers run more smoothly by preventing resource over-use and increasing security.

It should also be noted that when using CL or BL, you may be sacrificing a user’s quality of service in favor of maintaining server stability and QoS for other users.  For those of you on the side of “I don’t want a single customer to cause downtime for everyone else”, do keep in mind that the same single customer may in turn experience downtime if they exceed the resource limits you set for them – it’s not always possible to save the problem user AND the server at the same time.  You therefore may want to ensure that your “higher priority” users are accommodated appropriately and your Terms of Service accounts for the issues the user may experience if they exceed certain resource limitations.

In terms of security, both offer similar features.  Users are locked to their own environments, preventing them from accessing sensitive parts of the filesystem (processes, /etc/passwd, /etc/named.conf, etc) that may reveal information about other users.  Both also support limiting the execution of SUID scripts that are root-owned, and block common symlink attacks.

CloudLinux

CloudLinux is based on the containerization concept used by OpenVZ/Virtuozzo – in fact, much of its core code is adapted from OpenVZ’s code base.  It essentially treats users on a server like they are in their own virtual environment (like a VPS), assigning virtual memory and a percentage of CPU.  CloudLinux refers to a user as an LVE (Lightweight Virtual Environment).

The CPU limit is based on a percentage of a core, and when that limit is reached the user’s processes are slowed down to not exceed that limit.

The memory limit works similarly to that of a containerized VPS – when user’s processes reach the memory limit, the server will not allocate any more.  This can result in offending processes being killed, resulting in 500 or 503 errors in PHP and CGI scripts.

The I/O limits are measures in KB/s and when the I/O limit is reached, the processes are throttled but do not get killed.  CL also allows you to set process run time limits to keep user processes from running longer than a certain amount of time.

It should also be mentioned that CloudLinux has been around for a while, and is very mature and widely used.  They are also officially partnered with cPanel, which helps ensure ongoing compatibility between the two environments.  CloudLinux, Inc also operates KernelCare, which is a service that delivers rebootless kernel patches, and the CL kernel is supported by this technology.

CL also has a couple other added features that their customers may find beneficial, such as file caching and support for multiple PHP versions, the latter of which is a native offering in EasyApache 4.

BetterLinux

BetterLinux was developed and used by BlueHost for years before being released separately as a commercial product, so it is tailored to address the woes of shared hosting environments by people that understand shared hosting.

The process of limiting CPU usage works slightly differently than CL.  BL utilizes “jails”, which is a pool of CPU cores allocated to housing users that exceed their CPU limit, based on % of one core.  You can configure BL to dynamically assign jail cores based on what the server can spare, or assign a max number of cores.  When a user exceeds their CPU limit for a certain amount of time, their processes are “moved” into the jail and can continue to run.  This may mean the user does not experience any interruption, however, if there are only (for example) two cores assigned to the jail and several users are jailed, those users are sharing two cores and may experience sluggishness.

The memory limits are based off of physical memory instead of virtual memory.  When a user’s processes reach the memory limit, the server will not allocate any more and offending processes may be killed.  BL allows you to specify the script used for enforcing memory limits, so this behavior can be easily customized by writing your own script.

The I/O limiting feature seems to work similarly to CL’s current implementation.

Occasionally some very annoying bugs pop up that cause stability problems, seemingly a result of limited testing and product maturity.  The developers usually identify and handle these quickly.  It also seems BL is not very widely used and hasn’t gained much attention in the market since it popped up in 2012.  While BL is still actively being developed, the lack of market participation may be a concern for some users in terms of relationship longevity.

At the time of this writing BL does not support any rebootless kernel solution and the developers are frequently behind on releasing kernel updates (typically 1-7 days).  This can result in the occasional frustration when dealing with a large number of servers facing a sudden reboot party when a kernel exploit is released and patched.  The developers have indicated that they are working on native support for reboot-less kernel updates for CentOS 7 though. that would otherwise be viewable

So whether you choose to go with either CloudLinux or BetterLinux, keep in mind that both are valid solutions for addressing resource and privacy concerns in shared hosting environments, and we haven’t necessarily experienced that one works particularly better than the other in terms of accomplishing what they are meant to do, but the vendor relationship, frequency of updates, and ease of management plays a major role in the decision of most of our customers.