Hosting compartido, VPS o servidor en la nube: qué necesita de verdad su sitio

El hosting compartido, el VPS y el servidor en la nube parecen tres niveles de potencia en la tarifa, pero se diferencian en tres sitios: qué lo separa a usted de los vecinos en la misma máquina, dónde choca la cuenta y quién actualiza el software.

Un miércoles por la mañana, hacia las diez, el sitio web se vuelve lento — no caído, solo lento: la página tarda cinco segundos en abrirse, el panel de administración se niega a guardar una entrada y, al cabo de media hora, todo vuelve a estar en orden, como si no hubiera pasado nada. El soporte del proveedor responde después de mediodía que la cuenta ha superado los límites de su plan, y propone pasar al siguiente nivel, que cuesta tres veces más y en la tarifa se llama «servidor en la nube».

En ese momento la mayoría de los compradores no sabe qué está comprando exactamente, y no es un reproche: el hosting compartido, el VPS y el servidor en la nube aparecen en la tarifa uno debajo de otro como tres niveles de potencia de un mismo servicio, aunque son tres soluciones técnicas distintas, que se diferencian en tres puntos concretos. Cada uno de esos tres puntos puede comprobarlo usted con las cifras de su propio sitio en la mano, y ninguno se lee en el nombre del plan.

Tres puntos en los que los planes se diferencian de verdad

El primero es el aislamiento, es decir, qué separa exactamente su sitio web de los de los demás clientes en la misma máquina física. En el hosting compartido es una cuenta en el sistema operativo junto con un contenedor de recursos colocado a nivel de kernel; en el caso del VPS es una máquina virtual propia con su sistema operativo; en un servidor en la nube es esa misma máquina virtual, solo que pedida y cobrada de otra manera. La diferencia práctica entre las tres variantes está en hasta qué punto la carga del vecino puede afectar a su sitio y en cuánto de la máquina se le permite cambiar cuando resulta que la configuración por defecto no le sirve.

El segundo punto es el límite, es decir, dónde choca la cuenta y cómo se manifiesta, y es precisamente aquí donde surgen más malentendidos, porque la gente espera que la sobrecarga signifique una página lenta, cuando en parte de los casos significa una página que no se abre en absoluto y devuelve un código de error que el comprador no ha visto ni una vez en su vida. El tercero es la responsabilidad: quién actualiza el sistema operativo, quién el servidor web, quién PHP y quién el propio sitio, y es aquí donde los compradores de VPS calculan mal con más frecuencia, porque el acceso root no es un regalo que el proveedor entrega junto con una máquina más potente — es el paso de la lista de deberes de él a usted, y ocurre en silencio, en el mismo minuto en que se envía la contraseña.

Todo lo demás que ocupa filas en una tabla comparativa de hosting es o bien igual en todos los planes, o bien no es lo que falla: los discos NVMe hoy están prácticamente en todas partes, pero el «tráfico ilimitado» es una afirmación sobre el volumen de datos transferidos, no sobre los recursos, y suele estar justo al lado de la tabla en la que los recursos están contados hasta el último megabyte. El 99,9 %, por su parte, es una cifra con un significado jurídico preciso y con una lista de excepciones debajo, y la mayor parte de los compradores cree que cubre algo muy distinto de lo que cubre de verdad.

Hosting compartido: un servidor, muchas cuentas

El hosting compartido es una cuenta de usuario en una máquina en la que viven cientos de cuentas iguales, y los proveedores españoles llaman a este mismo producto de tres maneras: IONOS lo escribe como hosting compartido, Webempresa como hosting compartido y también como alojamiento compartido, y en el catálogo el producto suele aparecer simplemente como alojamiento web. Técnicamente, en los tres casos significa el mismo acuerdo: a usted le pertenece la cuenta, no la máquina; el sitio lo gestiona a través de cPanel o de un panel similar; y todo lo que está por debajo de ese panel pertenece a otro.

