Hosting compartido vs VPS — cuándo migrar y por qué

Dónde fallan los planes compartidos: límites de CPU, reputación de IP compartida, muros de inodos — y el salto a un VPS KVM con root desde $4.80/mes anual.

Un Apache, cientos de inquilinos: el trato que realmente firmaste

Lo contraintuitivo de un plan compartido es que no se trata de un servidor pequeño: es una cola con tu nombre. Alquilaste un directorio bajo /home/username/public_html en un sistema operativo que nunca verás, y esa cifra mensual tan baja no es generosidad que el proveedor haya absorbido: es la consecuencia aritmética de no reservar nada. Cientos de sitios comparten un kernel, un proceso de servidor web y una IPv4, y cada techo con el que acabas chocando se remonta a esa única decisión de diseño.

Mecánicamente, el host ejecuta un servidor web que atiende a cientos de hosts virtuales, y una capa de control mide cuánto tiempo de procesador puede consumir cada cuenta por intervalo. Las peticiones dentro del límite se sirven; las que lo superan mueren como respuestas 503 o 508 antes de que tu código llegue a ejecutarse. El proyecto Apache documenta los módulos multiproceso que hacen posible esta densidad (documentación de Apache HTTP Server). El tráfico se rige por cláusulas de uso razonable y no por una velocidad de puerto publicada, de modo que el pico de lanzamiento de un vecino aterriza en tu página de estado como errores que tú no causaste.

El mismo compartimento rige el correo y las tareas programadas: una sola cola de Postfix o exim atiende a todos los inquilinos, un solo planificador serializa los trabajos de todos, y el abuso de una cuenta se responde apretando la correa de todos. Nada de esto es un defecto que soporte técnico pueda parchear, porque la arquitectura es justo lo que hace posible ese precio. Cuando compras compartido, lo que recibes es un puesto en la cola con una asignación estricta adjunta: no hardware, ni una porción garantizada, ni capacidad sobre la que puedas planificar un lanzamiento.

Incluso las partes cómodas esconden uso compartido. Las copias de seguridad que programas ocupan tu propia cuota; los registros que nunca pediste se acumulan en tu conteo de archivos; el propio panel consume asignación mientras lo configuras. Un ajuste en wp-config.php surte efecto al instante porque el intérprete ya está residente para todo el nodo: esa inmediatez es la cara amable del alojamiento compartido, y se paga con la misma aritmética que estrangula tu hora de mayor tráfico.

El error típico es leer la tabla del plan como capacidad: el ancho de banda ilimitado parece un techo y en realidad es la línea menos restrictiva de la página. Lo que aprieta primero son los segundos de procesador, los procesos de entrada y el conteo de inodos, ninguno de los cuales la página de ventas imprime junto al precio. Hasta que planifiques en función del medidor y no de los terabytes, cada optimización dentro de la cuenta apunta a la restricción equivocada, y la restricción, y no tu código, es la que lanza los errores 500.

Los límites de CPU son un medidor, no un plan de capacidad

Una asignación estrangulada se comporta como un contador de electricidad prepagado: que salte no significa que la máquina se quedara sin capacidad, significa que gastaste tu cupo del intervalo. Los paneles compartidos lo imponen con muros a nivel de kernel, y esa imposición permanece invisible hasta el momento en que ralentiza tu checkout delante de un cliente que va a pagar. Por eso el informe clásico del síntoma suena a leyenda urbana: el sitio funciona sin problemas y, de repente, se arrastra exactamente a la hora en que aterriza tu campaña.

El mecanismo es una valla de grupo de control trazada alrededor de cada cuenta: una porción de los núcleos, un techo de memoria, un tope de workers concurrentes. La documentación del kernel describe el modelo sobre el que se construyen estos paneles (documentación de cgroup v2 del kernel). Cifras concretas: una asignación del 100% equivale a un núcleo completo repartido por el nodo; un tope de 20 procesos de entrada significa que la vigésimo primera petición simultánea se encola o falla. El chasis en sí se mantiene sano durante todo el proceso: la escasez es contractual, no física.

