CloudLinux License: How to Buy, Activate and Install It

What is a CloudLinux license and what does it give you?

A CloudLinux license is the right to run CloudLinux OS on one server and receive its updates. You activate it either with an activation key or through a license tied to the server's public IP address. In return, you can isolate every hosting account on a shared server by resources and by file system.

This guide covers where to buy a CloudLinux license, how to check whether your server can be converted, and the high level steps of the installation. We are a digital marketing and web team, not a hosting company. That is why every command below comes from the official CloudLinux installation documentation. We do not quote prices or version promises, because they change often and the vendor's current page is always the right source.

Two kinds of readers will get the most out of this article. The first is the technical user who manages a VPS or dedicated server, usually with cPanel or a similar panel. The second is the site owner who asks "does this plan run CloudLinux?" before buying hosting. If you are in the second group, feel free to skip the command sections and jump to the edition comparison and the final sections.

What problem does CloudLinux OS solve?

On a shared server, dozens or even hundreds of accounts use the same CPU, memory and disk. For example, one broken plugin or one traffic spike in a single account can slow down the whole machine. On top of that, a plain Linux install often lets users see other usernames and some shared files. CloudLinux OS targets exactly these two problems.

Specifically, CloudLinux describes itself as binary compatible with RHEL and CentOS. In other words, applications that run on those systems run on CloudLinux without changes. On top of that base, it adds hosting focused layers such as kernel level resource limits, user isolation and per account language version selection.

• Stability: one account's heavy usage does not take down its neighbors.
• Security: users cannot see each other's files or processes.
• Flexibility: each account can pick its own PHP, Python or Node.js version.
• Visibility: statistics show you which account keeps hitting its limits.

In short, CloudLinux is the infrastructure layer that stops a noisy neighbor from becoming the reason your site is slow. We also cover the other server side causes of slowness in our guide on why a website loads slowly.

How do LVE, CageFS and PHP Selector work together?

At the core of CloudLinux sits LVE, short for Lightweight Virtual Environment. According to the official components documentation, LVE limits resources per user at the kernel level. The main resources it controls are these:

• CPU usage (the docs define 100 percent as one core).
• Virtual and physical memory.
• Disk read and write speed (I/O) and operations per second (IOPS).
• Entry processes, which stand for concurrent connections.
• The total number of processes.

The second layer is CageFS. It places each user in a virtualized file system, so the user only sees safe binaries and cannot detect other usernames. We explain this in detail in our article on CageFS and account isolation, so we will not repeat it here.

The third piece, then, is the set of language selectors. PHP Selector lets an account owner choose a PHP version and extensions without touching the server wide default. You can read how it differs from cPanel's MultiPHP in our cPanel PHP version guide. In addition, MySQL Governor watches database usage and LVE-Stats records limit hits.

Which CloudLinux edition fits your server?

A CloudLinux license is not one size fits all. Instead, there are several editions, split by account count and feature set. The official editions page lists four: Solo, Admin, Legacy (formerly Shared) and Shared Pro. The table below summarizes that page; always check the current version before you buy.

For a VPS that hosts a single agency site or one online store, Solo is often enough. A small agency that keeps a handful of client sites in separate accounts can look at Admin. If you run multi tenant shared hosting, then Shared Pro or Legacy becomes the realistic choice.

How do you buy a CloudLinux license?

You can get a CloudLinux license in two ways: directly from CloudLinux or through an authorized partner, also known as a reseller. When you buy directly, you open an account on CloudLinux Network (CLN), the customer portal. You then manage your licenses, activation keys and trial keys from that portal.

With a reseller, the process usually runs through the company that rents you the server or through a license vendor. In that case the reseller often assigns an IP based license instead of handing you a key. Whichever route you choose, we suggest this order:

1. Write down how many hosting accounts the server will carry and which features you need.
2. Pick the matching edition on the editions comparison page.
3. Confirm compatibility with your operating system and control panel in the official docs.
4. Buy the license through CLN or your reseller, and note whether it is key based or IP based.
5. Take a backup and test a restore before you start the installation.

We do not list prices here, because they vary by edition, billing period and reseller. Instead, check the current amount on the CloudLinux site or with your reseller. Also, if you have not chosen a server yet, our guide on how to choose web hosting lays out the decision order.

What is the difference between IP based and key based licensing?

With key based licensing, CLN gives you an activation key. The example format in the docs is a long string of digits and letters with a hyphen in the middle. When you pass this key to the installer, it detects your CloudLinux edition automatically from the key. If you move the server, you register the key again on the new machine.