Lo que lo separa a usted de los vecinos es software concreto, no una promesa en la tarifa, y conviene conocerlo por su nombre. La mayor parte de los proveedores con cPanel trabaja sobre CloudLinux, en el que cada cuenta tiene su propia copia del sistema de archivos: la documentación de CloudLinux sobre CageFS escribe que los usuarios no pueden ver ni detectar a otros usuarios ni sus nombres de usuario en el servidor, no pueden leer la configuración del servidor web y solo ven una lista de procesos recortada. La segunda capa es LVE — un contenedor de recursos a nivel de kernel que fija a cada cuenta límites de procesador, memoria, entrada/salida y procesos precisamente para que, en la formulación de la propia documentación, ningún sitio por sí solo pueda tumbar el servidor web entero.

La tercera capa es el ajuste PHP open_basedir, y aquí conviene saber lo que dice el propio manual de PHP, no el marketing del proveedor: es solo una medida de protección adicional y no es de ninguna manera exhaustiva, y no debe dependerse de ella cuando se necesita seguridad. En el mismo lugar el manual advierte que desactivar funciones con disable_functions también puede eludirse y que en un entorno de alojamiento compartido no es una medida de seguridad suficiente. Nada de esto es un argumento contra el hosting compartido; es un argumento de que el aislamiento lo dan aquí el kernel y el sistema de archivos, no una línea en un archivo de configuración, y de que un proveedor que responde a la pregunta sobre el aislamiento con la palabra «seguro» no ha respondido.

Lo que en el hosting compartido no se puede elegir importa tanto como lo que sí se puede: el kernel es uno para todas las cuentas, así que la versión del kernel no la va a cambiar; la lista de versiones de PHP la fija el proveedor y suele ir una o dos por detrás de la más reciente; el servidor web es el que está instalado, así que la respuesta a la pregunta por un paquete que no está será «no», no «instálelo». Un servidor compartido es también el lugar en el que, si hay un incidente, el proveedor tiene que revisar las cuentas vecinas, porque un atacante que ha entrado en una cuenta intenta lo mismo con los vecinos; qué hacer cuando eso ya ha ocurrido lo hemos descrito en el artículo sobre un sitio WordPress pirateado. Ninguno de estos límites es un defecto: es exactamente el acuerdo que hace barato este producto, y el comprador que lo entiende saca partido de ello.

Qué ocurre cuando la cuenta choca contra su límite

Un plan de hosting compartido tiene varios topes distintos; se alcanzan con independencia unos de otros y se manifiestan de formas completamente diferentes, así que el síntoma es una herramienta de diagnóstico útil. Los límites por defecto de CloudLinux para una cuenta son el 100 % de un núcleo de procesador, 1 GB de memoria física, 1024 KB/s de entrada/salida, cien procesos y veinte entry processes — procesos que entran en la cuenta desde fuera —, y es precisamente la última cifra la que sorprende a los compradores, porque veinte suena a un número ridículamente pequeño para un sitio que recibe diez mil visitantes al mes.

La explicación es que un entry process no es un visitante: es un proceso que entra en la cuenta desde fuera — una petición HTTP nueva a un script PHP, una sesión SSH o una tarea cron — mientras que los procesos que ya nacen dentro cuentan en un límite del todo distinto. Cuando se ha alcanzado el número de entry processes, el módulo de Apache ya no deja entrar la siguiente petición y devuelve el error 508 Resource Limit Reached, y CloudLinux lo describe en su base de conocimiento sin suavizarlo: el sitio que consume demasiados recursos deja de funcionar, pero el resto de clientes en el mismo servidor siguen operando con normalidad. Ese es exactamente el sentido de este mecanismo: cortar una cuenta para que no se pare la máquina.

Los demás límites se manifiestan de otra manera, y del síntoma se puede leer cuál se ha alcanzado exactamente antes de que alguien empiece a adivinar: el procesador y la entrada/salida no se cortan, se frenan, así que la página se vuelve lenta y al final se abre, mientras que los límites de memoria y de procesos suelen dar un 500 o un 503, es decir, una página que no se abre en absoluto. En servidores LiteSpeed los entry processes se cuentan de forma distinta que en Apache, así que ahí esa misma cifra no debe traducirse como número de visitantes simultáneos, y esa es una de las maneras más frecuentes de que un número correcto acabe en la frase equivocada.

