Qué es un VPS: arquitectura, virtualización (LXC, KVM) y casos de uso

Un VPS, abreviatura de Virtual Private Server o servidor virtual privado, es una porción aislada de un servidor físico configurada como si fuera un servidor independiente. El usuario obtiene acceso administrativo (root en sistemas Linux, Administrator en Windows), recursos asignados de forma garantizada, una dirección IP propia y la libertad de instalar el sistema operativo y el software que prefiera. La pieza que hace posible esa abstracción es la virtualización, una capa de software que permite ejecutar varios sistemas independientes sobre un mismo hardware sin que se interfieran entre sí.

El concepto cubre un rango amplio de escenarios. Desde alojar un sitio WordPress que excedió las capacidades de un hosting compartido, hasta operar un cluster de microservicios, pasar por servidores de aplicaciones, bases de datos dedicadas, servicios de correo, instancias de juegos, túneles VPN, infraestructura de desarrollo y sistemas de monitoreo. La versatilidad explica por qué el servicio de VPS es uno de los productos más utilizados del segmento de hosting, ubicándose entre el hosting compartido (más barato y limitado) y el servidor dedicado (más caro y con hardware completo).

Cómo se construye el aislamiento entre VPS

Un servidor físico moderno tiene capacidad de cómputo, memoria y almacenamiento que excede largamente las necesidades de un solo proyecto típico. La virtualización permite repartir esa capacidad en porciones independientes, cada una vista por sus usuarios como un servidor completo. La forma técnica de esa repartición define las dos grandes familias de tecnología sobre las que se construyen los VPS comerciales en 2026.

La primera familia es la virtualización completa mediante hipervisor. Un hipervisor es un software que actúa como capa intermedia entre el hardware físico y los sistemas operativos virtualizados. Cada instancia virtual ejecuta su propio kernel completo, su propia tabla de procesos, su propia gestión de memoria, sus propias tablas de red. El hipervisor presenta hardware emulado o paravirtualizado a cada instancia, y reparte el acceso al hardware real. La instancia, en términos prácticos, no sabe que es virtual.

La segunda familia es la virtualización a nivel de sistema operativo mediante contenedores. En lugar de ejecutar un kernel completo por instancia, el sistema host ejecuta un único kernel y aísla los procesos de cada instancia mediante namespaces, cgroups y límites de recursos. Cada contenedor ve solo sus propios procesos, su propia red virtual, su propio sistema de archivos, pero comparte el kernel del host. La instancia se entera de que es contenedor cuando intenta operaciones que requerirían control sobre el kernel.

Ambas familias entregan un VPS funcional. La diferencia entre ellas explica buena parte de las decisiones de mercado y de las restricciones que un usuario puede encontrar.

KVM: virtualización completa por hipervisor

KVM (Kernel-based Virtual Machine) es la implementación de hipervisor tipo 1 integrada al kernel Linux desde 2007. Junto con QEMU para emulación de dispositivos, KVM convierte un servidor Linux en hipervisor capaz de ejecutar máquinas virtuales completas. Es la tecnología que está detrás de la mayoría de los VPS llamados "VPS KVM" en el mercado, y es también la base de productos de virtualización empresarial como Proxmox VE y oVirt.

Lo que un VPS KVM entrega:

• Kernel propio. Cada VPS ejecuta su propio kernel Linux (o Windows, FreeBSD, OpenBSD, lo que se decida instalar). El usuario puede actualizar el kernel, cargar módulos, modificar parámetros de sysctl que en otra tecnología no estarían accesibles.
• Sistema operativo elegible. Cualquier ISO bootable se puede instalar. Ubuntu Server, Debian, AlmaLinux, Rocky, openSUSE, Windows Server, FreeBSD, distribuciones especializadas (pfSense para firewall, OPNsense, Mikrotik RouterOS) son opciones reales.
• Aislamiento de seguridad fuerte. Una vulnerabilidad dentro de un VPS no afecta a los demás VPS del mismo host porque no comparten kernel ni espacio de memoria.
• RAM y vCPU dedicadas. El hipervisor reserva recursos específicos para cada VM. Hay overhead de virtualización (un par de puntos porcentuales) pero la asignación es estricta.
• Capacidades de red avanzadas. Soporte completo de raw sockets, iptables/nftables sin restricciones, configuración de interfaces a nivel kernel, capacidad de actuar como router o firewall.
• Hibernación, snapshot y migración en vivo. Funciones del hipervisor que permiten pausar la VM, tomar imágenes consistentes y mover una VM en operación entre hosts físicos.