La presión se nota antes de que lleguen los errores. El kernel registra el tiempo de bloqueo, tramos en que las tareas esperaron al procesador, y en tu propia máquina podrías leerlo directamente en /proc/pressure; en compartido lo infieres de las gráficas de latencia que el panel te concede a regañadientes. Como la valla es por cuenta, no puedes sintonizar a través de ella desde dentro: la caché estira el presupuesto, pero un medidor que estrangula el calentamiento de la caché cancela el beneficio, y una reindexación nocturna choca con la misma ventana de 60 segundos cada vez.

Los paneles muestran el medidor disparado como un aviso de recursos o una gráfica de uso: el recibo, no un diagnóstico. Las cifras aún cuentan la historia: una latencia p95 que sigue tu calendario de marketing en vez de tus cambios de código es la firma de una asignación, no de una aplicación. Anota en qué horas muerde el techo (lanzamientos de campaña, picos matinales, solapamiento de cron), porque son las horas que pagarías dos veces en una migración de emergencia mal ejecutada más adelante.

El error estándar es comprar el plan compartido más grande esperando que el muro se mueva proporcionalmente. Se mueve, pero sigue siendo un muro, y el tráfico pico sigue encontrándolo. Si los tiempos de respuesta se degradan justo cuando llega la demanda, estás midiendo un racionamiento. La solución duradera es arquitectónica: capacidad reservada en una tabla de planes en lugar de racionada por asignación, que es precisamente la frontera que un VPS KVM traza a tu alrededor.

La reputación de IP es un bien común que heredas, no una puntuación que te pertenece

Aquí va lo contraintuitivo: tu entregabilidad puede hundirse sin que nunca hayas enviado un mensaje cuestionable. En un plan compartido, cientos de inquilinos envían a través de una sola IPv4 con un único registro PTR, y los sistemas receptores puntúan esa dirección antes de leer una sílaba del contenido. Cuando un vecino hace spam desde ella, la entrada en la lista de bloqueo cae sobre todo el vecindario, y tus restablecimientos de contraseña rebotan con los mismos códigos 550 que la basura.

Los receptores se comportan así porque el protocolo de correo autentica el sobre, nunca la intención: el comportamiento está codificado en la especificación SMTP (RFC 5321), y los sistemas de reputación crecieron para cubrir ese vacío de confianza. Las listas de bloqueo públicas indexadas por direcciones son el sistema inmunitario de la industria (su formato de consulta está estandarizado en el RFC 5782). Un mal inquilino gana una inclusión en la lista; cada cuenta detrás de esa salida compartida por el puerto 25/tcp hereda la penalización hasta que la inclusión caduca o el proveedor rota la dirección.

Lo que sí responde a tu propio esfuerzo es el lado del dominio: cabeceras autenticadas, higiene de listas, disciplina de envío. Lo que no responde es la dirección en sí: no puedes calentar, rotar ni gestionar la reputación de una IP compartida con desconocidos, y ningún operador renumera un nodo porque tus boletines cayeran en la pestaña de promociones. Los aplazamientos se endurecen hasta convertirse en rechazos explícitos 5.7.1 mientras tu copy sigue idéntico; la variable nunca fue la prosa.

Donde el daño se agrava: el correo transaccional (recibos, restablecimientos, facturas) comparte esa misma salida envenenada con el marketing que nunca pidió tener al lado. Una tienda puede perder el flujo de restablecimiento de contraseña durante una semana y ver triplicarse el volumen de soporte, todo por la campaña de un vecino. La recuperación en el receptor es un trámite lento; reenviar con más fuerza solo demuestra que sus filtros tenían razón y profundiza el hoyo en el que ya estás.

