En el catálogo de Conexcol, la línea Linux con cPanel se llama Sitios Elásticos. No es un cambio de nombre por marketing: es que el término viejo describe un modelo técnico que aquí no aplica.

Este artículo explica qué es lo que sí hay debajo —CloudLinux y los límites LVE—, qué problema resuelve, qué no resuelve, y cómo comprobar en tu propio panel si te está funcionando.

De paso queda clara una precisión del catálogo: en Conexcol, «hosting compartido» se refiere únicamente a la línea Windows con Plesk. La línea Linux es Sitios Elásticos, y es otra arquitectura.

El problema que todos conocen: el vecino ruidoso

El modelo clásico funciona así: un servidor, muchas cuentas, un solo montón de recursos. Todos toman del mismo procesador, de la misma memoria y del mismo disco, sin fronteras entre ellos.

Mientras nadie se pase, funciona bien. El problema aparece cuando alguien se pasa:

  • Una tienda vecina recibe un pico de tráfico y se come el procesador.
  • Un plugin mal escrito entra en un bucle y abre procesos sin parar.
  • Un bot rastrea un sitio vecino a toda velocidad y satura la entrada/salida del disco.
  • Un backup mal programado corre en plena mañana en vez de la madrugada.

Y tu sitio, que no hizo nada, se pone lento. O peor: se cae junto con todo lo demás.

Eso es el vecino ruidoso. Y no es una anécdota: es la consecuencia lógica de un diseño sin fronteras. Si los recursos son un solo pozo común, quien tome de más se lo quita a alguien.

Qué es una LVE

CloudLinux es un sistema operativo derivado de Enterprise Linux con una diferencia central: su kernel sabe separar cuentas.

Cada cuenta de hosting vive dentro de una LVE (Lightweight Virtual Environment, entorno virtual liviano). Es una jaula de recursos aplicada por el propio núcleo del sistema, no por un plugin ni por un script de vigilancia que revisa cada minuto y avisa tarde. El límite se aplica en el momento, en cada petición.

Dentro de una LVE se limitan, por cuenta:

  • CPU: cuánto procesador puede consumir la cuenta.
  • Memoria física: cuánta RAM real puede tomar.
  • Entrada/salida: la velocidad de lectura y escritura en disco, y la cantidad de operaciones por segundo.
  • Procesos: cuántos procesos simultáneos puede abrir la cuenta.
  • Entradas concurrentes: cuántas peticiones puede estar procesando el servidor web para esa cuenta al mismo tiempo.
  • Inodos: cuántos archivos puede tener.

La consecuencia práctica es la que importa:

El vecino que se pasa recibe su propio freno. Tu sitio no se entera.

En el modelo sin fronteras, el que se pasa reparte el daño entre todos. Con LVE, el que se pasa choca contra su propio techo: sus peticiones se encolan o se le devuelve un error de recursos, y el resto del servidor sigue igual. El costo del exceso se lo queda quien lo causó.

Eso es lo que hace que esta línea no se pueda describir con el término viejo. El término viejo describe el pozo común. Aquí no hay pozo común.

Y el «elástico», ¿de dónde sale?

De que el límite es un número, y un número se puede subir.

En el modelo tradicional, cuando tu sitio crecía tenías que mudarte: contratar un servidor distinto, copiar archivos, exportar e importar la base de datos, mover el correo, cambiar el DNS, esperar la propagación, cruzar los dedos con el certificado SSL. Un fin de semana perdido y un riesgo real de que algo quede roto.

Con LVE, crecer es ajustar el techo de tu jaula. Sin cambiar de servidor, sin cambiar de IP, sin tocar el DNS y sin que tu sitio deje de responder.

Esa es la elasticidad: creces sin mudarte.

Y el ajuste funciona en los dos sentidos. Si montaste una campaña, pasó el pico y el tráfico volvió a lo normal, el techo se puede volver a bajar. Escríbenos y lo revisamos con el dato del panel en la mano.

Qué ganas, en concreto

Rendimiento predecible. Es la palabra clave, más que «rápido». Tus recursos son tuyos: el mismo formulario responde igual el martes a las 3 p.m. que el viernes negro. Un sitio predecible se puede optimizar; uno que depende del humor de los vecinos, no.

Aislamiento de verdad. CloudLinux también separa el sistema de archivos por cuenta. Un usuario no ve los archivos de configuración de otro, ni sus bases de datos, ni sus procesos. Es una frontera de seguridad, no solo de velocidad.