El costo es overhead. Un VPS KVM consume más recursos del host por instancia que un contenedor equivalente. Para el proveedor, esto se traduce en menos VPS por servidor físico. Para el usuario, en precio levemente superior frente a contenedores comparables.

LXC: virtualización por contenedores del sistema

LXC (Linux Containers) es la tecnología de contenedores nativos del kernel Linux. A diferencia de Docker, que orienta los contenedores hacia ejecución de procesos individuales (un contenedor = una aplicación), LXC opera contenedores como sistemas completos: dentro corre systemd, hay procesos múltiples, se inician servicios al boot, se administra como si fuera un servidor.

Lo que un VPS LXC entrega:

• Aislamiento de procesos, red, sistema de archivos y usuarios. Cada contenedor ve un mundo coherente y separado del host y de los demás contenedores.
• Sistema de archivos propio. El usuario tiene root dentro del contenedor, instala paquetes, configura servicios, opera como en cualquier servidor.
• Distribuciones Linux como elección. Cualquier distribución Linux moderna puede ejecutarse en LXC. Plantillas oficiales cubren las principales: Ubuntu, Debian, AlmaLinux, Rocky, Alpine, Arch, Fedora.
• Eficiencia de recursos. Como no hay kernel separado por contenedor, la densidad por servidor físico es alta. Esto se traduce en precios más competitivos en el segmento bajo del mercado VPS.
• Inicio rápido. Crear, arrancar, detener, recrear un contenedor LXC es operación de segundos. Las VMs KVM toman minutos.

El costo es que algunas operaciones que requieren control del kernel no funcionan dentro de un contenedor LXC compartido. Cargar módulos del kernel, modificar parámetros sysctl que afecten al host, ejecutar Docker dentro del contenedor sin configuración adicional, manipular reglas de tráfico a bajo nivel, son tareas restringidas o que requieren configuración explícita del proveedor. Para la mayoría de las cargas web (servidor de aplicaciones, base de datos, cache, mail) las restricciones no son problema. Para cargas que necesitan kernel propio, sí lo son.

Comparación entre los dos modelos

Característica	VPS LXC	VPS KVM
Tipo de virtualización	Contenedor del sistema	Máquina virtual completa
Kernel	Compartido con el host	Propio por instancia
Sistemas operativos	Solo Linux	Linux, Windows, BSD, otros
Densidad por servidor físico	Alta	Media
Overhead por instancia	Mínimo	Bajo a medio (2–5%)
Tiempo de creación/inicio	Segundos	Minutos
Aislamiento de seguridad	Fuerte (namespaces + cgroups)	Muy fuerte (hardware-assisted)
Carga de módulos del kernel	Restringida	Sin restricciones
Docker anidado	Posible con configuración	Trivial
Costo típico de mercado	Más bajo	Levemente superior
Casos típicos	Web, mail, app servers, microservicios	Cargas con kernel custom, Windows, virtualización anidada

El planteamiento práctico es más simple de lo que sugiere la matriz: para el 80% de las cargas habituales (alojar sitios web, correr aplicaciones PHP/Node/Python, servir bases de datos relacionales, proveer cache y servicios HTTP), un VPS LXC bien dimensionado entrega lo necesario y a mejor precio. Para el 20% que requiere control del kernel, sistema operativo distinto a Linux, o pruebas de virtualización dentro del propio servidor, KVM es la elección obligada.

Qué recursos se entregan en un VPS típico

Independiente del modelo de virtualización, un plan VPS comercial estándar especifica al menos cinco variables que conviene comprender:

• RAM (memoria). Memoria asignada al VPS, en gigabytes. Determina cuántos procesos concurrentes pueden ejecutarse y cuánto cache aplicativo se puede mantener. Para WordPress típico, 2 GB es punto de partida razonable; para aplicaciones más pesadas, 4–8 GB.
• vCPU (núcleos virtuales). Capacidad de cómputo asignada. Un vCPU en un proveedor de calidad equivale aproximadamente a un núcleo físico bajo carga moderada. La cantidad de vCPUs limita el paralelismo: para sitios estáticos, 1 vCPU sobra; para aplicaciones con muchos workers concurrentes, 2 a 4.
• Almacenamiento. Espacio en disco, hoy típicamente NVMe SSD en proveedores serios, ocasionalmente SATA SSD en planes muy económicos, raramente HDD mecánico. Para sitios web típicos 20–40 GB es suficiente; para servidores con bases de datos crecientes o archivos pesados, se escala según el caso.
• Transferencia mensual. Volumen total de datos que el VPS puede enviar al exterior por mes. Sitios chicos rara vez exceden los 100 GB mensuales; e-commerce con tráfico medio puede llegar a 500 GB; servicios de media o descargas requieren TB.
• IP dedicada. Dirección pública asignada al VPS. Algunos proveedores permiten agregar IPs adicionales por costo extra. Los servicios de correo, en particular, requieren IP dedicada con buena reputación para que los mensajes no caigan en spam.