El error típico es pulir el SPF y la redacción mientras la dirección compartida sigue en la lista, o peor, escalar el volumen para forzar la entrega. Diagnostica en el orden correcto: demuestra que la dirección es la variable probando desde otra distinta, y luego traslada el trabajo de correo a infraestructura que gobiernes tú. La reputación se adhiere al par A/PTR y al dominio: controla ambos y la entregabilidad se vuelve un problema resoluble; compártelos y es la variable de un desconocido llevando tu nombre.

La cuota real son los inodos, no los gigabytes

La sorpresa llega en forma de disco lleno en un plan que anuncia espacio ilimitado. Los hosts compartidos cuotifican archivos, no solo bytes: cada mensaje, miniatura, entrada de directorio y fragmento de caché consume un inodo, y el techo en estas cuentas se sitúa entre cincuenta mil y medio millón. Puedes estar inactivo al 40 por ciento de tus gigabytes y aun así estamparte contra el muro, porque el contador que aprieta enumera objetos, no volumen, y nada en la página de ventas admite que existe.

La mecánica del llenado es mundana. Un Maildir que conserva cada mensaje desde la fundación de la empresa, una caché de CMS que escribe un archivo por fragmento renderizado, un plugin de copias que instantanea cada noche dentro de tu propia asignación, un checkout de control de versiones por cada experimento: cada uno añade miles de objetos pequeños que nunca se agregan en un peso visible. Ejecuta df -i contra una cuenta longeva y la columna IUse% dirá la verdad que el marketing omitió. El correo es el campeón habitual: un solo mensaje con adjuntos gasta varios inodos antes de que nadie lo lea.

Donde se rompe, se rompe de lado. Las escrituras empiezan a fallar a mitad de operación con ENOSPC: un carrito no puede guardar su sesión, una subida llega truncada, una tabla temporal de base de datos se niega a crecer, mientras la gráfica de uso muestra la mitad de la asignación libre y soporte repite que todo está bien. El techo se eleva una vez, quizá dos, por cortesía; a partir de ahí el techo es política, y la política termina en un máximo duro que ningún ticket puede negociar.

Hay un coste de segundo orden que la gente pasa por alto: la misma presión de conteo de archivos ralentiza el gestor de archivos del propio panel, alarga las copias de seguridad y puede empujar la exportación nocturna fuera de su ventana, de modo que la instantánea de ayer silenciosamente nunca ocurre. La cuota no solo detiene las escrituras en el límite: degrada todo lo adyacente durante semanas antes de que llegue el límite, razón por la cual el primer síntoma suele ser una copia de seguridad que descubres que nunca se tomó.

El error es responder borrando contenido multimedia byte a byte, tratando un conteo como un peso. Audita con conteos en su lugar: find . -xdev | wc -l por directorio supera cualquier estimación basada en tamaños, y luego reubica la clase de datos de archivo: montañas de correo, derivados de imágenes, copias de las copias. Una cuota que no puedes inspeccionar desde dentro es una cuota que no puedes planificar; una máquina con root te muestra cada contador que aplica, que es la versión honesta del mismo contrato.

Lo que cambia de verdad con una porción reservada

La descripción honesta de un VPS KVM no es un plan compartido más grande: es un contrato distinto. Una porción reservada llega con su propio kernel, su propio hardware virtual y una tabla de planes que imprime la asignación: tienes los núcleos, la memoria y la velocidad de puerto lo uses o no, y el pico de nadie más puede aparecer en tus gráficas. El proyecto KVM documenta la frontera de virtualización que hace exigible ese aislamiento (proyecto Linux KVM).

En VPSbit el punto de entrada es Core: 2 vCPU en un Ryzen 9 9950X, 4 GB DDR5, 80 GB NVMe, un puerto de 1 Gbps sin límite de tráfico y una IPv4 más una asignación IPv6 de /64. Pide Core a $6/mes de tarifa ($4.80/mes en el término anual) y pon la factura junto a un plan compartido premium: el dinero ocupa el mismo rango, pero cada número de arriba está reservado y publicado en lugar de racionado tras una prosa de uso razonable. El registro de planes VPS imprime cada nivel junto a sus especificaciones.

