VPS, hosting gestionado o servidor dedicado: qué está eligiendo en realidad en 2026

Desde fuera, los tres modelos parecen iguales: inicias sesión, ves un Linux prompt y ejecutas tu aplicación. Por debajo, el acuerdo que has firmado es muy diferente.

Con un VPS, alquilas una parte de una máquina física. El host físico y la capa de virtualización pertenecen al provider. Tú controlas el guest operating system y todo lo que está por encima. El límite exacto del kernel depende del modelo de virtualización, y eso importa cuando aparecen vulnerabilidades a nivel de kernel.

Con managed hosting, alquilas un resultado. El provider opera el operating system, el runtime, a menudo la base de datos y la mayor parte de las herramientas que lo rodean. Tú aportas la aplicación y el contenido. El control panel, cPanel, Plesk, DirectAdmin o uno propio, es la superficie visible. Pero el producto real es el equipo de operations que hay detrás.

Con un dedicated server, alquilas el hardware en sí. El operating system, el kernel, el storage layout y, a menudo, partes de la configuración de boot y remote management están bajo tu control. El límite exacto depende del provider y del contrato. El provider entrega energía, red, seguridad física y la capa managed acordada. El resto depende de ti, salvo que contrates además un managed dedicated tier.

Ninguno de estos modelos es mejor en abstracto. Son acuerdos distintos para trabajos distintos. El error que comete mucha gente no es elegir el modelo equivocado. Es tratar el modelo elegido como si fuera uno de los otros modelos.

Un VPS te da una máquina Linux a la que puedes acceder por SSH, costes mensuales previsibles, provisioning rápido y un operating system real para ejecutar workloads reales. Para la mayoría de sitios web en producción, herramientas internas, entornos de staging, APIs con menos tráfico y pequeños equipos SaaS, es la respuesta correcta, no un compromiso.

Lo que obtienes con un VPS:

• Root en tu propio operating system, con la libertad de instalar lo que necesites.
• Costes mensuales previsibles y en gran parte fijos.
• Provisioning en minutos en lugar de días, más la posibilidad de añadir o redimensionar instances cuando cambia la carga.
• Una línea clara de responsabilidad por encima de la capa de virtualización: todo lo que instalas, lo operas tú.

Lo que compartes con otros tenants:

• El host físico y la capa de virtualización. Cuando aparece una vulnerabilidad de host-level, el provider parchea el host. Dentro del guest, sigues parcheando tu propio operating system.
• Recursos físicos durante los picos. La mayoría de plataformas VPS gestionan esto bien, pero un noisy neighbor todavía puede aparecer como variabilidad en I/O latency o CPU steal time durante un pico de tráfico.
• El blast radius de un host compromise. Si el hypervisor o la capa de host se ven comprometidos, todos los tenants en ese host pueden entrar en scope.

Eso no es un argumento contra VPS. Es el trade-off que aceptaste: menor coste y menos responsabilidad sobre hardware, a cambio de una capa del stack que no controlas tú. El punto es saber qué trade-off has elegido, para operar la máquina en consecuencia.

En un VPS, tu responsabilidad de patching empieza dentro del guest operating system. Aplicas security updates, haces reboot cuando tu guest kernel lo necesita y vigilas la status page del provider para host-level maintenance que no puedes evitar. La Linux kernel-CVE que apareció a principios de mayo es el ejemplo más claro: cada VPS guest necesitaba atención dentro del operating system, mientras los providers también tenían que ocuparse de las capas de host y virtualización cuando aplicaba. El operator y el provider estaban juntos en el patch path.

Managed hosting es el modelo en el que el provider opera el servidor para que tú no tengas que hacerlo. En su forma clásica, con cPanel o Plesk control panel, servidor de correo compartido y one-click WordPress installer, este modelo absorbió a toda una generación de pequeñas empresas, agencias e indie developers que no querían ser sysadmins. Esa sigue siendo su promesa central: tú subes el sitio, el provider lo mantiene funcionando.

Lo que “managed” cubre exactamente varía por provider. Una checklist útil al evaluar uno:

• Operating system patching: ¿quién aplica los patches, con qué calendario y con qué rapidez cuando una CVE se añade a una lista de vulnerabilidades conocidas y explotadas activamente?
• Control-panel patching: ¿qué versiones se siguen, y cómo se gestiona un zero-day antes de que haya un upstream patch disponible?
• Backups: ¿con qué frecuencia se hacen, dónde se almacenan, cómo se inicia un restore y cómo se prueban los restores?
• Monitoring e incident response: ¿quién monitoriza qué, y cuál es el response time real ante un incidente confirmado?
• Límite de soporte: ¿dónde termina “managed” y dónde empieza “tu aplicación”?