Otras variables que conviene revisar al elegir: el ancho de banda del enlace de red (1 Gbps simétrico es estándar moderno; 10 Gbps en planes superiores), la disponibilidad de IPv6 nativa, la geografía del datacenter (relevante para latencia hacia los usuarios y para residencia de datos), la presencia de respaldos automáticos y la política de SLA del proveedor.

A quién va dirigido un VPS

El VPS no es para todos los proyectos. Hay perfiles claros donde aporta y otros donde es overkill o subóptimo.

Aporta cuando:

• Un sitio creció más allá de las capacidades de un hosting compartido (lentitud, errores 500 en horas pico, restricciones de plugins).
• El proyecto requiere instalar software que el hosting compartido no permite (binarios custom, servicios de fondo, daemons, lenguajes o versiones específicas).
• Se necesitan múltiples sitios o subdominios con configuraciones independientes y aislamiento entre ellos.
• El equipo técnico tiene capacidad de administración Linux y quiere control sobre la configuración.
• Se buscan recursos garantizados para cargas que no toleran la "vecindad ruidosa" del hosting compartido.
• Se requiere IP dedicada con reputación propia para servicios de correo o aplicaciones que verifican geolocalización.
• Se desarrollan microservicios, APIs, sistemas que se beneficien de aislamiento y de root.
• Se opera infraestructura de desarrollo: staging, CI runners, herramientas internas de equipo.

No es la mejor opción cuando:

• El sitio es chico, estático o de bajo tráfico, sin necesidades de configuración custom. Un hosting compartido bien gestionado es más barato y más sencillo.
• El equipo no tiene capacidad técnica de administración Linux y no quiere contratar gestión externa. Un VPS no administrado es responsabilidad del usuario y requiere conocimiento real.
• El proyecto requiere cómputo masivo, redundancia geográfica automática y autoescalado granular. Un solo VPS no es suficiente; convendría infraestructura cloud con servicios gestionados.
• El proyecto requiere hardware completo dedicado, certificaciones físicas, o cargas que saturarían un servidor entero. Un servidor dedicado es la categoría correcta.

Cuándo conviene VPS frente a hosting compartido y servidor dedicado

Las tres categorías cubren rangos distintos del espectro de necesidades:

Variable	Hosting compartido	VPS	Servidor dedicado
Recursos	Compartidos sin garantía	Asignados con garantía	Hardware físico completo
Acceso al sistema	Limitado al panel y FTP	Root completo	Root completo
Personalización del SO	No disponible	Total dentro del modelo de virtualización	Total
Aislamiento de vecinos	Bajo (vecindad puede afectarte)	Alto (recursos dedicados)	Total (sin vecinos)
Costo mensual referencial	$3.000 – $20.000 CLP	$8.000 – $100.000 CLP	$80.000 – $500.000 CLP
Conocimiento técnico requerido	Bajo	Medio a alto	Alto
Escenario típico	Sitio personal, blog, pyme con tráfico moderado	Aplicaciones, e-commerce activo, infraestructura de desarrollo	Servicios de alta carga, redundancia, requisitos físicos

El paso de hosting compartido a VPS suele tener un disparador concreto: el sitio empieza a fallar en hora pico, el panel restringe instalación de algo necesario, o aparecen requisitos (correo dedicado, IP propia, configuración custom) que no caben en compartido. El paso de VPS a servidor dedicado es menos frecuente y suele venir cuando un solo proyecto justifica el uso completo de un servidor: cargas de tamaño grande, requisitos de uptime altos con redundancia local, o necesidades de hardware específico.

Stack típico que se ejecuta sobre un VPS

Para dimensionar lo que un VPS puede contener, conviene listar combinaciones habituales:

• Sitio WordPress autónomo. Nginx o Apache con PHP-FPM, MariaDB o MySQL, Redis para cache, Certbot para SSL automático. 2 GB RAM, 1–2 vCPU bastan para sitios con tráfico moderado.
• Aplicación Node.js o Python. Node con PM2, o Python con Gunicorn/Uvicorn detrás de Nginx como reverse proxy. Base de datos PostgreSQL o MySQL local. Redis para cache y colas. 2–4 GB RAM según concurrencia esperada.
• E-commerce con Magento, PrestaShop o WooCommerce activo. Stack PHP optimizado, Redis para cache de sesiones y datos, Elasticsearch o Meilisearch para búsqueda, OPcache habilitado, MySQL/MariaDB con tuning. 4–8 GB RAM, 2–4 vCPU.
• Servidor de correo con dominio propio. Postfix + Dovecot + SpamAssassin, certificados Let\'s Encrypt, registros DKIM/DMARC/SPF en DNS. IP dedicada con reputación gestionada. 2 GB RAM suficiente para volumen empresarial pequeño.
• Servidor de juegos. Minecraft, ARK, CS, Rust, FiveM. Recursos según el juego: 4–16 GB RAM, vCPU con buena performance single-thread (los juegos suelen escalar mal en multi-thread).
• Servidor VPN privado. WireGuard u OpenVPN sobre Linux. Recursos modestos: 1 vCPU y 1 GB RAM bastan para uso personal o equipo chico.
• CI runner o ambiente de staging. GitLab Runner, GitHub Actions self-hosted, Drone, infraestructura de desarrollo del equipo. RAM y vCPU según volumen de jobs concurrentes.
• Cluster de microservicios pequeño. Docker Compose o k3s sobre un VPS con suficientes recursos. Útil para etapas tempranas antes de escalar a infraestructura distribuida.

Cómo elegir un VPS sin equivocarse

Reducido a las decisiones que efectivamente importan, elegir un VPS se resuelve respondiendo seis preguntas:

1. ¿Necesitas Windows o cargas que requieran kernel propio? Si sí, KVM. Si no, LXC ofrece mejor relación precio/recursos.
2. ¿Cuánta RAM y vCPU requiere realmente tu aplicación? Sobredimensionar es desperdicio; subdimensionar es problemas en producción. Una prueba de carga en staging antes de elegir suele ahorrar dos o tres iteraciones.
3. ¿Dónde están tus usuarios? Para audiencia chilena, datacenter en Chile o cercano (Brasil, Argentina) es preferible por latencia. Datacenters en US o Europa agregan 100–200 ms a cada request.
4. ¿Necesitas administración del proveedor o gestionas tú mismo? Un VPS no administrado es más barato pero exige conocimiento real de Linux y políticas de respaldo que tú implementas. Un VPS administrado quita esa carga a costo mayor.
5. ¿Qué nivel de uptime necesitas? Para sitios donde la caída de unas horas es tolerable, un VPS estándar es suficiente. Para sistemas que no pueden caer, se requieren redundancia activa, replicación y arquitecturas distribuidas, que exceden el alcance de un solo VPS.
6. ¿Qué historial tiene el proveedor? Tiempo en el mercado, transparencia operativa, calidad del soporte y políticas claras de respaldo y restauración. La opción más barata sin track record suele costar más en la primera caída que el ahorro acumulado.

El VPS de MOX Networks opera con virtualización tanto LXC como KVM según el plan, datacenter en Chile, IP dedicada incluida en todos los planes y soporte en español. Para casos donde la decisión entre los dos modelos no es evidente, el equipo puede recomendar la opción que se ajusta al perfil específico del proyecto.

Si la pregunta inicial era simplemente qué es un VPS, la respuesta es la versión corta de todo lo anterior: una porción virtualizada de un servidor físico que el usuario opera como si fuera un servidor propio, con recursos garantizados, root y libertad de configuración, ubicado en un punto medio del espectro entre el hosting compartido (más barato pero limitado) y el servidor dedicado (más caro pero con hardware completo). La pregunta de fondo —cuál VPS específico elegir— se responde mejor con las seis preguntas anteriores que con cualquier comparativa genérica.

Publicado por MOX Networks. La información técnica sobre virtualización LXC y KVM se basa en la documentación oficial del Kernel Linux, en la documentación de Proxmox VE y en la práctica operativa interna sobre infraestructura propia.