Hay todavía un cuarto tope, que no tiene nada que ver con la carga y por eso se cuela sin avisar: un inode (inodo) es el registro del sistema de archivos de un archivo o una carpeta, así que el número de inodes en la cuenta es sencillamente el de archivos y carpetas, incluido el buzón que nadie ha vaciado en años. Hostnet publica los inodes abiertamente en su tarifa — en el plan MINI 400.000, PLUS 600.000, PRO 800.000 — y en la misma tabla, junto a MINI y PLUS, están el 100 % de un núcleo y 2048 MB de memoria, y junto a PRO el 200 % y 3072 MB, además de 10 MB/s de entrada/salida y 150 conexiones simultáneas para los tres, mientras que el tráfico mensual es «ilimitado». Esta combinación es la verdadera lección sobre la palabra «ilimitado» en una tarifa de hosting: se refiere al volumen de datos transferidos, y todos los demás límites están ahí al lado, contados hasta la última cifra.

VPS: su propio sistema operativo sobre hardware compartido

Un VPS (servidor privado virtual) es una máquina virtual en la que a usted le pertenecen el sistema operativo, el acceso root y la posibilidad de instalar lo que haga falta, y en el mercado español se escribe tanto con la abreviatura inglesa como desarrollado: IONOS lo llama servidor virtual privado, y el propio servicio se vende como VPS. Lo que este nombre no dice son dos preguntas técnicas que deciden cuánto del «servidor propio» es de verdad suyo.

La primera pregunta es si la virtualización es a nivel de hardware o de sistema operativo. KVM es un módulo del kernel de Linux que usa las extensiones de virtualización del procesador y da a cada invitado su propio hardware virtualizado — tarjeta de red, disco, adaptador de vídeo — y, sobre todo, su propio kernel, así que sobre él se puede ejecutar también un Windows sin modificar. LXC y los contenedores emparentados son otro mecanismo: usan espacios de nombres de Linux, cgroups y la restricción de capacidades para crear un entorno lo más cercano posible a una instalación Linux aparte, pero sin un kernel propio. Las consecuencias son simples y prácticas: en un contenedor la versión del kernel, los módulos del kernel y las vulnerabilidades del kernel siguen siendo comunes con la máquina anfitriona, así que parte de lo que usted creía estar comprando se quedó en realidad con los vecinos.

La segunda pregunta es sobre el procesador, porque las palabras «servidor propio» no significan procesador propio. Los servidores cloud de Hetzner tienen dos líneas de producto distintas: en los planes de recursos compartidos la capacidad de cálculo se reparte entre todas las instancias del mismo servidor físico, con un rendimiento base y la posibilidad de superarlo un tiempo, mientras que en los planes de recursos dedicados un vCPU es un hilo de un núcleo físico y solo suyo. DigitalOcean lo formula todavía más claro: en un plan compartido el hilo puede estar repartido con otros, y si los vecinos tienen mucha carga la instancia recibe porciones del hilo, no el acceso completo, de modo que en la práctica el acceso completo es posible, pero no está garantizado.

Cuántos vecinos hay en una máquina no lo publica ninguno de los grandes proveedores, y la proporción que encontrará en los blogs no es la medición publicada de nadie, así que no merece la pena ni citarla ni creérsela. La única magnitud documentada a la que se puede apelar es si el plan promete recursos compartidos o dedicados, y esta diferencia suele estar escrita con toda claridad: con dos nombres de producto distintos, dos especificaciones distintas y una diferencia de precio que es varias veces mayor.

El servidor en la nube es el mismo VPS, comprado de otra forma

Un servidor en la nube es técnicamente una máquina virtual sobre un hipervisor, es decir, exactamente lo mismo que un VPS, y también se explica así: IONOS escribe que los servidores cloud son servidores virtuales, y la documentación de Hetzner empieza por la misma frase — los servidores cloud son máquinas virtuales que se ejecutan sobre servidores físicos. Si de dos ofertas espera usted dos máquinas físicas distintas, la espera no tiene fundamento.

La diferencia no está en el hardware, sino en la forma de comprarlo, y la describe con más precisión la definición del NIST, el instituto estadounidense de normas, que el sector sigue citando: la nube tiene cinco rasgos — autoservicio bajo demanda, acceso por red, agrupación de recursos con varios inquilinos, elasticidad rápida y consumo medido. En la práctica eso significa una API con la que se puede crear y destruir la máquina por programa, tarificación por horas con un tope mensual y piezas adicionales que se pueden conectar por separado: snapshots (imágenes instantáneas), almacenamiento de bloques aparte, una dirección IP flotante y un balanceador de carga.