El root también amplía la superficie de software: virtualización anidada, Docker sin restricciones (sí, --privileged), ISOs personalizadas, sockets en bruto: justo las características que los términos compartidos prohíben de una en una porque cada una requiere acceso al kernel. Tu stack deja de ser un desplegable que el host curó. Servidores de correo, terminaciones VPN, runners de CI, relés de voz, salas de juego: todo funciona porque el kernel responde ante ti y ningún anexo de uso aceptable excluye las cargas de trabajo una por una.

La geografía también pasa a formar parte de la especificación. Doce centros de datos componen el mapa (Reikiavik y Zúrich entre ellos, junto con Ámsterdam, Fráncfort, Tokio, Singapur, Hong Kong, Taipéi y el resto), cada uno con su propio nivel, enlace ascendente y ley aplicable, y el abuso se gestiona bajo la jurisdicción donde físicamente se encuentran los racks. En compartido, la ubicación de tus datos era una línea en una política; aquí es un atributo que eliges al pedir y puedes cambiar redeployando.

El error a evitar es importar las expectativas del compartido: comprar la porción y tratar las especificaciones publicadas como un acelerador que conviene exprimir. Nada te estrangula; la restricción migra a tu propia configuración, tu propio ritmo de parcheo, el estado de tu propio firewall. El techo ahora es la tabla de planes y no el humor de un medidor, lo que plantea la pregunta práctica que esta página responde a continuación: ¿cuándo fue el medidor, y no las especificaciones, tu problema real?

Cinco señales, ordenadas por lo que te cuestan

Contraintuitivamente, el correo de estrangulamiento, la señal que todos tratan como urgente, es la más barata de las cinco. Cuesta rendimiento, no datos. Ordenadas por daño real: primero el colapso de entregabilidad, porque el correo que sale por un 25/tcp compartido puede desaparecer sin un rebote que controles; luego el muro de inodos, donde las escrituras sobre datos en producción fallan a mitad de operación; después las actualizaciones forzosas que exigen root porque algún componente simplemente no está permitido en compartido; luego los avisos de recursos; y por último la revalorización del precio en la renovación de ese mismo puesto en la cola.

El orden importa porque las señales corren en relojes distintos. La entregabilidad se degrada durante semanas y las reparaciones tardan otras tantas, así que merece la respuesta más temprana de toda la lista. El muro de inodos llega de golpe y rompe escrituras en producción sin período de gracia. El estrangulamiento es crónico pero sobrevivible: un insulto, no una herida. Actúa en el orden en que el daño se classifica y a menudo migrarás antes de que la señal oficial, el correo de recursos, llegue siquiera a tu bandeja.

Donde los lectores se equivocan: tratan el aviso de recursos como una tarea pendiente (optimiza el sitio) y no como una medición de la arquitectura. La optimización que te mantiene por debajo de un medidor no es margen; es una apuesta a que la demanda nunca crezca. Mientras tanto, la señal de correo, la que de verdad pierde datos, se ignora porque la bandeja sigue viéndose bien desde la silla del remitente. Los informes de rebote (mailq en tu propia máquina, los registros del panel en compartido) son la bandeja honesta.

También hay un efecto de agravio entre señales: el estrangulamiento durante un pico de correo convierte las conversaciones SMTP en aplazamientos, los aplazamientos envejecen hasta volverse rebotes 5xx, y los rebotes esculpen la historia de reputación de la sección anterior. Las cinco señales no son alarmas independientes; son un único patrón de congestión con cinco disfraces, razón por la cual parchear un solo disfraz rara vez cambia el final por más de un ciclo de facturación.

