VPS Linux: qué es, cómo funciona y qué distribución elegir

Cómo funciona un VPS Linux

El proveedor divide un servidor físico mediante un hipervisor. Con virtualización KVM, cada VPS ejecuta su propio kernel y permanece aislado de las otras máquinas virtuales. Al contratar eliges una imagen —por ejemplo Ubuntu o Debian— y el panel crea el disco, asigna recursos e inicia el sistema.

Después puedes conectarte por SSH, instalar paquetes y configurar servicios. A diferencia del hosting compartido, no dependes de un panel para decidir qué software está disponible. A cambio, debes aplicar actualizaciones, controlar accesos, vigilar recursos y mantener backups.

Qué puedes instalar

Un VPS Linux puede ejecutar Nginx, Apache, PHP, Node.js, Python, Java, Docker, PostgreSQL, MySQL, Redis, WireGuard y herramientas como n8n o Coolify. El límite práctico está en la compatibilidad, los recursos contratados y la capacidad para administrar el sistema.

Para una lista concreta consulta 15 usos reales de un VPS.

Ubuntu Server

Ubuntu Server ofrece versiones LTS con un ciclo de mantenimiento extenso, documentación abundante y gran compatibilidad con herramientas comerciales. Es una elección sencilla para el primer VPS, equipos que usan Ubuntu localmente y tutoriales de Docker, Kubernetes o automatización.

Su ritmo de actualización es más activo que Debian y algunos paquetes pueden incluir decisiones propias de Canonical. Conviene instalar una versión LTS, no una edición intermedia, para producción.

Debian

Debian prioriza la estabilidad y cambios conservadores. Su instalación mínima utiliza pocos recursos y es una base excelente para Nginx, bases de datos o contenedores. Muchas instrucciones escritas para Ubuntu se parecen, pero los repositorios, versiones y nombres de ciertos paquetes pueden variar.

Elige Debian si tu equipo lo conoce, buscas una base pequeña y prefieres versiones ampliamente probadas a novedades frecuentes.

AlmaLinux y Rocky Linux

Ambas distribuciones pertenecen al ecosistema compatible con Red Hat Enterprise Linux. Son habituales en empresas, paneles de hosting y entornos que usan SELinux, dnf y herramientas diseñadas para RHEL.

Son apropiadas si la aplicación o el panel exige esa familia. No conviene elegirlas únicamente porque “suenan empresariales”: Ubuntu o Debian pueden ser más fáciles si toda la documentación de tu proyecto usa apt.

Otras distribuciones

Fedora ofrece software reciente, pero un ciclo corto; Arch Linux entrega control y paquetes actuales, aunque exige mantenimiento frecuente. Para un servidor de producción, la previsibilidad suele importar más que disponer de la versión más nueva de cada paquete.

Comparación rápida

La comparación detallada entre las dos opciones más frecuentes está en Ubuntu vs Debian para VPS.

Cómo elegir correctamente

Empieza por los requisitos oficiales de la aplicación. Después valora experiencia del equipo, periodo de soporte, disponibilidad de paquetes y documentación. No elijas en función de una diferencia mínima de RAM: la operación diaria pesa más.

Si todavía no hay requisitos, Ubuntu LTS es la opción más fácil para aprender; Debian es excelente para una base sobria y estable. En ambos casos utiliza una versión con soporte vigente y evita una instalación que esté cerca del fin de mantenimiento.

Requisitos iniciales

Un sistema mínimo puede arrancar con 1 GB de RAM, pero la aplicación determina el tamaño real. Un sitio con base de datos o varios contenedores suele necesitar más margen. Consulta cuánta RAM necesita un VPS antes de elegir el plan.

En almacenamiento, separa el espacio del sistema, los datos, los logs y el margen requerido para actualizaciones y copias temporales. Un disco rápido no compensa quedarse sin espacio.

Primeros pasos después de instalarlo