Cada una de estas piezas tiene límites que conviene conocer antes de la compra, no un mes después. El cambio de plan de Hetzner no puede reducir el tamaño del disco aunque solo se use una parte; después de ampliar el disco hay que extender la partición usted mismo en modo Rescue, y el propio cambio de plan figura como excepción de la garantía de disponibilidad. Un snapshot, a su vez, no es una copia de seguridad, aunque el mercado use las dos palabras como sinónimos: en los snapshots de Hetzner no entran los volúmenes adjuntos, y la consistencia no está garantizada si el servidor está en marcha, así que es una buena cosa antes de una actualización y una mala cosa como única copia de los datos. La dirección IPv4 flotante se cobra aparte, igual que la IPv4 principal de la propia instancia.

Un sitio corporativo de cinco páginas no suele usar ninguna de estas piezas, y esa es la frase más honesta de esta sección: si el sitio nunca cambia de potencia, nunca conmuta a una segunda máquina y nunca se conecta a una API, entonces un servidor en la nube y un VPS del mismo tamaño son la misma máquina con dos facturas distintas. Eso no es un argumento contra la nube, porque ahí donde se usa la elasticidad, cuesta menos que una reserva mantenida de forma permanente. Es un argumento de que la elección está entre capacidades que usted va a usar de verdad, no entre palabras que suenan modernas.

Quién actualiza qué

La mayor diferencia práctica entre los tres planes no es la velocidad, sino el reparto de deberes, y quienes lo han formulado con más claridad son los propios proveedores de nube. El modelo de responsabilidad compartida de AWS lo divide todo en dos partes: la seguridad de la nube es responsabilidad de AWS — el hardware, el software, la red y las instalaciones en las que funcionan los servicios — y la seguridad en la nube es responsabilidad del cliente. En la cuestión de los parches está escrito incluso aparte y palabra por palabra: AWS es responsable de implementar parches y de corregir defectos en la infraestructura, pero el cliente es responsable de los parches de su sistema operativo invitado y de sus aplicaciones.

En el hosting compartido esta capa pertenece al proveedor, y ese es el mayor valor de este producto, en el que rara vez se piensa: el kernel, el servidor web y PHP los actualizan ellos, y usted no se entera de nada hasta que algo se rompe. En un VPS o un servidor en la nube no gestionados, todo eso pasó a usted junto con la contraseña root, y Hetzner lo dice también desde el otro lado en sus condiciones: el software, la configuración y los ajustes del sistema que introduce el cliente no se consideran una interrupción de la disponibilidad, así que el proveedor no responde de ellos y no entran en ninguna compensación.

El propio sitio web sigue siendo su responsabilidad en los tres casos, y ese es el punto en el que las ofertas hay que leerlas con atención, porque la palabra «gestionado» en el sector suele significar el sistema operativo y el software del servidor, no el núcleo de WordPress, los plugins y el tema. También en el mantenimiento de nuestro propio alquiler de infraestructura entran las actualizaciones del sistema operativo y del software del servidor, la configuración de seguridad, las copias de seguridad con restauración comprobada, la monitorización y la reacción según el SLA — y ahí no está escrito que actualicemos sus plugins, porque esa es otra línea de la tarifa y otro contrato, y lo decimos con claridad para que nadie descubra este límite el día de un incidente.

La prueba práctica antes del pedido es una pregunta, planteada sin rodeos y en tres partes: quién actualiza el sistema operativo, quién el servidor web y PHP, y quién el código del sitio. Si la respuesta a alguna de las tres es «usted mismo», entonces es un trabajo para el que hace falta o una persona con tiempo o un contrato con otro, y ninguno de los dos es gratis. Sin respuesta, esta pregunta no desaparece: vuelve a los dieciocho meses como un sistema en el que nadie ha puesto ni un parche, y entonces ya no es una cuestión de elección de plan.

Qué significa el 99,9 % y qué no cubre

El porcentaje de disponibilidad en la tarifa parece una promesa, pero en realidad es una fórmula con una lista de excepciones. El acuerdo de nivel de servicio de los servidores cloud de Hetzner promete un 99,9 % al mes para una instancia, y el propio Hetzner calcula en su explicación lo que significa esa cifra en la práctica: en un mes de treinta días, 43 minutos de inactividad siguen dentro del acuerdo, es decir, no son un incumplimiento y no está prevista ninguna compensación por ellos.

