- CloudLinux OS est un système Linux conçu pour l’hébergement mutualisé : CageFS isole chaque compte et LVE plafonne ses ressources (CPU, mémoire, disque, processus).
- Il évite qu’un site gourmand ou compromis ne dégrade les autres comptes, mais il n’ajoute pas de puissance et ne remplace ni les mises à jour de votre site ni les sauvegardes.
- KernelCare, un service distinct vendu par abonnement, applique des correctifs du noyau sans redémarrage ; Ubuntu propose un service équivalent, Livepatch.
- Pour juger un hébergement, regardez les limites de ressources, le support, les sauvegardes et le temps de réponse du serveur (moins de 0,8 seconde au premier octet, selon web.dev).
CloudLinux OS est un système d’exploitation serveur Linux conçu pour l’hébergement web mutualisé : il isole chaque compte d’hébergement et plafonne ses ressources, afin qu’un site gourmand ou compromis ne dégrade pas les autres sites de la machine. Il rend un serveur partagé plus régulier et plus cloisonné, sans créer de puissance supplémentaire. Voici comment il fonctionne, ce qu’il change pour un site, et comment choisir un hébergement vraiment performant.
Qu’est-ce que CloudLinux OS et à qui s’adresse-t-il ?
CloudLinux OS est un système commercial édité par CloudLinux. Il s’adresse d’abord aux hébergeurs, aux agences et aux administrateurs de serveurs qui hébergent plusieurs comptes sur une même machine. L’éditeur le présente comme une suite d’outils pour l’hébergement web, qui isole les comptes et encadre leurs ressources. En tant que client final, vous ne l’installez pas : vous en bénéficiez (ou non) selon l’infrastructure choisie par votre hébergeur.
Quelles sont les éditions et les versions ?
Selon la documentation de l’éditeur, la licence dépend du nombre de comptes d’hébergement : Solo (un seul compte, sans limites LVE hormis celles sur les inodes), Admin (cinq comptes, limites LVE disponibles mais désactivées par défaut), Shared (édition dite « Legacy », comptes illimités avec limites LVE) et Shared Pro (comptes illimités). La page de tarifs actuelle présente les licences comme « 1 compte », « 5 comptes » et « comptes illimités », en précisant qu’il s’agit des anciennes éditions Solo, Admin et Shared Pro, et propose un essai gratuit de 30 jours. CageFS est incluse dans toutes les éditions.
Le cycle de vie de CloudLinux OS suit celui de Red Hat Enterprise Linux. Au moment de la rédaction (octobre 2026), la documentation indique :
| Version | Fin du support standard | Support étendu (ELS) |
|---|---|---|
| CloudLinux OS 6 | 30 novembre 2020 | jusqu’au 30 juin 2024 |
| CloudLinux OS 7 | 30 juin 2024 | jusqu’au 30 juin 2027 |
| CloudLinux OS 8 | 31 mai 2029 | non indiqué |
| CloudLinux OS 9 | 31 mai 2032 | non indiqué |
| CloudLinux OS 10 | 31 mai 2035 | non indiqué |
Ce système n’a donc rien d’une nouveauté : il existe en plusieurs générations. Si un hébergeur vous annonce « CloudLinux », demandez quelle version il utilise, car une version en fin de support ne reçoit plus les mêmes correctifs.
Comment fonctionnent LVE et CageFS ?
LVE : à quoi servent les limites de ressources ?
LVE signifie Lightweight Virtual Environment. C’est une technologie de niveau noyau développée par CloudLinux, qui s’appuie sur les cgroups de Linux et sert à empêcher qu’un seul site ne fasse tomber le serveur. Chaque compte reçoit un cadre de consommation, que l’hébergeur règle selon la formule vendue. Les principales limites sont les suivantes :
| Limite | Ce qu’elle encadre | Si elle est atteinte |
|---|---|---|
| SPEED | Le temps de calcul (CPU), en pourcentage d’un cœur | Les processus sont ralentis, pas arrêtés |
| PMEM | La mémoire physique | Le noyau libère d’abord le cache, puis peut arrêter des processus (erreurs 500 ou 503) |
| IO et IOPS | Le débit disque et le nombre d’opérations de lecture et d’écriture par seconde | Les opérations sont ralenties ou suspendues |
| NPROC | Le nombre de processus et de threads | Aucun nouveau processus tant qu’un autre n’est pas terminé |
| EP | Les entrées simultanées (connexions Apache dynamiques, SSH, tâches cron) | Erreur 508 « Resource Limit Reached » |
Que faire si votre site affiche une erreur 508 ou 503 ?
Une erreur 508 indique que votre compte a atteint sa limite d’entrées simultanées : le site ralentit, mais les autres comptes ne sont pas touchés. Des erreurs 500 ou 503 répétées peuvent traduire un manque de mémoire. Dans les deux cas, consultez d’abord les statistiques de consommation proposées par votre hébergeur, puis cherchez la cause côté site : plugin trop gourmand, absence de cache, tâche planifiée lourde, trafic de robots. Si le site est bien optimisé et que les limites sont régulièrement atteintes, demandez à votre hébergeur quelle formule convient à votre trafic.
CageFS : comment le cloisonnement des comptes fonctionne-t-il ?
CageFS est un système de fichiers virtualisé qui enferme chaque utilisateur dans sa propre « cage ». Un compte ne voit ni les autres comptes ni leurs noms d’utilisateur, n’accède pas aux fichiers de configuration du serveur (ceux d’Apache, par exemple) et ne voit pas les processus des autres utilisateurs. L’isolation s’applique aux scripts lancés par Apache, LiteSpeed, cron ou SSH, sans modifier ces scripts. Elle s’intègre nativement à cPanel, Plesk et DirectAdmin.
L’intérêt est concret : si un site est piraté, l’attaquant a plus de mal à explorer les fichiers des autres comptes de la machine. Cela réduit une partie des risques de propagation, sans les supprimer.
Qu’est-ce que l’effet « noisy neighbor » ?
On parle de « voisin bruyant » (noisy neighbor) lorsqu’un compte consomme tant de ressources qu’il dégrade les performances des autres sur le même serveur. C’est un risque classique de l’hébergement mutualisé. LVE le limite en plafonnant chaque compte, et CageFS réduit l’exposition entre comptes. D’autres composants complètent le dispositif, selon l’édition : MySQL Governor surveille et encadre l’usage de MySQL par compte d’hébergement, et les Selectors permettent à chaque compte de choisir sa version de PHP (ainsi que de Python, Ruby ou Node.js).
KernelCare : peut-on vraiment corriger le noyau sans redémarrer ?
KernelCare est un service de correction à chaud du noyau Linux (live patching) : il installe des correctifs de sécurité sans redémarrer la machine. Il est proposé par TuxCare, par abonnement, avec un essai gratuit de 30 jours. Ce n’est pas une fonction incluse d’office dans CloudLinux OS : c’est un produit distinct, compatible avec CloudLinux, mais aussi avec RHEL, AlmaLinux, Rocky, Oracle Linux, CentOS, Ubuntu et Debian.
Un client installé sur la machine vérifie régulièrement la présence de correctifs (toutes les quatre heures par défaut) puis les applique. Le délai cible de livraison est de dix jours après la divulgation publique d’une faille, mais TuxCare précise qu’il s’agit d’un objectif et que certains correctifs complexes demandent plus de temps. La couverture n’est donc pas garantie pour toute faille.
Le correctif à chaud évite la coupure liée au redémarrage, ce qui compte pour un serveur qui héberge de nombreux sites. Il ne dispense pas d’une maintenance régulière : à propos de son propre service, Canonical recommande de continuer à planifier des redémarrages pour vider l’état accumulé en mémoire,. Appliquez la même prudence à tout service de ce type.
CloudLinux, Ubuntu Server, CentOS : que comparer vraiment ?
La comparaison est souvent présentée de façon trop tranchée. Ubuntu Server est un système généraliste, excellent pour de nombreux usages, qui n’a pas été conçu spécifiquement pour l’hébergement mutualisé. Quant à CentOS Linux, il n’est plus maintenu : CentOS Linux 8 a reçu ses dernières mises à jour le 31 décembre 2021 et CentOS Linux 7 le 30 juin 2024. Aujourd’hui, CentOS Stream est un projet en amont de RHEL, pas un remplaçant direct de l’ancien CentOS Linux.
| Critère | CloudLinux OS | Ubuntu Server | CentOS Linux |
|---|---|---|---|
| Isolation des comptes | CageFS, incluse dans toutes les éditions | Pas d’équivalent livré tel quel ; à bâtir avec d’autres outils (droits, conteneurs…) | Pas d’équivalent livré tel quel |
| Limites de ressources par compte | LVE (CPU, mémoire, disque, processus), selon l’édition | Mécanismes du noyau (cgroups) à configurer soi-même ou avec un outil tiers | Mécanismes du noyau à configurer soi-même |
| Correctifs du noyau sans redémarrage | KernelCare (abonnement distinct) | Livepatch (Ubuntu Pro, gratuit pour un usage personnel jusqu’à 5 machines) ou KernelCare | Projet arrêté : plus de mises à jour depuis le 30 juin 2024 (version 7) |
| Maintenance et support | Versions 8, 9 et 10 sous support standard | Couverture de 10 ans avec Ubuntu Pro, portée à 15 avec l’extension Legacy | Fin de vie |
Le bon choix dépend de l’usage. Pour héberger des dizaines de comptes clients sur un panneau comme cPanel, CloudLinux OS répond à un besoin précis. Pour une application dédiée ou un serveur conteneurisé, un système généraliste bien configuré peut suffire.
Dans quels cas CloudLinux est-il utile ?
- Hébergement mutualisé : pour limiter l’impact d’un client sur les autres et réduire les réclamations liées aux lenteurs.
- Agence web : pour héberger plusieurs sites clients avec un meilleur cloisonnement.
- Sites WordPress et boutiques en ligne : un plugin défaillant ou un pic de trafic reste contenu dans les limites de son compte.
- Serveurs à forte densité de comptes : pour répartir les ressources de façon plus prévisible.
À l’inverse, si vous hébergez un seul site sur un serveur dédié bien dimensionné, l’intérêt est plus limité : vous n’avez pas de voisins à contenir.
CloudLinux rend-il un site plus rapide ?
Pas à lui seul. Il répartit les ressources plus équitablement et rend le serveur plus régulier, mais il ne rend pas un site lourd plus léger. La vitesse dépend aussi du code, de la base de données, du cache, de la version de PHP, du poids des pages et de la distance avec le visiteur.
Un indicateur utile pour juger le serveur est le TTFB (Time to First Byte), le délai avant l’arrivée du premier octet de la réponse. D’après web.dev, une valeur de 0,8 seconde ou moins est considérée comme bonne, et au-delà de 1,8 seconde comme mauvaise. Ce délai inclut aussi les redirections, la résolution DNS et la négociation TLS : il ne mesure donc pas uniquement l’hébergeur. Il n’est pas non plus une des Core Web Vitals, et web.dev précise que l’atteindre n’est pas indispensable si les métriques principales sont bonnes.
L’hébergement mutualisé est-il plus sobre ?
Partager une machine entre de nombreux sites est souvent présenté comme un moyen d’utiliser le matériel plus pleinement. Cela ne dit pourtant rien de l’empreinte réelle d’un hébergeur, qui dépend aussi du taux d’occupation des serveurs et de l’énergie du centre de données. Pour situer ces enjeux, consultez notre guide sur le green IT appliqué à l’hébergement web, qui en détaille les principes et les limites.
Comment choisir un hébergement web performant ?
Au-delà du système d’exploitation, posez ces questions à votre hébergeur avant de souscrire :
- Quelles sont les limites de CPU, de mémoire, de disque et de processus de la formule, et que se passe-t-il en cas de dépassement ?
- Quels outils de suivi de la consommation sont mis à disposition ?
- Quelle est la fréquence des sauvegardes, leur durée de conservation, et la restauration est-elle simple ?
- Quelles versions de PHP sont proposées, et jusqu’à quand sont-elles maintenues ?
- Où se trouvent les serveurs et les données ?
- Quel support est disponible, par quel canal, et dans quels délais ?
Si vous recherchez une offre en Suisse, vous pouvez consulter le site d’un hébergeur web Suisse et lui poser ces mêmes questions, notamment sur les technologies d’isolation et de limitation des ressources qu’il met en œuvre.
Quelles erreurs éviter avec CloudLinux ?
- Mal dimensionner les limites LVE : trop basses, elles brident inutilement les sites ; trop hautes, elles font perdre l’intérêt de l’isolation.
- Confondre sécurité du système et sécurité de l’application : CloudLinux protège l’infrastructure, mais ne remplace pas la mise à jour de WordPress, des extensions ou de tout autre CMS.
- Négliger la surveillance : suivez les consommations réelles avant d’ajuster les limites.
- Attribuer au serveur tout problème de performance : le code, la base de données ou une extension en sont souvent la cause.
La meilleure approche consiste à combiner un socle solide avec une bonne hygiène : mises à jour régulières, supervision, sauvegardes testées et optimisation du site. Ce contenu informe et ne remplace pas l’avis d’un administrateur système ou de votre hébergeur pour votre situation.
Questions fréquentes
CloudLinux, c’est quoi exactement ?
CloudLinux OS est un système d’exploitation serveur Linux conçu pour l’hébergement web mutualisé. Il isole chaque compte grâce à CageFS et limite ses ressources grâce à LVE, afin qu’un site gourmand ne pénalise pas les autres. Il s’adresse surtout aux hébergeurs et administrateurs, le client final en bénéficiant indirectement.
Quelle différence entre CageFS et LVE ?
Les deux ont des rôles distincts. CageFS enferme chaque utilisateur dans un système de fichiers virtualisé : il ne voit ni les autres comptes ni les fichiers de configuration du serveur. LVE plafonne la consommation de ressources du compte, comme le processeur, la mémoire, le disque ou le nombre de processus. L’un cloisonne, l’autre limite.
Que se passe-t-il quand un site atteint sa limite LVE ?
Cela dépend de la limite. Pour le processeur ou le disque, les processus sont ralentis sans être arrêtés. Pour la mémoire, le noyau peut arrêter des processus, ce qui provoque souvent des erreurs 500 ou 503. Pour les entrées simultanées, le visiteur voit une erreur 508. Les autres comptes du serveur ne sont pas touchés.
CloudLinux est-il payant et peut-on l’installer partout ?
C’est un produit commercial, dont la licence dépend du nombre de comptes (1, 5 ou illimité, anciennement Solo, Admin et Shared Pro), avec un essai gratuit de 30 jours sur le site de l’éditeur. Il suit le cycle de vie de Red Hat Enterprise Linux et s’intègre à cPanel, Plesk et DirectAdmin. Vérifiez la compatibilité de votre serveur et les tarifs actuels auprès de l’éditeur avant d’installer.
KernelCare évite-t-il tous les redémarrages d’un serveur ?
Non. KernelCare, proposé par TuxCare par abonnement, applique des correctifs de sécurité du noyau sans redémarrage, avec un délai cible de dix jours après la divulgation d’une faille, sans garantie absolue. Canonical recommande de continuer à planifier des redémarrages avec son propre service. Une maintenance régulière reste donc nécessaire.
CloudLinux protège-t-il un site WordPress des piratages ?
Il réduit certains risques, car un compte piraté a plus de mal à atteindre les autres comptes du serveur, et un plugin gourmand reste contenu dans ses limites. Mais il ne remplace ni les mises à jour de WordPress et des extensions, ni les mots de passe solides, ni les sauvegardes. Il protège l’infrastructure, pas le code de votre site.
Pour sécuriser aussi vos connexions d’administration, par exemple sur un réseau public, découvrez ce qu’est un VPN.
Sources : CloudLinux, documentation de CloudLinux OS (éditions, composants CageFS et LVE, limites, cycle de vie des versions) et page de tarifs (licences, essai), consultées en octobre 2026 ; TuxCare, documentation des services de correction à chaud du noyau (KernelCare), consultée en octobre 2026 ; Canonical, page Ubuntu Livepatch, consultée en octobre 2026 ; projet CentOS, « Comparing CentOS Stream and CentOS Linux » (dates de fin de vie de CentOS Linux 7 et 8) ; Google, web.dev, « Time to First Byte (TTFB) ».