La lectura honesta del managed hosting es que el valor está en el equipo de operations, no en el control panel. Dos providers pueden entregar el mismo software y operar productos completamente distintos encima. Uno tiene un SOC, un incident playbook documentado y un track record de parchear CVEs críticas el mismo día en que un exploit funcional se hace público. Otro tiene un helpdesk y un forum. Ambos venderán “managed hosting”. El trabajo de evaluación consiste en descubrir cuál de los dos estás comprando.

Lo que managed hosting hace muy bien, cuando eliges un operator serio: te quita de encima la carga administrativa diaria, te da un único punto de contacto cuando algo se rompe y convierte server operations en un coste mensual previsible en lugar de un sumidero de tiempo imprevisible. Eso es un producto real, y para muchos compradores es el producto correcto.

Donde se vuelve incómodo es cuando el límite no está claro. “Managed” no significa “aislado”. Si aparece una vulnerabilidad crítica de authentication bypass en el propio control panel, todos los servidores que ejecutan ese panel están expuestos hasta que el provider aplique el patch. El cliente no elige la patch window. Eso forma parte del acuerdo. La forma de convivir con ello es elegir un provider cuya patch cadence y hábitos de disclosure puedas auditar, no fingir que esa dependencia no existe.

Un dedicated server es el acuerdo más simple de los tres de explicar, y el más exigente de operar. El hardware está asignado a ti. No hay tenant al otro lado del hypervisor, porque no hay hypervisor salvo que tú pongas uno. No hay entorno guest compartido, no hay recursos físicos compartidos, no hay scheduling overhead de una capa de virtualización.

Eso significa que tienes control, o puedes contratar control, sobre:

• El operating system y el kernel, incluyendo decisiones de hardening que no siempre son posibles en entornos compartidos.
• El boot path y la configuración de plataforma, según el modelo del servidor y la política del provider.
• Out-of-band management access, idealmente con tráfico IPMI y BMC en una red de management separada que no sea accesible desde el internet público.
• Storage layout, configuración RAID y disk encryption keys.
• Patch timing. Cuando aparece una CVE crítica, tú decides cuándo hace reboot el servidor.

Esa última diferencia fue la que más importó durante el último mes. En una dedicated machine que tú operas, aplicar el kernel patch para una privilege-escalation CVE es una maintenance window que tú planificas. No esperas al host operator, no tienes un blast radius compartido y no hay un second-order outage porque el host hace reboot y tu guest reinicia con él.

El precio de ese control es la responsabilidad. Patching, monitoring, backups, incident response, capacity planning, salvo que compres un managed tier encima, todo eso depende de ti. Dedicated no es la respuesta correcta para un equipo que no tiene, o no quiere construir, una práctica real de operations. Es la respuesta correcta cuando tu workload realmente se beneficia de un stack ownership más profundo: carga base estable, rutas sensibles a latency, requisitos de aislamiento por policy o compliance, o un modelo de security en el que “el kernel es mío” es un requisito duro.

Si no tienes ninguno de esos drivers, dedicated es overhead. Si los tienes, es el único modelo que te da las palancas que necesitas.

En la práctica, las tres categorías se solapan de formas que las páginas comparativas no siempre dejan claras.

Existe managed VPS. También existe unmanaged dedicated. Igual que existe un dedicated server en el que tú mismo ejecutas un hypervisor y alquilas VPS slices a tenants internos. El nombre de la categoría te dice dónde empiezas. No te dice cuál es el acuerdo completo.

Tres preguntas cortan el marketing:

• ¿Quién controla el kernel? Si la respuesta es “tú”, controlas el guest kernel. Si la respuesta es “el provider”, dependes del provider para esa capa. La respuesta exacta depende del modelo de virtualización.
• ¿Quién aplica el patch? Recorre lo que pasa un sábado por la mañana cuando aparece una CVE crítica. ¿De quién suena el pager? ¿De quién se crea el change ticket?
• ¿De quién es tu blast radius? Si el host se ve comprometido, ¿entras tú en scope? Si el control panel se ve comprometido, ¿entras tú en scope? Las respuestas honestas aquí son más útiles que las listas de features.

Cuando puedes responder esas tres preguntas, puedes ignorar la mayor parte del ruido de las tablas comparativas. El producto que hay debajo tiene una forma, independientemente de la etiqueta que haya en la página de marketing.