La compensación misma es igual de concreta y mucho más pequeña de lo que la gente espera: se calcula a partir de los minutos por encima del umbral, convertidos en horas y multiplicados por la tarifa horaria de la instancia, y se paga como crédito contra el consumo futuro, no como dinero. En el ejemplo del propio Hetzner, 185 minutos de inactividad dan 142 minutos por encima del umbral, o 2,37 horas, y un crédito de 0,87 €, que es menos de lo que cuesta una hora de trabajo para calcularlo. El volumen de negocio no recuperado, los pedidos perdidos y las posiciones caídas en los buscadores no entran en ningún sitio, y ningún acuerdo de hosting que hayamos leído los cubre.

La lista de excepciones es tan importante como la cifra, porque es precisamente ella la que decide con qué frecuencia se aplica esa cifra: fuera del acuerdo quedan el mantenimiento anunciado de antemano, el software y la configuración del propio cliente, el cambio de plan pedido por el cliente, las migraciones en vivo por estabilidad de la máquina anfitriona y la red más allá de la red principal del proveedor. Todo eso está escrito con honestidad y a la vista, y de ahí se sigue una conclusión simple: el porcentaje se aplica a la máquina, no a su sitio web, así que un sitio que se cayó tras una actualización fallida está fuera de este contrato por completo.

Además, el 99,9 % no es una constante del sector, aunque a menudo se use como si lo fuera. El acuerdo de Amazon EC2 para una instancia promete un 99,5 %, y el 99,99 % solo si las instancias están colocadas en al menos dos zonas de disponibilidad, es decir, son dos contratos distintos con dos cifras distintas, y la frase «en el sector hay un 99,9 %» aplana las dos en una. En el hosting compartido un documento así suele no existir en absoluto: solo hay una cifra en la página web, sin definición, sin método de medición y sin consecuencias, y eso es una afirmación, no un compromiso.

Cómo medir su sitio antes de elegir

La cifra que decide no es el número de visitantes al mes, aunque sea exactamente la que el comprador sabe de memoria y exactamente la que el vendedor pregunta primero. Lo que decide es el número de peticiones PHP simultáneas en el momento en que la carga es mayor, y esa es una magnitud del todo distinta, que correlaciona débilmente con la visita mensual.

Dos sitios con la misma visita pueden estar a lados distintos del mismo límite, y la diferencia está en cuánto tiempo mantiene cada página un proceso. Un sitio corporativo estático, servido desde la caché, lo atiende en su mayor parte el servidor web sin PHP, así que casi no consume entry processes y diez mil visitantes al mes no le significan nada. Una tienda online en la que cada cesta, cada inicio de sesión y cada vuelta desde la pasarela de pago mantiene el proceso PHP dos segundos puede alcanzar ese mismo límite ya con veinte compradores simultáneos, y precisamente por eso, en la primera hora de una campaña, caen exactamente las tiendas que han pagado la campaña.

Junto a esta cifra conviene leer otras tres, y las tres están disponibles sin ayuda de un desarrollador. La primera es el tamaño de la base de datos y la consulta más lenta en ella, porque suele ser esa la causa real de la lentitud, no la potencia de la máquina. La segunda es el número de archivos en la cuenta, porque el límite de inodes lo alcanzan de forma inesperada y sin aviso los sitios con bibliotecas de medios grandes y con un buzón viejo. La tercera es lo que el sitio hace fuera del navegador — tareas cron, envío de correo, integraciones con el sistema de contabilidad — porque estos procesos también entran en la cuenta desde fuera y cuentan en el mismo límite que usted acaba de medir para los compradores.

Las cuatro cifras se pueden leer en una tarde a partir de las estadísticas del panel de hosting y de los registros del servidor, y ese es el único sitio en el que está la carga real de su sitio, no una idea de ella. El nombre del plan no conoce estas cifras; el vendedor que no las ha visto, tampoco; y una conversación que empieza con ellas suele terminar en una respuesta más barata que una conversación que empieza con una lista de planes.

Cuándo el cambio ayuda y cuándo no resuelve nada