With IP based licensing, the reseller binds the license to the server's public IP address. In practice, resellers tend to prefer this model. The official docs give a clear warning here: before conversion, confirm that the server's public IP holds a license for the intended edition. Otherwise the script runs, but you do not end up with the edition you expected.

If you are unsure which IP address your server uses, check where your domain points with our DNS lookup tool, then see which network owns that address with our IP lookup tool. Then make sure the IP you send to the reseller matches the server's real public IP. On servers behind NAT or with several addresses, this mismatch is a common snag.

To sum up, the key model gives you portability, while the IP model makes reseller management easier. The technical result is the same in both cases: the server becomes registered with CLN and licensed.

Should you start with a trial key?

Yes, a trial key is a smart starting point, especially if this is your first time with CloudLinux. According to the official installation docs, a trial key stays valid for 30 days. To get one, you register a customer account on CLN, log in and use the trial activation key button in the portal.

Above all, we recommend treating the trial as a real product test. For example, instead of converting your production server directly, try it on a test VPS with the same operating system and panel. That way you see whether your sites, PHP extensions and cron jobs work with the new kernel and CageFS.

During the trial, look for answers to these questions:

• Does the panel integration (CloudLinux Manager) show the screens you expect?
• Do the LVE limits throttle your sites under normal traffic?
• Do your backup and monitoring tools still work in the new environment?
• Can your team read and interpret the statistics screens?

When the trial ends, you only need to register the paid key on the same server to switch over. We show the registration command in a later section.

Can your server be converted to CloudLinux?

There are two ways to install CloudLinux: a clean install from an ISO on an empty server, or converting an existing server. In practice, servers that already run a panel and live sites take the conversion route. Moreover, the official docs list supported and unsupported systems for conversion very clearly.

• Supported: CentOS 7, AlmaLinux OS 8, 9 and 10, Rocky Linux 8 and 9.
• Not supported: CentOS 8, CentOS Stream and Rocky Linux 10.
• Note: uninstalling after a conversion from Rocky Linux is not an option the docs support.

On the hardware side, the docs say CloudLinux works on hardware that RHEL, CentOS and AlmaLinux support. However, ARM based CPUs such as Graviton are out of scope. Also be careful with ZFS; according to the docs, LVE disk I/O limits do not work on ZFS.

There is one more detail about ISOs. The docs offer ISOs for CloudLinux OS 7, 8 and 9, but state that there is no ISO for CloudLinux OS 10; instead, you convert an AlmaLinux 10 server. The CloudLinux documentation also has a separate section for Ubuntu based servers. That said, this guide focuses on conversion within the RHEL family.

What should you prepare before installation?

Conversion is a serious change, because it replaces the operating system's release packages and kernel. So do not skip the preparation. We condensed the checklist from the official docs into the steps below:

1. Verify the operating system, architecture, virtualization type and panel compatibility.
2. Take a full backup and actually test a restore; having a backup alone is not enough.
3. Plan a maintenance window, because the process ends with a reboot.
4. Finish any pending package operations and fix repository or package manager errors.
5. Confirm that the activation key or IP license matches the intended edition.
6. Make sure you have console access, so you can still act if SSH drops.

For backups, think about files, databases and configuration as separate layers. We walk through that split step by step in our website backup strategy guide.

Also, if the server runs a firewall, make sure it does not block access to the CloudLinux repositories during conversion. If you use CSF, our CSF firewall guide is a quick refresher on how its rules work.

How do you download and review the cldeploy script safely?

The conversion itself runs through an official script called cldeploy. Online you may see one liners that download this script and pipe it straight into a shell. We do not recommend that, because running a root level script without reading it is an unnecessary risk. Instead, use two separate steps: download first, then review.

Step one is to download the script as a file from the CloudLinux repository. The official docs give this address:

cd /root
curl -O https://repo.cloudlinux.com/cloudlinux/sources/cln/cldeploy
ls -l cldeploy

In step two, open the file in a text viewer and skim it. Check that the source really is repo.cloudlinux.com and that the file is a shell script, not an HTML error page:

head -n 20 cldeploy
less cldeploy

Next, run the precheck option from the official docs. It validates the prerequisites before any conversion starts:

bash cldeploy --precheck

If the precheck shows a warning, fix that first. Ignoring a warning and moving on raises the odds of ending up with a half converted system.

How does a conversion with a CloudLinux license work, step by step?

Once the precheck comes back clean, you move on to the actual conversion. The command depends on the type of CloudLinux license you hold. If you have an activation key, you pass the key to the script, and the script reads the edition from that key:

bash cldeploy -k ACTIVATION_KEY