Versiones de PHP por cuenta. Cada sitio corre la versión de PHP que necesita, con sus propias extensiones. Un sistema legado que quedó atrapado en una versión vieja no obliga a nadie más a quedarse atrás, y un proyecto nuevo puede usar lo último sin pedir permiso.

Diagnóstico honesto. Cuando un sitio va lento, hay un número que lo explica en vez de una teoría. «Se lo comió el vecino» deja de ser una respuesta posible, y eso obliga a todos —a ti y a nosotros— a buscar la causa real.

Qué NO arregla (y hay que decirlo)

Sería deshonesto vender esto como magia. Los límites por cuenta no arreglan:

  • Un plugin mal escrito. Si una consulta tarda segundos, va a tardar lo mismo con toda la CPU del mundo. Los límites te dicen dónde está el problema; no lo reescriben.
  • Una base de datos sin índices. El clásico. Se nota cuando la tabla crece, y no es un problema de recursos.
  • Un tema que dispara decenas de peticiones por página. Eso es diseño, no infraestructura.
  • La latencia de la red. El aislamiento de recursos ocurre dentro del servidor. El viaje entre el navegador de tu cliente y el servidor es otro asunto, y lo tratamos en el artículo sobre qué es la latencia. Y ojo: un CDN encima tampoco lo arregla del todo, porque el carrito, el login y el checkout no se cachean y vuelven al origen en cada petición. Un borde cercano acelera las imágenes; no acerca el servidor.
  • Un sitio que ya se quedó chico. Si consumes de forma sostenida más de lo que un plan de Sitios Elásticos debe dar, lo correcto no es subir el techo indefinidamente: es un servidor cloud propio. Preferimos decirlo a venderte un límite que se te va a quedar corto en tres meses.

Lo que sí hace el límite es convertir un misterio en un dato. Antes de CloudLinux, «mi sitio está lento» era una conversación de intuiciones. Ahora es una gráfica.

Cómo mirarlo tú mismo

En tu cPanel, entra a Resource Usage (Uso de recursos). Ahí ves, en el tiempo:

  • El consumo de CPU, memoria y entrada/salida de tu cuenta.
  • Los procesos y entradas concurrentes.
  • Y lo más útil: los faults, es decir, las veces que tu cuenta tocó un techo.

Cómo leerlo:

  • Cero faults y consumo bajo: tu plan te queda holgado. Nada que hacer.
  • Faults ocasionales en horas pico: vale la pena mirar caché de página antes que subir el plan. Muchas veces se resuelve del lado del sitio.
  • Faults sostenidos todos los días: el plan se te quedó corto, o hay algo consumiendo de más. Escríbenos y lo miramos con el dato en la mano, no con adivinanzas.
  • Un pico de entrada/salida a una hora fija: casi siempre es un backup, un cron o un bot. Se corrige moviendo el horario.

Esa transparencia es parte del producto. Preferimos que veas el número a que nos creas.

El contexto completo

Los Sitios Elásticos corren sobre infraestructura en Colombia, en una instalación con certificación Tier III del Uptime Institute —certificación que es de la instalación, no una insignia nuestra— y conectada al NAP Colombia. Para dimensionarlo: el Uptime Institute reconoce 23 instalaciones premiadas en Colombia, de las cuales 13 tienen Tier III de construcción.

Desde Bogotá, esa infraestructura midió 16,9 ms el 30 de agosto de 2026, sobre red INTERNEXA (AS18678), por ruta pública y tomando el RTT mínimo. La medición se hizo desde una conexión de consumidor en Colombia, que es la que sufre el visitante de tu sitio.

El SLA es un compromiso contractual del 100% con compensación; la medición real de la instalación está en 99,98%. Decimos las dos cosas porque son dos cosas distintas: una es lo que respondemos, la otra es lo que pasó.

Y si algo se rompe, contesta gente en Colombia. En las opiniones públicas tenemos 4,91 sobre 379, y 74 de 120 reseñas hablan del soporte sin que se les pregunte por él.

En resumen

Sitios Elásticos = CloudLinux con límites LVE por cuenta: CPU, memoria, entrada/salida y procesos, aplicados por el kernel, ajustables sin mudanza.

El vecino ruidoso deja de ser tu problema y pasa a ser el suyo.

Y el término correcto importa, porque describe lo que de verdad está corriendo debajo.