Cuando una página empieza a crecer, una de las recomendaciones que aparece constantemente es:
“Pásate a un VPS.”
A veces se presenta como si fuese el siguiente paso obligatorio después de un hosting compartido.
Pero no siempre lo es.
Un VPS puede proporcionar más control, recursos y posibilidades de configuración, pero también puede aumentar bastante la complejidad si tenemos que administrarlo nosotros mismos.
Por eso antes de contratar uno conviene entender qué es realmente un VPS, qué ventajas tiene y cuándo merece la pena utilizarlo.
¿Qué es un VPS?
VPS significa Virtual Private Server, o servidor privado virtual.
Simplificando bastante, un servidor físico puede dividirse mediante virtualización en diferentes servidores virtuales independientes.
Cada VPS puede disponer de determinados recursos y ejecutar su propio sistema operativo.
Conceptualmente podríamos imaginar:
Servidor físico
→ VPS 1
→ VPS 2
→ VPS 3
→ VPS 4
Cada VPS funciona como un entorno separado.
Esto permite disponer de bastante más control que en muchos planes de hosting compartido sin necesidad de contratar una máquina física completa.
La categoría de VPS en DSForo está precisamente destinada a compartir dudas, configuraciones y experiencias sobre este tipo de servidores.
VPS no significa servidor físico exclusivo
Esta diferencia es importante.
Cuando contratamos un VPS normalmente no estamos alquilando toda la máquina física.
Estamos contratando un entorno virtual que utiliza parte de los recursos de una infraestructura mayor.
Dependiendo del proveedor y la tecnología empleada podemos tener diferentes niveles de aislamiento y asignación de recursos.
Por eso no asumiría que:
VPS = servidor dedicado.
Son modelos diferentes.
¿Qué diferencia hay entre hosting compartido y VPS?
En un hosting compartido el proveedor suele encargarse de gran parte de la infraestructura.
Normalmente recibimos un panel donde podemos:
- Añadir dominios.
- Crear bases de datos.
- Instalar WordPress.
- Crear cuentas de correo.
- Configurar SSL.
- Gestionar archivos.
No necesitamos saber demasiado sobre el sistema operativo que existe por debajo.
En un VPS podemos tener mucho más control.
Dependiendo del servicio podremos administrar:
- Sistema operativo.
- Servidor web.
- PHP.
- Base de datos.
- Firewall.
- Usuarios.
- Servicios.
- Logs.
- Backups.
- Actualizaciones.
Eso puede ser una ventaja enorme.
Pero también significa que alguien tiene que ocuparse de todo ello.
Más control implica más responsabilidad
Este es probablemente el punto que más olvidamos cuando vemos una oferta de VPS barata.
Un proveedor anuncia:
4 CPU
8 GB RAM
160 GB NVMe
por un precio muy atractivo.
Y pensamos:
¿Cómo voy a pagar más por un hosting compartido si este VPS tiene muchísimo más?
La comparación no siempre es directa.
En el hosting compartido podemos estar pagando también por:
- Administración.
- Panel.
- Seguridad.
- Backups.
- Actualizaciones.
- Soporte.
- Configuración.
- Mantenimiento.
En un VPS no administrado muchas de esas responsabilidades pasan a nosotros.
¿Qué es un VPS administrado?
Un VPS administrado incluye algún nivel de gestión por parte del proveedor.
Pero hay que leer exactamente qué significa administrado en cada empresa.
Puede incluir aspectos como:
- Actualizaciones del sistema.
- Configuración del servidor web.
- Monitorización.
- Copias de seguridad.
- Ayuda ante incidencias.
- Seguridad básica.
- Gestión del stack.
Otro proveedor puede utilizar la misma palabra ofreciendo bastante menos.
Antes de contratar preguntaría:
¿Qué tareas realiza exactamente el proveedor y cuáles me corresponden a mí?
¿Qué es un VPS no administrado?
En un VPS no administrado recibimos normalmente el servidor y somos responsables de buena parte de su gestión.
Podemos tener acceso administrativo y libertad para instalar prácticamente lo que necesitemos.
Eso resulta fantástico para alguien que sabe administrar sistemas.
Para alguien que nunca ha utilizado Linux puede convertirse en una fuente de problemas.
El acceso root no arregla automáticamente nada
Tener acceso root significa disponer de privilegios administrativos muy elevados.
Podemos instalar software, modificar configuraciones y controlar prácticamente todo el sistema.
También podemos:
- Romper la red.
- Eliminar archivos críticos.
- Bloquearnos el acceso.
- Dejar servicios expuestos.
- Romper permisos.
- Desconfigurar el servidor web.
Por eso no consideraría el acceso root simplemente como:
una funcionalidad premium.
Es una herramienta muy potente que requiere cuidado.
¿Para qué sirve un VPS?
Un VPS puede utilizarse para muchísimas cosas.
Por ejemplo:
- Alojar páginas web.
- Instalar WordPress.
- Ejecutar aplicaciones PHP.
- Alojar APIs.
- Ejecutar aplicaciones Node.js.
- Bases de datos.
- Bots.
- Automatizaciones.
- Herramientas internas.
- Entornos de desarrollo.
- Paneles.
- Servicios privados.
- Servidores de juegos, cuando el proveedor y recursos lo permitan.
La ventaja principal es la flexibilidad.
No estamos limitados únicamente a las funcionalidades ofrecidas por un panel de hosting tradicional.
¿Necesito un VPS para WordPress?
No necesariamente.
Este es uno de los errores más habituales.
Una instalación WordPress pequeña puede funcionar perfectamente en un buen hosting compartido.
De hecho, un hosting compartido bien administrado puede ofrecer mejor rendimiento que un VPS mal configurado.
Antes de migrar a un VPS porque WordPress está lento, comprobaría primero si el problema realmente está en la infraestructura.
Ya tenemos una guía sobre cómo elegir un buen hosting para una página web donde se explican aspectos como CPU, RAM, límites, backups y escalabilidad.
Un VPS puede ser peor que un hosting compartido
Parece contradictorio, pero puede ocurrir perfectamente.
Imaginemos:
Hosting compartido
configurado por profesionales, con caché, backups, seguridad y servidor optimizado.
Frente a:
VPS
instalado por alguien que nunca ha administrado Linux, sin caché, con mala configuración de PHP y una base de datos sin optimizar.
¿Cuál será más rápido?
No podemos responder únicamente mirando:
VPS vs compartido.
La configuración importa muchísimo.
¿Cuándo empieza a tener sentido un VPS?
Hay varias situaciones donde puede resultar interesante.
Una de ellas es necesitar más control técnico.
Por ejemplo, queremos instalar una tecnología que nuestro hosting no admite.
También puede interesarnos cuando necesitamos controlar:
- Versiones concretas.
- Servicios.
- Configuraciones.
- Procesos.
- Puertos.
- Recursos.
- Automatizaciones.
En ese momento un VPS empieza a ofrecer una flexibilidad que un alojamiento compartido puede no proporcionar.
Cuando necesitamos recursos más previsibles
En algunos entornos compartidos los recursos disponibles dependen bastante de las políticas del proveedor y de cómo distribuye su infraestructura.
Un VPS puede ofrecer una asignación más clara de recursos según el plan.
Por ejemplo:
- Determinadas vCPU.
- Determinada RAM.
- Determinado almacenamiento.
Eso puede facilitar la planificación.
Pero hay que entender qué significa exactamente cada recurso.
¿Qué es una vCPU?
Una vCPU representa capacidad de procesamiento virtual asignada a nuestra máquina virtual.
No asumiría que:
4 vCPU de proveedor A = 4 vCPU de proveedor B.
El rendimiento depende de:
- Hardware físico.
- Generación del procesador.
- Virtualización.
- Frecuencia.
- Contención.
- Política del proveedor.
Las cifras comerciales sirven para orientarnos, pero no describen completamente el rendimiento.
¿Cuánta RAM necesita un VPS?
Depende totalmente del proyecto.
Un servidor que ejecuta:
- Nginx.
- PHP.
- Base de datos.
- Redis.
- Panel.
- Antivirus.
- Monitorización.
consume memoria incluso antes de atender tráfico.
Una aplicación sencilla puede funcionar con pocos recursos.
Otra puede necesitar bastante más.
No elegiría RAM basándome únicamente en:
Tengo 100.000 visitas, necesito X GB.
El tipo de aplicación importa muchísimo.
WordPress no consume lo mismo en todos los casos
Dos páginas WordPress pueden tener necesidades totalmente diferentes.
Una puede ser:
blog sencillo + caché + pocas visitas simultáneas
y otra:
WooCommerce + usuarios registrados + búsquedas + filtros + muchos plugins
Aunque ambas tengan un número mensual de visitas parecido, su consumo puede ser muy diferente.
Por eso mediría:
- CPU.
- RAM.
- procesos PHP.
- consultas.
- tiempo de respuesta.
antes de ampliar recursos.
¿Qué almacenamiento elegir?
En muchos VPS encontraremos SSD o NVMe.
El almacenamiento rápido puede beneficiar operaciones relacionadas con:
- Base de datos.
- Logs.
- Archivos.
- Caché.
- Escrituras.
Pero nuevamente no elegiría únicamente porque una oferta tenga la palabra:
NVMe.
Importan también calidad del proveedor, límites, redundancia y rendimiento sostenido.
¿Qué es el almacenamiento local?
En muchos VPS el disco está asociado a determinada infraestructura o nodo.
Esto puede tener implicaciones importantes cuando pensamos en disponibilidad y recuperación.
Si el proveedor ofrece snapshots o backups debemos investigar exactamente cómo funcionan.
No asumiría que porque existe un botón llamado:
snapshot
ya tenemos solucionada toda nuestra estrategia de copias.
Snapshot y backup no son exactamente lo mismo
Un snapshot puede capturar el estado de una máquina o volumen en un momento determinado dependiendo de la plataforma.
Puede ser muy útil.
Pero antes de confiar en él preguntaría:
- ¿Dónde se almacena?
- ¿Cuánto tiempo dura?
- ¿Qué ocurre si elimino el VPS?
- ¿Está en la misma infraestructura?
- ¿Cómo se restaura?
- ¿Tiene un coste adicional?
Para un proyecto importante mantendría además copias independientes.
¿Qué sistema operativo se utiliza en un VPS?
En servidores web encontraremos frecuentemente distribuciones Linux como:
- Debian.
- Ubuntu.
- AlmaLinux.
- Rocky Linux.
La elección depende de nuestras necesidades y conocimientos.
Si estamos empezando, utilizaría una distribución ampliamente documentada y compatible con el software que necesitamos.
No escogería un sistema extraño simplemente porque suena más técnico.
¿Necesito saber Linux?
Si contratamos un VPS no administrado, conocer Linux resulta extremadamente recomendable.
No necesitamos dominar absolutamente todo.
Pero sí entender conceptos como:
- Archivos.
- Usuarios.
- Permisos.
- Procesos.
- Servicios.
- Logs.
- Paquetes.
- Red.
- SSH.
Sin esa base cualquier problema sencillo puede convertirse en una aventura.
¿Qué es SSH?
SSH permite conectarnos remotamente al servidor mediante una terminal.
Por ejemplo, podemos administrar:
- Archivos.
- Servicios.
- Configuración.
- Actualizaciones.
- Procesos.
Es una de las herramientas fundamentales cuando gestionamos servidores Linux.
También significa que debemos proteger correctamente ese acceso.
No utilizaría contraseñas débiles en SSH
Un servidor expuesto a Internet puede recibir intentos automatizados de acceso prácticamente desde el comienzo.
No somos demasiado pequeños para interesar a bots.
Los escaneos automáticos buscan sistemas vulnerables continuamente.
Por eso utilizaría mecanismos de autenticación adecuados y limitaría accesos cuando resulte posible.
Claves SSH
Las claves SSH permiten autenticarnos utilizando criptografía de clave pública.
La clave privada permanece con nosotros.
La parte pública puede añadirse al servidor.
Este sistema puede resultar muy útil para administrar servidores.
Pero una clave privada debe protegerse igual que cualquier credencial sensible.
Nunca la publicaría en:
- GitHub.
- Un foro.
- Una captura.
- Un documento público.
Firewall
Cuando montamos nuestro propio VPS tenemos que pensar qué servicios están expuestos a Internet.
No todo necesita ser accesible públicamente.
Una configuración típica puede necesitar tráfico web por determinados puertos.
Pero quizá nuestra base de datos solamente necesita recibir conexiones desde la propia aplicación.
La pregunta debería ser:
¿qué necesita estar accesible y desde dónde?
No:
¿qué puedo abrir?
Puertos
Los servicios de red utilizan puertos.
Veremos habitualmente:
22 para SSH.
80 para HTTP.
443 para HTTPS.
Y otros dependiendo de nuestras aplicaciones.
No abriría un puerto simplemente porque un tutorial diga:
abre el 3306.
Primero entendería qué servicio utiliza ese puerto y quién necesita conectarse.
Base de datos expuesta públicamente
Supongamos que nuestra aplicación y MySQL están en el mismo VPS.
Quizá no existe ninguna necesidad de permitir que cualquiera desde Internet intente conectarse directamente a la base.
Reducir servicios expuestos disminuye nuestra superficie de ataque.
Esto no convierte automáticamente el servidor en seguro.
Pero es una buena práctica básica.
¿Qué stack necesito para una web PHP?
Una configuración típica podría incluir:
Linux
Nginx o Apache
PHP
MySQL/MariaDB
A veces encontraremos siglas como:
LAMP
o:
LEMP
para describir determinadas combinaciones.
Pero no es obligatorio utilizar exactamente un stack concreto.
Lo importante es que nuestra aplicación sea compatible y que sepamos mantenerlo.
Nginx o Apache
Ambos son servidores web ampliamente utilizados.
No convertiría la elección en una guerra.
Puede haber diferencias técnicas importantes según el escenario.
Pero para una web pequeña probablemente tenga más impacto:
- Una buena configuración.
- Caché.
- Base de datos optimizada.
- PHP correctamente configurado.
que elegir una tecnología únicamente porque alguien afirma que es “la más rápida”.
¿Puedo instalar un panel de control?
Sí, existen paneles que simplifican determinadas tareas de administración.
Pueden permitir gestionar:
- Dominios.
- Bases de datos.
- SSL.
- PHP.
- Usuarios.
- Correos.
- Backups.
Esto acerca la experiencia a un hosting tradicional.
Pero el panel también es software que debemos mantener y proteger.
No elimina completamente la responsabilidad de administrar el servidor.
Panel no significa VPS administrado
Esta diferencia es importante.
Podemos instalar un panel muy cómodo y seguir siendo responsables de:
- Sistema operativo.
- Actualizaciones.
- Firewall.
- Seguridad.
- Backups.
- Servicios.
Una interfaz gráfica facilita operaciones.
No convierte automáticamente nuestra infraestructura en gestionada.
¿Qué ocurre si el VPS se queda sin RAM?
Dependiendo del sistema y configuración podemos empezar a tener problemas importantes.
Procesos pueden cerrarse.
Servicios pueden dejar de responder.
La aplicación puede devolver errores.
Antes de ampliar memoria revisaría qué la está consumiendo.
Podemos tener:
- Demasiados procesos PHP.
- Base de datos mal configurada.
- Aplicación con fugas.
- Plugins.
- Tareas pesadas.
- Servicios innecesarios.
Añadir RAM puede ser correcto.
Pero primero debemos entender el consumo.
Swap
En Linux podemos encontrarnos con swap.
Simplificando, permite utilizar almacenamiento como apoyo cuando la memoria lo requiere según la configuración.
Pero el almacenamiento es mucho más lento que la RAM.
No consideraría:
1 GB RAM + 8 GB swap
equivalente a:
9 GB RAM.
No funciona así.
Swap puede ayudar en ciertas situaciones, pero no sustituye una cantidad adecuada de memoria.
¿Qué ocurre si la CPU está al 100 %?
Un pico ocasional puede ser normal.
Una CPU saturada continuamente requiere investigación.
Puede deberse a:
- PHP.
- Consultas.
- Crawlers.
- Bots.
- Procesos programados.
- Compresión.
- Backups.
- Malware.
- Aplicaciones defectuosas.
Antes de aumentar el plan revisaría procesos y métricas.
Monitorización
Una ventaja de disponer de mayor control es que podemos monitorizar mucho mejor el sistema.
Revisaría al menos:
- CPU.
- RAM.
- Disco.
- Carga.
- Red.
- Disponibilidad.
- Procesos.
- Logs.
Si administramos una web importante también configuraría alertas.
No quiero descubrir que el servidor lleva seis horas caído porque alguien me escribe por WhatsApp.
Disco lleno
Este problema puede romper servicios de formas bastante extrañas.
Los logs crecen.
Los backups se acumulan.
Las imágenes aumentan.
La base de datos crece.
Un día nos quedamos sin espacio.
A partir de ahí pueden fallar escrituras, bases de datos y aplicaciones.
Por eso monitorizar almacenamiento es obligatorio.
Cuidado con guardar backups en el mismo VPS
Imaginemos:
/backups
contiene todas nuestras copias.
Perfecto.
Hasta que el servidor desaparece completamente.
Entonces perdemos:
producción + backups
al mismo tiempo.
Para proyectos importantes tendría alguna copia fuera del propio VPS.
Actualizaciones
En un servidor no administrado tendremos que mantener el sistema actualizado.
Esto incluye:
- Sistema operativo.
- Paquetes.
- Servidor web.
- PHP.
- Base de datos.
- Librerías.
No significa actualizar producción sin comprobar nada.
Pero tampoco dejar todo abandonado durante años.
Debemos encontrar un proceso de mantenimiento razonable.
Reiniciar también forma parte de la administración
Algunas actualizaciones pueden requerir reinicios de servicios o incluso del sistema.
Eso implica pensar en disponibilidad.
Para un blog pequeño quizá un reinicio de un minuto no sea ningún problema.
Para una aplicación crítica puede necesitar planificación.
El contexto importa.
Logs
Cuando algo falla, los logs son fundamentales.
Podemos encontrar registros del:
- Sistema.
- Servidor web.
- PHP.
- Base de datos.
- Aplicación.
- Firewall.
Una de las ventajas de administrar nuestro propio VPS es disponer de mucho más acceso a esta información.
Una de las desventajas es que tenemos que saber interpretarla.
Error 502
Si tenemos un stack como:
Nginx → PHP-FPM
un problema entre ambos puede terminar provocando errores 502.
Pero no existe una causa única.
Podría ser:
- PHP caído.
- Socket incorrecto.
- Timeout.
- Saturación.
- Mala configuración.
Por eso el mensaje de error solamente es el comienzo de la investigación.
Error 503
Un 503 indica que el servicio no está disponible en ese momento.
Puede aparecer por:
- Sobrecarga.
- Mantenimiento.
- Aplicación caída.
- Falta de capacidad.
Nuevamente:
503 no significa automáticamente “necesito más RAM”.
Hay que mirar logs y recursos.
Error 500
El famoso 500 puede deberse a muchas causas del lado servidor.
Cuando aparece después de cambiar una configuración, plugin o código, revisaría primero qué acabamos de modificar.
También comprobaría logs.
Cambiar diez configuraciones simultáneamente solamente dificulta saber cuál era el problema.
¿Un VPS mejora el SEO?
No directamente.
Google no va a posicionarnos mejor simplemente porque nuestra web esté en un VPS.
Pero una infraestructura adecuada puede ayudar indirectamente proporcionando:
- Estabilidad.
- Buen rendimiento.
- Menos caídas.
- Capacidad suficiente.
Eso puede mejorar la experiencia del usuario y la calidad técnica del proyecto.
Pero:
VPS ≠ mejor posicionamiento automático.
Podemos tener el VPS más potente del mundo y una web que no responde correctamente a ninguna búsqueda.
Un VPS tampoco garantiza mejor velocidad
Este mito aparece mucho.
La velocidad depende del conjunto:
hardware + red + configuración + aplicación + caché + base de datos
Un VPS mal configurado puede ofrecer peor tiempo de respuesta que un hosting compartido optimizado.
Por eso mediría antes y después de cualquier migración.
¿Cuándo migraría WordPress a un VPS?
Lo consideraría cuando exista alguna de estas situaciones:
- Recursos insuficientes de forma recurrente.
- Necesidad de configuración específica.
- Restricciones del hosting actual.
- Varias webs con necesidades similares.
- Aplicaciones adicionales.
- Necesidad de mayor control.
- Crecimiento claro del proyecto.
Pero no lo haría simplemente porque hemos alcanzado:
10.000 visitas mensuales.
Ese número aislado no dice demasiado.
¿Cuántas visitas soporta un VPS?
Probablemente sea una de las preguntas más frecuentes y menos útiles.
Dos VPS idénticos pueden soportar cargas completamente distintas dependiendo de la aplicación.
Una página cacheada puede atender muchísimo tráfico con pocos recursos.
Una aplicación dinámica mal optimizada puede saturarse con pocos usuarios simultáneos.
La pregunta correcta sería:
¿qué recursos consume mi aplicación bajo una carga determinada?
Eso sí podemos medirlo.
Concurrencia frente a visitas mensuales
Esta diferencia es fundamental.
100.000 visitas distribuidas uniformemente durante un mes pueden ser relativamente sencillas de gestionar.
100.000 solicitudes concentradas en unos minutos son otra historia.
Cuando dimensionamos infraestructura importa mucho la concurrencia y los picos.
No únicamente el total mensual.
WooCommerce en VPS
Una tienda puede beneficiarse de disponer de recursos y configuración adecuados.
Pero WooCommerce tiene muchas partes dinámicas:
- Carrito.
- Checkout.
- Sesiones.
- Usuarios.
- Pedidos.
No podemos resolverlo todo simplemente instalando una caché de página completa.
En proyectos de ecommerce prestaría especial atención a:
- PHP.
- Base de datos.
- caché de objetos.
- procesos.
- plugins.
- consultas.
- cron.
Redis
En algunos VPS podemos instalar Redis para determinados usos como caché de objetos.
Esto puede resultar útil en ciertas aplicaciones.
Pero no instalaría Redis únicamente porque:
todas las guías de optimización lo recomiendan.
Primero comprobaría si nuestra aplicación puede utilizarlo correctamente y si estamos resolviendo un problema real.
Cada servicio adicional consume recursos y necesita mantenimiento.
CDN
Un VPS puede trabajar perfectamente junto a una CDN.
No son alternativas.
Podemos tener:
usuario → CDN/proxy → VPS
La CDN puede encargarse de determinados recursos, caché o funciones de red.
Nuestro VPS continúa ejecutando la aplicación.
La arquitectura depende de nuestras necesidades.
¿Qué ubicación elegir?
Si prácticamente toda nuestra audiencia está en España, una ubicación europea bien conectada puede resultar razonable.
Si tenemos usuarios repartidos internacionalmente, la situación cambia.
Pero no elegiría únicamente según kilómetros físicos.
También importan:
- Calidad de red.
- Rutas.
- Peering.
- CDN.
- proveedor.
La latencia real es más importante que mirar un mapa.
IPv4 e IPv6
Los proveedores pueden ofrecer direcciones IPv4, IPv6 o ambas.
No entraré aquí en toda la teoría de direccionamiento.
Pero conviene comprobar qué incluye nuestro plan, especialmente si determinadas integraciones o configuraciones requieren IPv4.
Algunos proveedores pueden cobrar aparte ciertos recursos de red.
Dirección IP dedicada
Un VPS suele tener una o varias direcciones asignadas según el proveedor.
Eso nos proporciona control sobre la infraestructura.
Pero no asumiría que disponer de una IP propia proporciona automáticamente ventajas SEO.
No existe una razón para contratar un VPS únicamente pensando:
Tendré una IP exclusiva y Google me posicionará mejor.
Correo electrónico en un VPS
Técnicamente podemos instalar nuestro propio servidor de correo.
Pero administrarlo correctamente puede ser bastante más complejo de lo que parece.
Tenemos que pensar en:
- Entrega.
- Reputación IP.
- SPF.
- DKIM.
- DMARC.
- Spam.
- Seguridad.
- Colas.
- Bloqueos.
Para muchos proyectos prefiero separar el correo transaccional o corporativo utilizando servicios especializados.
No metería todos los servicios en el mismo VPS sin pensarlo
Es tentador instalar:
web + email + base de datos + backups + analítica + VPN + automatizaciones
todo en la misma máquina.
Funciona.
Hasta que esa máquina falla.
También aumenta la complejidad y superficie de ataque.
No significa que debamos tener diez servidores desde el comienzo.
Pero sí entender qué consecuencias tiene concentrarlo todo.
VPS para varias webs
Esta puede ser una razón interesante para contratar uno.
Podemos alojar diferentes proyectos dentro del mismo servidor y controlar el entorno.
Pero debemos vigilar el aislamiento.
Si una web consume toda la CPU o sufre un problema de seguridad, podría afectar a las demás.
No consideraría cada web completamente independiente simplemente porque tiene un dominio diferente.
¿Un VPS es más seguro?
No por definición.
Tenemos más control para aplicar medidas de seguridad.
Pero también más responsabilidad.
Un hosting compartido administrado por un equipo competente puede ser mucho más seguro que un VPS abandonado con software desactualizado.
La seguridad depende de cómo gestionamos el sistema.
Principio de mínimo privilegio
Una práctica importante consiste en proporcionar a cada usuario o proceso únicamente los permisos necesarios.
No ejecutaría todas las aplicaciones como root.
No daría permisos de escritura globales simplemente para solucionar un error.
No compartiría la misma credencial para todo.
Reducir privilegios limita el impacto potencial de determinados fallos.
Fail2ban y herramientas similares
En servidores Linux encontraremos herramientas destinadas a bloquear o limitar determinados comportamientos según registros y reglas.
Pueden formar parte de una estrategia de seguridad.
Pero instalar una herramienta no sustituye:
- Actualizaciones.
- Contraseñas.
- Firewall.
- Buenas configuraciones.
- Monitorización.
No existe un plugin mágico que convierta un VPS en invulnerable.
Backups automatizados
Si administramos nuestro propio servidor, automatizar copias puede ahorrarnos problemas.
Pero comprobaría que realmente funcionan.
Una tarea programada puede fallar durante meses sin que nadie se dé cuenta.
Por eso además de crear backups necesitamos:
monitorizar backups.
Y, de vez en cuando:
probar restauraciones.
Un backup no probado es una promesa
Podemos tener cien archivos llamados:
backup-final-definitivo.sql.gz
pero hasta intentar restaurarlos no sabemos con seguridad si nos permitirán recuperar el sistema.
En un proyecto importante realizaría pruebas de recuperación.
No necesariamente cada día.
Pero sí de forma periódica.
VPS y automatizaciones
Un VPS puede ser útil cuando necesitamos ejecutar procesos recurrentes.
Por ejemplo:
- Scripts.
- Cron jobs.
- Bots.
- Procesamiento de datos.
- APIs internas.
- Workers.
En un hosting compartido algunas de estas tareas pueden estar limitadas.
En un VPS tenemos mayor libertad para configurar procesos según nuestras necesidades.
Docker en un VPS
Otra posibilidad habitual es utilizar contenedores.
Docker puede ayudar a empaquetar aplicaciones y dependencias de una forma reproducible.
Pero no instalaría Docker simplemente porque:
todo el mundo lo utiliza.
Si nuestra aplicación puede desplegarse fácilmente sin esa capa, quizá no la necesitemos.
Primero entendería el problema que queremos resolver.
¿Qué es un VPS cloud?
Muchos proveedores utilizan términos como:
- Cloud VPS.
- Cloud server.
- Cloud instance.
No existe una definición comercial totalmente uniforme entre empresas.
Algunas plataformas permiten ampliar recursos, crear snapshots, redes privadas, volúmenes y otras funcionalidades con bastante flexibilidad.
Otras utilizan “cloud” principalmente como término comercial.
Leeríamos la arquitectura y características concretas.
Escalar verticalmente
Escalar verticalmente significa aumentar recursos de una máquina.
Por ejemplo:
2 vCPU → 4 vCPU
4 GB RAM → 8 GB RAM
Es una forma sencilla de ampliar capacidad.
Para muchos proyectos puede ser suficiente durante bastante tiempo.
Escalar horizontalmente
Escalar horizontalmente implica añadir más máquinas o instancias.
Por ejemplo:
VPS A + VPS B + VPS C
y distribuir trabajo entre ellas.
Esto requiere una aplicación y arquitectura preparadas.
No intentaría diseñar todo para escalado horizontal el primer día si todavía tenemos veinte visitas.
Empieza sencillo
Este consejo me parece especialmente importante en infraestructura.
Podemos pasar días diseñando:
- Kubernetes.
- Balanceadores.
- Réplicas.
- Microservicios.
- Colas.
- Clusters.
para un proyecto que todavía no tiene usuarios.
Cada pieza añade:
- Coste.
- Configuración.
- Monitorización.
- Fallos posibles.
- Tiempo de mantenimiento.
Empezaría con la arquitectura más sencilla que cumpla nuestras necesidades actuales.
¿VPS o servidor dedicado?
Un servidor dedicado puede resultar interesante cuando necesitamos recursos físicos propios, mucha capacidad o requisitos particulares.
Un VPS ofrece más flexibilidad y normalmente una barrera de entrada bastante menor.
No existe un ganador universal.
Para la mayoría de proyectos pequeños y medianos que necesitan superar un hosting compartido, un VPS puede ser un punto intermedio bastante razonable.
¿VPS o hosting compartido?
Elegiría hosting compartido cuando priorizo:
- Simplicidad.
- Administración incluida.
- Menor mantenimiento.
- Proyecto estándar.
- Recursos suficientes.
Consideraría VPS cuando necesito:
- Más control.
- Configuración personalizada.
- Aplicaciones propias.
- Procesos específicos.
- Mayor flexibilidad.
- Recursos más definidos.
El precio no debería ser el único criterio.
¿VPS administrado o no administrado?
Si mi negocio depende de la web y no tengo experiencia administrando Linux, elegiría probablemente un servicio administrado o contrataría a alguien que pueda ocuparse.
Si quiero aprender servidores y el proyecto no es crítico, un VPS barato de pruebas puede ser una excelente escuela.
Separaría completamente:
servidor para aprender
de:
servidor que paga las facturas.
Qué comprobar antes de contratar un VPS
Mi checklist sería:
- vCPU.
- RAM.
- Almacenamiento.
- Transferencia.
- Ubicación.
- IPv4/IPv6.
- Sistema operativo disponible.
- Backups.
- Snapshots.
- Panel, si lo necesitamos.
- Nivel de administración.
- Soporte.
- Posibilidad de ampliar recursos.
- Precio de renovación.
- Condiciones de transferencia.
- SLA o disponibilidad.
- Qué ocurre si necesitamos migrar.
También revisaría opiniones recientes sobre estabilidad y soporte.
No contrataría solamente por el precio promocional
Un VPS de 2 € mensuales puede ser atractivo.
Pero preguntaría:
- ¿Qué hardware utiliza?
- ¿Qué soporte incluye?
- ¿Cuánto cuesta renovar?
- ¿Tiene backups?
- ¿Qué red ofrece?
- ¿Cómo se recupera una máquina?
- ¿Existe protección ante fallos?
Un servidor que aloja un proyecto importante no debería elegirse únicamente comparando céntimos.
¿Cuánto debería pagar?
Depende completamente del proyecto.
Para experimentar podemos encontrar opciones muy económicas.
Para producción quizá valoremos más:
- Fiabilidad.
- Backups.
- Soporte.
- Red.
- Administración.
No existe una cifra correcta.
Un VPS caro puede ser innecesario para un blog.
Uno demasiado básico puede ser una mala decisión para una tienda que genera miles de euros al día.
¿Cuándo NO contrataría un VPS?
No lo haría simplemente porque:
Parece más profesional.
Tampoco si:
- Mi hosting actual funciona perfectamente.
- No necesito configuraciones especiales.
- No sé administrarlo y tampoco quiero contratar administración.
- La única razón es ahorrar unos pocos euros.
- Estoy intentando solucionar una web lenta sin haber medido el problema.
En esos casos probablemente mantendría una solución gestionada.
¿Cuándo sí lo contrataría?
Cuando necesito algo que mi alojamiento actual no puede proporcionar razonablemente.
Por ejemplo:
más control
servicios personalizados
aplicaciones propias
automatizaciones
configuración específica
recursos más definidos
varios proyectos
y tengo capacidad para administrar correctamente la infraestructura.
Ahí un VPS puede ser una herramienta fantástica.
VPS para aprender
Incluso aunque no necesitemos uno en producción, contratar un VPS pequeño durante un tiempo puede ser una excelente forma de aprender.
Podemos practicar:
- SSH.
- Linux.
- Nginx.
- Apache.
- PHP.
- MySQL.
- Firewall.
- DNS.
- SSL.
- Backups.
- Logs.
Y romperlo sin consecuencias graves.
Eso sí: nunca utilizaría datos reales sensibles en un servidor destinado únicamente a experimentos.
Lo que aprendería primero
Si quisiera pasar de hosting compartido a administrar mi propio VPS, seguiría aproximadamente este orden:
Linux básico
Después:
usuarios y permisos
Luego:
SSH
red y puertos
firewall
servidor web
PHP o entorno de aplicación
base de datos
SSL
logs
backups
monitorización
No intentaría aprender todo durante la misma tarde.
La parte difícil no es instalar WordPress
Con determinados scripts o paneles podemos tener WordPress funcionando rápidamente.
Eso no significa que sepamos administrar el servidor.
La prueba real llega cuando:
- Se llena el disco.
- PHP se cae.
- Una actualización falla.
- Expira algo.
- Un bot dispara la carga.
- La base deja de responder.
Ahí necesitamos comprender qué está ocurriendo.
Un VPS no es “configurar una vez y olvidar”
Un servidor necesita mantenimiento.
Debemos revisar periódicamente:
- Actualizaciones.
- Capacidad.
- Backups.
- Errores.
- Seguridad.
- Logs.
- Certificados.
- Servicios.
La frecuencia dependerá de la importancia del proyecto.
Pero no dejaría una máquina pública abandonada durante años.
Conclusión
Un VPS es un servidor virtual que nos proporciona bastante más control que un alojamiento compartido tradicional.
Puede ser una opción excelente cuando necesitamos:
- Configuración personalizada.
- Más flexibilidad.
- Aplicaciones propias.
- Recursos definidos.
- Servicios adicionales.
Pero no es automáticamente más rápido, más seguro ni mejor que un hosting compartido.
Todo depende de cómo esté configurado y administrado.
Para una web pequeña que funciona correctamente en un hosting gestionado, probablemente no exista ninguna urgencia por migrar.
Para un proyecto que empieza a necesitar más control técnico, un VPS puede ser el siguiente paso lógico.
La pregunta que me haría antes de contratarlo sería muy sencilla:
¿Necesito realmente un VPS o simplemente quiero uno porque parece una mejora?
Si podemos responder claramente qué problema va a resolver, probablemente estemos tomando la decisión por el motivo correcto.
¿Utilizáis VPS en vuestros proyectos? ¿Preferís administrarlos vosotros mismos o pagar por un servicio gestionado?