If your reseller gave you an IP based license, you use the IP option instead of a key. For the Admin edition with an IP license, the docs show one extra flag:

sh cldeploy -i
sh cldeploy -i --to-admin-edition

The script does a lot of work in the background. According to the docs, it first backs up the original repository settings to /etc/cl-convert-saved and installs the CloudLinux repositories and RPM key. Then it swaps the release packages for CloudLinux versions and removes conflicting packages. Finally, it installs the CloudLinux kernel, the LVE tools and the panel integration.

Do not close the terminal while it runs. Since the process can take a while, it makes sense to start your SSH session inside screen or tmux; that way a dropped connection does not interrupt it. When the script finishes, read the final instructions it prints and save them. Those instructions are specific to your server.

What should you check after the reboot?

The last step of the conversion is a reboot. Before rebooting, the docs ask you to review any boot warnings, which means kernel and initramfs files and boot entries. If nothing looks wrong, reboot the server and then check the running kernel:

reboot
uname -r

Watch out for one detail here. On older CloudLinux releases you would look for "lve" in the kernel name. However, the docs say CloudLinux OS 9 and later use the AlmaLinux kernel, so a kernel name without lve is not a sign of failure.

After the kernel, check the application layer:

• Confirm that the CloudLinux Manager screen opens in your panel.
• Open the home page and admin area of each hosted site.
• Verify that database connections work and that error logs stay clean.
• Watch the first run of your cron jobs.

Optional features such as PHP Selector, X-Ray or AccelerateWP come later, each according to its own requirements. The docs treat them as follow up steps rather than part of the conversion. You should not expect any change on the SSL side; still, a quick check with our SSL checker to confirm the certificate serves correctly is a good habit.

What should you watch for on cPanel, Plesk and DirectAdmin?

The official docs list cPanel, Plesk, DirectAdmin, CyberPanel, InterWorx and Webuzo as supported panels. That said, the depth of integration varies from panel to panel. So we suggest reading your panel's section before you start.

• cPanel: the docs describe full integration, and CloudLinux Manager lives inside WHM.
• Plesk: the docs include it, and cldeploy handles the mod_fcgid replacement itself.
• DirectAdmin: the docs include it too, but you need to run the CustomBuild tool after conversion.
• Other panels: integration depends on the panel developer, and the docs do not guarantee stability.

You can also run CloudLinux on servers without a panel, but you lose part of the interface convenience. If you have not settled on a panel yet, decide on the panel first and then choose your CloudLinux license edition. Some edition features, such as reseller limits, only make sense alongside a panel.

One more practical note: web server modules can change during conversion. If you run LiteSpeed or Nginx instead of Apache, read the CloudLinux notes for your own stack as well.

Which commands activate a license or switch editions?

Sometimes you need to register the license again after installation. For example, this comes up when you move from a trial key to a paid key or when you change editions. The official docs give these commands for key based registration:

yum install rhn-setup
/usr/sbin/rhnreg_ks --activationkey=YOUR_KEY

For an IP based license, registration looks like this:

yum install rhn-setup
/usr/sbin/clnreg_ks --force

To switch editions, for example from Solo to Admin, first obtain a key for the new edition. Then force a fresh registration:

rhnreg_ks --activationkey=NEW_KEY --force

With an IP license, once your reseller assigns the new edition to your IP, you only need to run clnreg_ks again. Replace the uppercase placeholders with your own key. Also, never share the key openly in screenshots, support tickets or chat logs. The key is effectively access to your license.

Can you roll back from CloudLinux?

Partly, yes. The cldeploy script has an uninstall option, and the docs show it in two forms:

cldeploy -c
cldeploy --uninstall

This option removes the LVE packages and restores the original repository settings. However, it leaves the CloudLinux kernel on the system. The docs describe removing that kernel by hand and installing a standard kernel as a separate step. The key sentence in the docs is this one: the process is not a complete restoration of the pre conversion state.

So the practical takeaway is simple: do not treat rollback as a safety net. Your real safety net is the backup you took and test restored before converting. Also, the docs do not support uninstalling after a conversion from Rocky Linux. So on Rocky Linux servers, testing in a staging environment before you commit matters even more.

In short, treat CloudLinux as an operating system change, not as an add on. That mindset helps you set up both the preparation discipline and the maintenance plan correctly.

Are Imunify360 and KernelCare part of CloudLinux?

No. They are separate products from the same company, and each one needs its own license. The CloudLinux website describes the product family like this: Imunify360 offers automated, multi layered security for Linux web servers. ImunifyAV provides free malware scanning, and ImunifyAV+ adds one click cleanup. KernelCare delivers rebootless live patching for the Linux kernel.