Conéctate por SSH, verifica el sistema con cat /etc/os-release, actualiza los paquetes y sigue el checklist para asegurar Ubuntu. Configura usuarios, llaves SSH, firewall, monitoreo y backups antes de exponer la aplicación.

Los VPS KVM de Terranode permiten instalar varias distribuciones Linux desde el panel, reinstalar el sistema y acceder a una consola cuando la red no responde.

VPS Linux frente a hosting compartido

En un hosting compartido administras sitios dentro de las opciones del panel; el proveedor mantiene sistema, servidor web y parte de la seguridad. En un VPS Linux controlas la máquina: eliges paquetes, versiones, puertos y arquitectura. Esa libertad permite ejecutar una API, Docker o una VPN, pero también convierte las actualizaciones y copias en tu responsabilidad.

El salto tiene sentido cuando necesitas software no disponible en el hosting, aislamiento, una configuración particular o capacidad para varios servicios. No es una mejora automática para cualquier web. Si el sitio funciona bien y nadie puede administrar Linux, un servicio gestionado puede ser más eficiente que adquirir root y dejar el servidor sin mantenimiento.

Antes de migrar, enumera qué problema resuelve el VPS. “Tener más control” es demasiado abstracto; “usar una versión concreta de Node, ejecutar un worker y configurar colas” permite diseñar y verificar la nueva plataforma.

Qué entrega el proveedor y qué administras tú

El proveedor opera el hardware, hipervisor y conectividad. Tú administras el sistema huésped, usuarios, paquetes, aplicaciones y datos, salvo que el plan incluya gestión explícita. Un VPS que enciende y responde al ping puede tener la base caída, un certificado vencido o el disco lleno; esas capas ya pertenecen a la operación del cliente.

Aclara si el servicio incluye snapshots, backups, monitoreo, migración o soporte sobre aplicaciones. “Soporte 24/7” puede significar atender problemas del nodo, no corregir Nginx. Preguntar antes evita descubrir los límites durante una incidencia.

Guarda fuera del servidor las credenciales del panel, llaves de recuperación, inventario y procedimiento de restauración. La persona que recibe una alerta debe poder saber qué corre, dónde están los datos y qué acción es segura.

La distribución debe seguir a la aplicación

Empieza en la documentación oficial del software. Algunos paneles admiten solo determinadas versiones de AlmaLinux; una plataforma puede publicar paquetes para Ubuntu LTS y Debian; un producto comercial puede certificar una versión concreta. Elegir primero la distribución y forzar después la aplicación añade trabajo sin beneficio.

Cuando varias opciones están soportadas, decide por experiencia del equipo y ciclo de mantenimiento. Una versión con cinco años disponibles no ayuda si el equipo desconoce sus herramientas, pero una distribución familiar cerca del fin de soporte tampoco es buena base. Registra la fecha prevista de actualización desde el primer día.

No mezcles repositorios de familias distintas para conseguir un paquete. Si necesitas una versión que no existe en la distribución, usa el repositorio oficial del proyecto, un contenedor o reconsidera la imagen. Resolver dependencias a mano puede funcionar hoy y bloquear la próxima actualización.

Instalación mínima y superficie de ataque

Un servidor sin escritorio gráfico consume menos memoria y expone menos componentes. Instala solo lo que la aplicación necesita. Cada panel, agente y servicio adicional ocupa recursos, escucha en algún lugar o requiere parches. La comodidad debe justificar ese coste.

Después del aprovisionamiento, crea un usuario administrativo, configura llaves SSH y verifica una segunda sesión antes de cerrar la primera. Aplica firewall permitiendo únicamente puertos necesarios y conserva acceso a la consola del proveedor. Cambiar SSH, firewall y usuarios en una sola sesión sin prueba es una forma frecuente de bloquearse.