Un umbral práctico: dos señales cualesquiera dentro de un mismo trimestre significan que el problema es la arquitectura, no la carga de trabajo: programa la migración en lugar de dar otra vuelta de optimización. La guía de requisitos y límites detalla qué cambia el día que tienes root. Las señales uno y cinco se repiten para siempre en compartido; la lista de cierre final las convierte en un proyecto de una semana con ventana de reversión en lugar de un salto de fe.

La ruta de migración, sin drama

Lo intimidante de migrar nunca es la copia de archivos (rsync -a por SSH mueve un sitio típico en minutos), sino el corte de DNS y el correo. Haz bien la secuencia y toda la mudanza es una semana tranquila: aprovisionar, línea base, construir, copiar, cortar, mantener una ventana de reversión, cancelar. Hazla mal y pierdes el correo entrante un fin de semana mientras tus compradores se preguntan si has quebrado.

Primero aprovisiona: elige el plan, paga la factura, y la máquina se imagea en unos 60 segundos; el pago admite diecinueve monedas y sin paso de tarjeta (la FAQ de pago recorre el flujo), de modo que la mudanza también termina, de propina, la renovación automática de la tarjeta antigua. Aplica la línea base antes de que ningún sitio toque la máquina: SSH solo con claves, firewall de denegación por defecto, actualizaciones de seguridad desatendidas. El proyecto OpenSSH documenta la superficie de configuración para el inicio solo con claves (manual de sshd_config).

Luego construye y copia: levanta el stack o un panel, refleja los archivos con rsync, mueve la base de datos con mysqldump y una reimportación (documentación de mysqldump; Postgres mantiene la misma forma con su propia herramienta de volcado), y prepara el stack de correo si lo alojas tú. Un día antes del corte, baja el TTL del registro A a 300 segundos para que los resolvedores olviden pronto la dirección antigua: el TTL a nivel de registro, no el del nameserver, marca la velocidad del cambio.

El error clásico es cortar MX, web y certificados en una sola noche heroica y depurar en caliente después. En su lugar: gira el registro A, vigila el registro de correo en la máquina nueva, conserva la cuenta antigua durante una ventana de reversión de varios días y cancela solo entonces, y abre el ticket del PTR para la nueva dirección antes de que el volumen crezca (la guía de rDNS cubre ese ticket línea por línea). Los mantenedores de Mailcow son tajantes en que el stack de correo es la pieza que exige paciencia (documentación de Mailcow).

Trata la mudanza como dos cortes, no uno: el corte web es reversible en segundos devolviendo el registro a su valor anterior; el corte de correo merece su propia hora, sus propias comprobaciones y una batería de pruebas del lado del remitente: restablecimientos de contraseña, confirmaciones de pedido y respuestas. Un corte limpio le gana a uno rápido cada vez que se ha probado, y la ventana de reversión es lo que convierte una migración de un salto en una edición reversible.

Lo que asumes con el root, y lo que lo compensa

El balance honesto: un VPS te entrega el parcheo, el estado del firewall, la disciplina de copias y la exposición a abusos la misma tarde que te entrega el root. La abstracción de la que sales era también una venda en los ojos: cuando la base de datos se arrastra en compartido, el proceso que perfilarías pertenece a otro, y nadie te entrega el perfil. En tu propia porción, la consulta lenta es tuya, y también lo es la autoridad para arreglarla a las 2 de la madrugada sin presentar nada.

Los paneles y los scripts de stack reducen la diferencia operativa a una tarde laboral aproximadamente: endurecimiento base, un firewall de denegación por defecto (ufw default deny incoming), una política de actualizaciones, una rutina de copias. La mayor parte de la lista se hace una sola vez; la parte recurrente es leer tus propios registros y restaurar una copia una vez, a conciencia, antes de necesitarla con urgencia. Las instantáneas vienen incluidas en el pago como complemento de reversión, cubriendo la clase de incidente de lo-rompí-hoy y no la de se-murió-el-disco.