Pasar a un plan más grande es la respuesta correcta bastante menos a menudo de lo que se ofrece, y el primer caso en el que no ayuda es también el más frecuente. Si el sitio es lento porque una consulta lee toda la tabla de productos en cada apertura de página, una máquina más potente la ejecutará más rápido, el problema seguirá ahí, y usted habrá comprado tiempo, no una solución. Lo mismo vale para cuarenta plugins, para imágenes sin procesar a tamaño real y para un tema que en cada petición construye el menú desde cero.

El cambio es la respuesta correcta cuando el límite se ha alcanzado con código correcto: si el sitio está en caché, las consultas están en orden y la cuenta sigue chocando contra el número de entry processes, entonces es un límite del plan, no un defecto del código, y ya no hay nada que optimizar. El cambio es también la única respuesta cuando hace falta algo que en una cuenta compartida no se puede instalar — otra versión de PHP, un procesador de colas, Redis, un cron propio con paso de un minuto — o cuando un requisito de sector, de un pliego o de un cliente fija en qué país están los datos físicamente.

Hay también un tercer caso, del que los vendedores hablan poco porque reduce la factura: a veces el movimiento correcto es hacia abajo. Un sitio que hace tres años se pasó a un VPS por una campaña de publicidad y desde entonces recibe doscientos visitantes al día paga por una máquina que no usa, y paga dos veces: con dinero en la factura y con el tiempo de una persona, porque el sistema operativo de un VPS hay que actualizarlo aunque no entre nadie.

Antes de cualquier mudanza conviene resolver todavía una pregunta que no tiene nada que ver con la potencia: a nombre de quién está registrado el dominio y a nombre de quién está la cuenta de hosting. Sobre eso hemos escrito aparte en el artículo sobre los errores al encargar el desarrollo de un sitio web, y esta es una de esas preguntas que el día de la migración ya no se reparan rápido, porque la respuesta depende de una persona con la que usted quizá ya no habla.

Qué compra usted cuando el plan se llama hosting gestionado

La diferencia de precio entre una máquina no gestionada y una gestionada es grande, y no es un recargo sobre la misma mercancía, así que es honesto poner las dos cifras una al lado de la otra. En la tarifa de Hetzner que entró en vigor el 15 de junio de 2026, un servidor cloud CX23 con dos vCPU, cuatro gigabytes de memoria y 40 GB de disco cuesta 5,49 € al mes sin IVA, y la dirección IPv4 principal se añade por 0,50 € al mes. Nuestro hosting gestionado y servidores empieza en 45 € / mes, y la diferencia entre estas dos cifras es exactamente de lo que trata esta sección.

La diferencia es trabajo, y se puede enumerar pieza a pieza: actualizaciones del sistema operativo y del software del servidor, configuración de seguridad, monitorización con Zabbix las veinticuatro horas y reacción según el SLA, copias de seguridad cada día con 30 días de conservación y restauración comprobada con regularidad, y para infraestructura especialmente crítica, hasta 365 días y en dos países distintos de la Unión Europea. La preparación del entorno y la mudanza ocupan 3–10 días, la migración la hacemos en paralelo y el DNS lo conmutamos en una ventana planificada, y después usted tiene un contacto responsable, no un ticket de soporte en otra zona horaria.

Hay que decir también con honestidad la otra cara, porque sin ella esta sección sería una tarifa con un artículo alrededor. Si su sitio es estático, la visita es pequeña y nadie pide nunca una versión de PHP que el proveedor no tiene, entonces el hosting compartido por unos pocos euros al mes es la respuesta correcta, y un entorno gestionado sería un pago por una tranquilidad que usted ya tiene. Se lo decimos también a quienes llaman con esta pregunta, porque vender un entorno que no se usa es un trato a corto plazo: al cabo de un año vuelve como la pregunta de a cambio de qué se estaba pagando en realidad, y a eso no hay una buena respuesta.

Si no está seguro de qué lado de este límite está su sitio, esas cuatro cifras se pueden leer juntas: escríbanos, y le diremos qué muestra la estadística de su cuenta actual y cuál es el límite más cercano — también si la respuesta resulta ser que no hay ninguna necesidad de mudarse y que el dinero está mejor invertido en la velocidad del sitio.