Actualiza el sistema y reinicia cuando el kernel lo requiera. Un servidor “estable” que nunca cambia acumula vulnerabilidades y hace que la actualización futura sea más riesgosa. Los cambios pequeños y regulares son más fáciles de revisar que años de paquetes pendientes.

El sistema de paquetes y sus repositorios

Ubuntu y Debian usan apt; AlmaLinux y Rocky Linux usan dnf. El gestor resuelve dependencias, verifica paquetes y registra actualizaciones. Descargar instaladores aleatorios con curl | bash entrega control del servidor a un script que quizá no has leído. Cuando un proyecto ofrezca un repositorio oficial, revisa su dominio, clave y versiones compatibles.

En Debian y Ubuntu, una revisión inicial puede hacerse así:

sudo apt update
apt list --upgradable
sudo apt upgrade

En la familia RHEL equivalente:

sudo dnf check-update
sudo dnf upgrade

Lee qué paquetes se eliminarán o reemplazarán, sobre todo en producción. Automatiza parches de seguridad cuando encaje, pero conserva un proceso para reinicios y cambios mayores. Un backup anterior y una prueba posterior forman parte de la actualización.

Usuarios, sudo y acceso remoto

Trabajar siempre como root aumenta el alcance de un error. Crea cuentas personales con sudo, usa llaves distintas por administrador y retira accesos al salir alguien del equipo. Compartir una clave impide saber quién se conectó y obliga a reemplazarla para todos cuando se filtra.

La llave privada permanece en el equipo del usuario; el servidor guarda solo la pública. Protege la privada con frase de paso y conserva un método de recuperación. Antes de desactivar contraseñas, abre otra sesión con la llave y confirma sudo. La guía de llaves SSH y autenticación desarrolla este cambio sin perder acceso.

Revisa periódicamente authorized_keys, grupos administrativos e inicios de sesión. No expongas paneles o bases de datos a Internet para evitar un túnel SSH: la comodidad puntual crea una superficie permanente.

Servicios y registros con systemd

La mayoría de distribuciones actuales usa systemd para iniciar y supervisar servicios. Aprende a distinguir “proceso iniciado” de “aplicación sana”. systemctl status muestra estado y eventos recientes; journalctl permite revisar logs por unidad y periodo.

sudo systemctl status nginx
sudo journalctl -u nginx --since '30 minutes ago'
sudo systemctl list-units --type=service --state=failed

Después de cambiar una configuración, valida su sintaxis con la herramienta del servicio antes de recargar. Para Nginx es nginx -t; otras aplicaciones tienen comandos propios. Reiniciar a ciegas puede convertir un error de texto en una caída.

Configura rotación y vigila el espacio. Los logs son evidencia durante una incidencia, pero sin retención pueden llenar el disco. Borrarlos manualmente resuelve el síntoma y destruye la información que explica la causa.

Desplegar aplicaciones directamente o con Docker

Instalar runtimes y servicios en el sistema reduce capas y puede ser sencillo para una sola aplicación. Docker empaqueta dependencias, facilita reproducir versiones y separa proyectos, pero añade redes, volúmenes e imágenes que deben mantenerse. No elijas contenedores solo porque aparecen en todos los tutoriales.

Si usas Docker, los datos persistentes deben vivir en volúmenes o rutas definidas; eliminar un contenedor no debe eliminar pedidos ni archivos. Fija versiones de imágenes, limita exposición de puertos y planifica actualizaciones. Docker no reemplaza firewall ni backup.

Para varias aplicaciones, un proxy inverso puede recibir HTTPS y dirigir por dominio. Documenta puertos internos y evita publicar cada servicio directamente. La guía de Docker en un VPS cubre instalación y operación inicial.

Bases de datos en el mismo VPS

Una base local evita latencia de red y simplifica una plataforma pequeña. Escucha solo en localhost o red privada si ninguna máquina externa debe acceder. Crea usuarios por aplicación con privilegios mínimos; no uses la cuenta administrativa en archivos de configuración.