Donde los novatos rompen cosas: se saltan la línea base porque la máquina se portó bien el primer día, y luego heredan un compromiso o un volumen muerto sin vía de restauración. El segundo modo de fallo es el silencio: el hosting compartido te escribía cuando saltaba el medidor; tu máquina se quedará al 100% de procesador indefinidamente sin comentario. Una sonda de uptime más una alerta de carga (uptime sondeado cada minuto basta para empezar) cierra la mayor parte de ese hueco por el precio de diez minutos y cero cuotas mensuales.

Hay una recompensa más silenciosa que los operadores descubren tarde: el determinismo. En compartido, cambios de terceros (un vecino nuevo, un ajuste de política, una actualización menor de PHP) alteraban tu entorno de ejecución sin aviso. En la porción, la única fuerza que cambia el entorno eres tú, lo que hace que las regresiones sean atribuibles y el rendimiento reproducible. Depurar pasa de arqueología a lectura; la misma aplicación que se portó misteriosamente mal durante meses se convierte en un sistema que puedes razonar desde primeros principios.

La escala es la recompensa final: cuando una carga de trabajo quiere un núcleo entero, IPMI o discos de terabytes, la escalera dedicada está en el mismo pago. Pide Forge a $49 de tarifa ($39.20 en el término anual) y tendrás 16c/32t, 2×1 TB NVMe y entrega de IPMI bajo una sola factura en cripto. Compra la máquina más pequeña que quepa hoy, redimensiona la porción cuando los números lo digan, y guarda la comparación VPS vs dedicado para el día en que una carga de zócalo entero llame de verdad a la puerta.

La salida del hosting compartido, en el orden en que hay que ejecutarla

Siete días antes, audita lo que realmente tienes: cuenta los inodos con df -i, exporta el correo que quieras conservar y lista cada trabajo programado y cada registro DNS que lleva la cuenta. El inventario decide el tamaño del destino (la mayoría de los sitios aterrizan en una porción de 2 vCPU con margen para crecer) y hace las veces de mapa de reversión, porque documenta con precisión qué hacía la cuenta antigua en su último buen día.

Cinco días antes, aprovisiona y establece la línea base de la nueva máquina: claves, firewall, actualizaciones desatendidas y luego el stack. Tres días antes, mueve el contenido y la base de datos, y prepara el correo: la mudanza del correo es la lenta, así que dale su propio día en lugar de una hora al final. Un día antes, baja el TTL del registro A a 300 segundos; los TTL cortos son lo que convierte un corte en un evento intrascendente en lugar de una lotería de propagación que nadie puede observar.

El día del corte, levanta el nuevo stack, gira el registro A y vigila tres cosas durante la hora siguiente: dig confirmando la nueva dirección, el registro de correo mostrando entrega entrante y los certificados emitiéndose sin quejas. Conserva la cuenta antigua durante toda la ventana de reversión (varios días, no horas), porque el seguro más barato del proyecto es el plan veterano que sigue respondiendo mientras el novato aprende tu tráfico real.

Verifica como un operador, no como un visitante: ejercita los flujos que tocan escrituras (un pedido, un comentario, un restablecimiento de contraseña) y confirma que cada uno aterriza en la base de datos que lee el nuevo stack. Compara las tasas de error a ambos lados del cambio en las analíticas que uses. Dos noches tranquilas de métricas corrientes dicen más sobre la migración que cualquier comprobación con curl hecha a medianoche y agotado.

Cerrada la ventana, cancela la cuenta compartida y el proyecto está terminado: la renovación automática de la tarjeta muere con ella, y el pago con diecinueve monedas significa que la próxima renovación es una factura que apruebas conscientemente. Desde aquí el ritmo es tuyo: parchea cada mes, restaura una copia a propósito cada trimestre y vuelve a ejecutar esta secuencia siempre que aparezca una segunda señal de la lista ordenada dentro de un mismo trimestre. La salida, hecha en este orden, es aburrida, que es el mayor elogio que puede recibir una migración.