This distinction matters when you buy hosting. A plan that says "CloudLinux included" does not automatically include Imunify360 or KernelCare. When you review an offer, ask about each product separately.

• CloudLinux OS: resource limits, isolation and language selectors.
• Imunify360: server level firewall, malware scanning and proactive defense.
• KernelCare: applying kernel security patches without a reboot.
• AccelerateWP: a speed optimization toolkit for WordPress sites.

Application level vulnerabilities, on the other hand, remain your responsibility regardless of these products. We summarize the common types in our OWASP Top 10 article.

When should you leave this to your hosting provider?

To be honest, most site owners should never install CloudLinux themselves. If you are on a shared hosting plan, CloudLinux either comes preinstalled on your provider's server or it does not; it is not a setting you can change. In that case, your only job is to ask the right questions when you pick a plan.

On managed VPS plans, handing the OS conversion to the provider's support team is usually the safer choice. The provider knows its virtualization layer, console access and backup infrastructure better than you do. We strongly suggest handing the job over in these situations:

• You have no console or KVM access to the server.
• Your live online store cannot afford a maintenance window.
• The server's licenses (panel, CloudLinux) run through the provider.
• You have no experience fixing Linux package or boot problems.

If you run your own unmanaged VPS and have console access, this guide gives you a path. Even so, reading our VPS, VDS and cloud server comparison will clarify who owns which responsibility.

What are the most common installation mistakes?

Based on the warnings in the official docs and general sysadmin practice, we listed the mistakes that come up most often. Most of them are process mistakes rather than technical ones.

1. Trying an unsupported system: attempting a conversion on CentOS Stream or Rocky Linux 10.
2. Licensing the wrong IP: sending the reseller an address other than the server's real public IP.
3. Skipping the precheck: moving ahead without reading the precheck warnings.
4. Running the script unread: using the one line download and run pattern.
5. Never testing the backup: assuming the backup exists without ever trying a restore.
6. Rebooting without a console: losing access to the server if a boot problem appears.

There is also an expectation mistake. CloudLinux does not fix a poorly coded site's slowness; it only stops that site from hurting its neighbors. In fact, a site that hits its LVE limit may feel slower than it did before CloudLinux. In that case, the problem lies in the site, not the license, and the fix belongs in the code or the cache layer.

What should you monitor after installing a CloudLinux license?

Conversion is a one time job, but getting real value from CloudLinux takes regular follow up. In the first weeks, LVE limits deserve the most attention. Default limits may not fit every site's traffic. So use the statistics in CloudLinux Manager to see which account keeps hitting its ceiling.

Do not rush when you review limit hits. If an account keeps hitting its CPU limit, look at the site first; a plugin, cache or query problem may be the cause. Raising the limit right away may simply move the problem to the neighboring accounts.

We suggest adding these items to your maintenance routine:

• Apply operating system updates with the package manager on a regular schedule.
• Track the license status and renewal date in the CLN portal.
• After panel updates, confirm that the CloudLinux Manager screen still opens.
• Review recurring limit hits in the LVE statistics once a month.

If the license lapses, updates may stop, and that is a security risk. Therefore, put the renewal date in your calendar and keep the payment method current.

How can our team help with this process?

We are not a hosting company, and we do not sell CloudLinux licenses. However, in web design and ecommerce projects we often weigh how the server choice affects the site. For example, when we plan which hosting type, PHP version and cache layer a store will run on, infrastructure questions come up too.

Within that scope, we compare hosting offers on technical grounds, prepare the questions you should put to the provider and plan the site's move to the new environment. The conversion commands themselves stay with the server owner or the provider. We prefer to set that boundary clearly from the start.

If you are building a new site or store, take a look at our web design service, which handles infrastructure alongside design. If you want your current site's speed and technical health reviewed from a search perspective, our SEO consulting service also includes server side issues in its report.

Conclusion: how do you decide on a CloudLinux license?

You can boil the decision down to three questions. First, how many hosting accounts will the server carry? The answer points you to Solo, Admin or Shared Pro. Second, does your server run an operating system and panel that support conversion? Third, who handles installation and maintenance?

If all three answers are clear, the path is straightforward. You buy a CloudLinux license through CLN or a reseller, test with a trial key and verify your backup. Then you download and review cldeploy, run the precheck and convert during a maintenance window. After the reboot, you check the kernel, the panel and your sites.

If any answer is unclear, especially the third one, leaving the job to your hosting provider is usually the right call. Resource limits and isolation are valuable features; still, a half finished conversion can undo everything they offer in a single outage.