La memoria de la base compite con la aplicación. Ajusta buffers y conexiones según la RAM disponible, no según una plantilla para servidores grandes. Activa registro de consultas lentas cuando investigues rendimiento y controla el crecimiento de tablas.

Los backups deben ser coherentes con el motor. Copiar sus archivos en caliente no siempre produce una restauración válida. Genera volcados o usa herramientas compatibles, guarda una copia externa y ensaya importar en otra instancia.

Elegir tamaño de CPU, RAM y disco

El sistema base puede ser ligero, pero no dimensiona la aplicación. Suma workers, base, caché y tareas de mantenimiento. Conserva memoria disponible para picos y espacio en disco para actualizaciones, logs y una restauración temporal. La swap ofrece margen; no convierte un plan pequeño en uno suficiente.

La CPU importa para PHP, compilación, cifrado y procesamiento. El disco afecta bases, contenedores y muchas operaciones pequeñas. La región influye en latencia. Evita resolver todos los problemas aumentando una sola cifra: mide cuál recurso se agota durante el flujo lento.

Empieza con un tamaño razonable y define señales de escalamiento. “Ampliar cuando memoria disponible caiga repetidamente y haya OOM” es mejor que esperar a que los usuarios reporten una caída.

Backups que permiten reconstruir el servidor

No necesitas copiar cada archivo del sistema si puedes reinstalar paquetes. Prioriza base de datos, archivos subidos, configuración, secretos y manifiestos de despliegue. Guarda también un inventario de versiones y tareas programadas; sin él una restauración puede arrancar incompleta.

Una copia en el mismo disco solo ayuda frente a un borrado puntual. Mantén otra fuera del VPS y, si el servicio es crítico, fuera de la región. Cifra los secretos y limita quién puede borrar la copia. La frecuencia depende de cuánto dato puedes perder, no de una regla diaria universal.

Restaura en un entorno de prueba. Abrir el archivo no demuestra que la base importe, que las credenciales funcionen y que la aplicación responda. Registra tiempo y pasos: el objetivo es convertir una emergencia futura en un procedimiento conocido.

Monitoreo útil desde el primer día

Supervisa disponibilidad desde fuera, uso de CPU, memoria disponible, disco, errores y caducidad de certificados. Añade métricas propias del servicio: cola pendiente, consultas lentas, webhooks fallidos o pedidos sin procesar. Un gráfico verde de CPU no sirve si el checkout falla.

Define alertas con acción. Una advertencia de disco debe indicar qué revisar y a quién corresponde. Evita umbrales tan sensibles que el equipo aprenda a ignorarlos. Primero registra una línea base y ajusta a la variación normal.

Después de un despliegue, observa métricas y logs aunque la página abra. Los fallos en cron, correo o trabajos asíncronos aparecen después y no se ven en una prueba superficial.

Una ruta práctica para tu primer VPS Linux

Elige una versión soportada por la aplicación, despliega una imagen mínima y actualízala. Crea acceso individual por llave, prueba sudo y restringe el firewall. Instala el runtime, servidor web y base solo cuando corresponda. Configura HTTPS, backups y monitoreo antes de dirigir tráfico.

Prueba una restauración y documenta el sistema: distribución, plan, región, dominios, servicios, puertos, rutas de datos y contactos. Programa revisiones de paquetes y capacidad. Esta ruta no exige convertirse en experto antes de empezar; exige no dejar invisibles las responsabilidades.

Si la operación supera el tiempo o conocimiento del equipo, contrata administración o usa una plataforma gestionada. Elegir Linux no obliga a resolver cada incidente solo, pero sí a decidir quién lo hará.

Kernel, reinicios y actualizaciones en un VPS Linux

Actualizar paquetes no siempre completa la corrección: una biblioteca puede quedar reemplazada en disco mientras los procesos conservan la copia antigua en memoria, y un kernel nuevo no entra en uso hasta reiniciar. En un VPS recién instalado conviene aplicar todas las actualizaciones antes de desplegar la aplicación; en producción necesitas una ventana, una verificación posterior y una forma de volver a levantar el servicio automáticamente.

Después de actualizar, comprueba el kernel en ejecución y si Ubuntu solicita reinicio:

uname -r
test -f /var/run/reboot-required && cat /var/run/reboot-required
systemctl --failed

Un reinicio planificado también prueba supuestos operativos. Nginx, la base, contenedores y procesos supervisados deben iniciar sin una sesión SSH abierta. Ejecuta la prueba mientras todavía conservas la consola del proveedor y confirma la ruta pública, una operación de datos y los trabajos de fondo. Si la aplicación solo vuelve cuando alguien escribe un comando a mano, el despliegue no está terminado.

Las actualizaciones automáticas de seguridad reducen la exposición, pero no eliminan la necesidad de revisar cambios incompatibles en repositorios externos o aplicaciones. Define qué paquetes se actualizan automáticamente, dónde quedan los logs y quién atiende un reinicio pendiente. En servicios con varias máquinas puedes rotar nodos; en un único VPS debes acordar una ventana de mantenimiento y comunicarla según el impacto real.

Sistema de archivos, inodos y crecimiento del disco

El porcentaje de gigabytes libres no cuenta toda la historia. Linux almacena cada archivo en un inodo; millones de sesiones, archivos temporales o cachés pequeñas pueden agotar inodos aunque df -h muestre espacio. También es posible llenar el disco con un archivo de log borrado que un proceso todavía mantiene abierto.

df -hT
df -ih
sudo du -xhd1 /var | sort -h
sudo lsof +L1

du suma archivos visibles, mientras df refleja bloques ocupados por el sistema de archivos. Una diferencia grande entre ambos puede señalar archivos eliminados aún abiertos. Reiniciar el proceso correcto libera el descriptor; borrar más rutas al azar puede eliminar evidencia o datos sin resolver el consumo original.

Antes de instalar, separa conceptualmente datos reconstruibles de datos únicos. Cachés, paquetes y artefactos de build pueden recrearse; bases, archivos subidos y secretos necesitan backup. Montar un volumen adicional para datos facilita ampliar o trasladar almacenamiento, pero exige documentar el montaje en /etc/fstab, permisos y orden de arranque. Usa identificadores estables como UUID cuando corresponda y prueba un reinicio antes de guardar información importante.

Para crecer, confirma si el proveedor amplió primero el disco virtual y luego extiende partición, volumen y sistema de archivos con el procedimiento compatible. No ejecutes una orden de redimensionado tomada de otra guía sin identificar si usas particiones tradicionales, LVM, ext4 o XFS. Realiza un snapshot o backup recuperable, conserva consola y verifica tamaño y salud al terminar.

Elegir entre instalación directa y contenedores desde la operación

Docker no convierte automáticamente un VPS Linux en más seguro ni más sencillo. Aísla dependencias y hace reproducible el empaquetado, pero añade redes, volúmenes, imágenes y reglas de publicación que también debes entender. Una aplicación única con paquetes bien soportados puede funcionar de forma excelente como servicio systemd; varias aplicaciones con versiones incompatibles suelen beneficiarse de contenedores.

La decisión práctica depende de cómo vas a actualizar y recuperar. En instalación directa debes poder reconstruir paquetes, usuarios, configuración y unidades. Con contenedores necesitas conservar Compose, variables, secretos y volúmenes, fijar versiones de imagen y ensayar la restauración. En ambos casos, los datos deben vivir fuera del artefacto reemplazable y los procesos deben volver después de reiniciar.

No mezcles gestores sin una razón: ejecutar una aplicación con systemd y, a la vez, con PM2 o un contenedor puede crear dos instancias compitiendo por el mismo puerto. Elige una autoridad para el ciclo de vida de cada proceso y documenta dónde consultar su estado y sus logs.