Recomendaciones de VPS
Cómo elegir la configuración de un VPS (2026): qué pueden ejecutar realmente 1 núcleo/1 GB, 2 núcleos/2 GB y 2 núcleos/4 GB
No compares solo la cantidad de núcleos al comprar un VPS. Este artículo explica los límites reales de capacidad de 1 núcleo/1 GB, 2 núcleos/2 GB, 2 núcleos/4 GB y 4 núcleos/8 GB en escenarios como sitios estáticos, WordPress, Docker, múltiples sitios, bases de datos y K3s, y ofrece ejemplos de planes actuales, comandos de monitoreo de recursos, señales de actualización y una lista de verificación antes de comprar.
"¿Basta 1 núcleo/1 GB para un sitio web personal?" Esta es la pregunta más común al elegir un VPS, y la que más fácilmente se desvía con un simple "es suficiente".
Con el mismo 1 núcleo/1 GB, una máquina que solo aloja páginas estáticas puede estar inactiva durante años; otra que ejecuta WordPress, MySQL, Redis, un panel y un montón de plugins puede empezar a usar Swap en el momento en que arranca. No hay una respuesta estándar de configuración separada de la carga de trabajo, pero los límites se pueden calcular con claridad.
Este artículo no presenta "lo mínimo con lo que puede arrancar" como "lo que puede ejecutar de forma estable a largo plazo". Escribiré por separado los requisitos oficiales, las recomendaciones de planificación de capacidad y los planes disponibles actualmente, para que elijas según tu propia carga de trabajo.
Lo siguiente es una recomendación de planificación de capacidad, no una promesa de rendimiento del proveedor. El modelo de CPU, el nivel de sobreventa, la E/S de disco, la ruta de red y la configuración del software cambian el resultado.
| Configuración | Escenarios más adecuados | Errores comunes | Mi recomendación |
|---|---|---|---|
| 1 núcleo/1 GB | Sitios estáticos, páginas de redirección, monitoreo pequeño, bots ligeros, pruebas temporales | Queda poco margen tras instalar un panel y una base de datos | Ejecutar solo una carga ligera única, con rotación de registros y monitoreo configurados |
| 1 núcleo/2 GB / 2 núcleos/2 GB | WordPress de bajo tráfico, blogs personales, una base de datos más unos pocos contenedores | Muchos plugins, tareas de compilación o consultas a la base de datos competirán por recursos | Un nivel de partida práctico para sitios personales |
| 2 núcleos/4 GB | WordPress + Redis, múltiples contenedores, API pequeñas, varios sitios de bajo tráfico | Si el disco y la red son malos, más memoria no te salvará | Priorízalo si no quieres actualizar con frecuencia |
| 4 núcleos/8 GB | Múltiples sitios, aplicaciones Java, compilaciones de CI, servicios de equipos pequeños, experimentos ligeros con K3s | 4 núcleos compartidos pueden ser peores que 2 núcleos de alto rendimiento | Primero confirma el modelo de CPU, la política de núcleos dedicados y el rendimiento NVMe |
| 8 GB o más | Bases de datos medianas, más contenedores, compilación, servicios de búsqueda | Acumular memoria ignorando las copias de seguridad y la alta disponibilidad | Primero separa aplicación, base de datos y almacenamiento, luego decide entre escalar una sola máquina o dividir |
Si no quieres hacer ninguna estimación de recursos, empieza los proyectos personales directamente con 2 núcleos/2 GB; si planeas ejecutar WordPress + base de datos + Redis, o alrededor de 5 contenedores ligeros, 2 núcleos/4 GB suele dar menos problemas.
Los "5 contenedores" aquí no son una métrica estricta. Un contenedor Caddy inactivo y un servicio de búsqueda Java pueden diferir en consumo de recursos decenas de veces. Lo que realmente importa es el programa dentro del contenedor, no la cantidad de contenedores.
Muchos artículos suelen escribir "WordPress mínimo 1 GB" o "Docker mínimo 2 GB", que parecen ciertos pero a menudo no son declaraciones oficiales.
Tras su actualización de mayo de 2026, la página oficial de requisitos de WordPress recomienda:
- PHP 8.3 o superior;
- MariaDB 10.11+ o MySQL 8.0+;
- HTTPS;
- Apache o Nginx.
La página oficial no indica "cuántos núcleos y cuántos GB se requieren". Esto se debe a que las necesidades de recursos de WordPress varían enormemente según temas, plugins, tráfico, procesamiento de imágenes, caché y tamaño de la base de datos.
Así que 1 núcleo/1 GB se puede instalar, pero eso no significa que sea adecuado para ejecutarse a largo plazo con un panel, MySQL y múltiples plugins. Para un blog personal con mínimas complicaciones, elegiría 2 GB como punto de partida; con WooCommerce, constructores de páginas y muchos plugins, iría directamente a 4 GB.
Fuente oficial: WordPress Requirements
La documentación oficial de instalación de Docker especifica principalmente las distribuciones de Linux y arquitecturas de CPU compatibles, y no promete "cuánta memoria puede ejecutar cuántos contenedores". El demonio de Docker en sí no es el problema principal; lo que realmente consume recursos es MySQL, PostgreSQL, Java, la automatización de navegadores y tus propias aplicaciones.
Un VPS de 1 GB ejecutando Caddy + un pequeño programa Go puede ir muy holgado; cambia a WordPress + MySQL + Redis + monitoreo, y el margen desaparece rápidamente.
Fuente oficial: Install Docker Engine
La página oficial de requisitos de K3s indica estos requisitos mínimos de hardware:
- Nodo Server: 2 núcleos, 2 GB de RAM;
- Nodo Agent: 1 núcleo, 512 MB de RAM;
- Se prefiere SSD.
La página oficial también señala específicamente que esto es solo la línea base de K3s y sus componentes incluidos, sin incluir las cargas de trabajo del negocio. Es decir, 2 núcleos/2 GB pueden poner en marcha el plano de control, pero eso no significa que puedas meter cómodamente una base de datos, monitoreo y un montón de aplicaciones.
Fuente oficial: K3s Requirements
1 GB de memoria es más adecuado para proyectos con "una sola tarea, pocos servicios y datos pequeños".
Lo usaría para:
- Sitios estáticos Nginx/Caddy;
- Páginas de navegación personal, páginas de estado;
- Monitoreo ligero como Uptime Kuma, sin demasiados monitores;
- Pequeños bots de Telegram/Discord;
- Nodos personales de WireGuard;
- Tareas temporales de desarrollo y línea de comandos;
- Pasarelas API ligeras que solo reenvían solicitudes y no ejecutan modelos localmente.
No recomendado para ejecutar simultáneamente en 1 GB:
- BaoTa/1Panel + WordPress + MySQL;
- Múltiples tareas de automatización que requieren Chromium;
- Aplicaciones Java;
- GitLab, un conjunto completo de monitoreo o una plataforma de IA multiservicio;
- Entornos Docker sin límites de tamaño de registros.
Si ya compraste 1 GB, puedes usar ZRAM o Swap para dar un búfer a la memoria de ráfaga, pero no son memoria gratis. El intercambio continuo ralentizará el disco y, al final, aún tendrás que reducir servicios o actualizar. Para la configuración específica, consulta: Cómo optimizar un VPS de poca memoria con ZRAM y Swap (2026).
El sentido de 2 GB no es "el doble de rendimiento", sino que el sistema operativo, los registros, la base de datos y las aplicaciones ya no tienen que apretarse en los últimos cientos de MB.
Este nivel es más adecuado para:
- Un único WordPress de bajo tráfico;
- Blogs personales como Typecho, Ghost;
- Caddy/Nginx + aplicación + base de datos pequeña;
- 2–4 servicios Docker ligeros;
- Tareas pequeñas de Git, Webhook, automatización;
- Entornos de desarrollo y pruebas.
Al ejecutar WordPress, limitaría la cantidad de plugins, activaría OPcache, limitaría los procesos hijos de PHP-FPM y configuraría cachés de MySQL adecuadas para una máquina de poca memoria. A medida que crece el tráfico, primero revisa las consultas lentas, las colas de PHP-FPM y la tasa de aciertos de caché; no añadas núcleos a ciegas en cuanto se ralentice.
Si ya tienes 2 GB pero WordPress sigue lento, consulta: Qué hacer cuando WordPress va lento en un VPS (2026).
4 GB no hará que un sitio web sea más rápido automáticamente, pero deja espacio para cachés de base de datos, Redis, tareas de compilación y reinicios de contenedores.
Los usos comunes incluyen:
- WordPress + MySQL/MariaDB + Redis + Caddy;
- 5–10 contenedores de baja carga;
- Dos o tres sitios con poco tráfico;
- API Node.js/Python + PostgreSQL;
- Combinaciones como n8n, Directus, Uptime Kuma;
- Entornos de prueba de equipos pequeños.
"5–10" sigue siendo solo un rango de planificación para servicios ligeros. Cuando los contenedores incluyen navegadores, Elasticsearch, inferencia de modelos o grandes cantidades de tareas concurrentes, 4 GB también pueden agotarse rápidamente.
Este nivel es adecuado para quienes no quieren migrar cada vez que añaden un servicio. Cuando la diferencia de precio mensual es aceptable, prefiero dejar alrededor del 25% de margen de memoria que tener la máquina funcionando al 95% todo el año.
Docker Compose en producción también debe limitar los recursos por contenedor, para evitar que una tarea anómala arrastre toda la máquina: Cómo configurar Docker Compose para producción en un VPS (2026).
Una vez que llegas a 8 GB o incluso 16 GB, la pregunta ya no es solo "comprar más grande".
Si la aplicación, la base de datos, el almacenamiento de objetos y las copias de seguridad están todos en una sola máquina, cualquier fallo del sistema los tumbará todos juntos. Cuando el negocio empieza a importar, considera:
- Separar aplicación y base de datos;
- Poner archivos grandes en almacenamiento de objetos;
- Poner las copias de seguridad con otro proveedor o en otra región;
- Usar instancias por horas por separado para tareas de compilación;
- Dejar un nodo pequeño independiente para monitoreo y páginas de estado.
Escalar una sola máquina tiene las ventajas de simplicidad y baja latencia de red interna; dividir tiene las ventajas de límites de fallo claros y escalado más flexible. Los proyectos pequeños no necesitan adoptar un clúster complejo antes de tiempo por "corrección arquitectónica", pero cuando la base de datos ya consume la mitad de la memoria, es momento de hacer cuentas en serio.
"4 núcleos" solo indica cuántos vCPU se asignan, no qué tan rápido es cada núcleo ni cuánto tiempo puedes ocuparlos de forma continua.
Antes de comprar, confirma al menos:
- Modelo y generación de CPU;
- CPU compartida o dedicada;
- Si se puede ver un steal time evidente;
- Si el proveedor limita el uso continuo alto de CPU;
- ARM o x86, y si el software es compatible.
2 núcleos de una CPU nueva de alta frecuencia pueden compilar y responder a PHP con más soltura que 4 núcleos compartidos de una plataforma antigua. Si la carga no cambia en la hora punta de la noche pero el rendimiento cae notablemente, revisa la sobreventa y la competencia de vecinos: Cómo juzgar la sobreventa de un VPS (2026).
Los planes ARM suelen tener precios atractivos, pero los paneles de código cerrado, las imágenes antiguas y el software que solo distribuye binarios amd64 pueden no ser compatibles. Antes de comprar, consulta: ¿Vale la pena comprar un VPS ARM? (2026).
20 GB parecen suficientes para el sistema y un sitio web, pero las imágenes Docker, las cachés de compilación, las bases de datos, las copias de seguridad y los registros lo irán llenando poco a poco.
Yo reservaría:
- Sistema, paquetes y registros básicos: al menos 8–12 GB;
- Imágenes Docker y capas de contenedores: 10–30 GB adicionales según la aplicación;
- Base de datos: planificar 2–3 veces el volumen de datos actual para crecimiento y espacio temporal;
- Copias de seguridad locales: no guardar solo una copia, y mucho menos tratarla como copia de seguridad externa.
Para bases de datos y entornos de contenedores, prefiere SSD/NVMe. Con la misma capacidad nominal, la escritura sostenida y la E/S aleatoria pueden diferir mucho; tras contratar para un negocio importante, deberías ejecutar fio, pero no hagas pruebas destructivas en horas punta de producción.
Un puerto de 1 Gbps no significa datos ilimitados al mes. El puerto es el límite instantáneo; el paquete de tráfico determina cuánto se puede transferir en un mes.
Una estimación sencilla:
月出站流量 ≈ 页面平均大小 × 月页面浏览量 × 未命中 CDN 的比例
Por ejemplo, con un tamaño medio de página de 1 MB y 100.000 visitas al mes, todo servido directamente desde el origen, son unos 100 GB. Si las imágenes pasan por CDN y hay aciertos de caché del navegador, el tráfico del origen será mucho menor; el vídeo, las descargas y las copias de seguridad amplificarán rápidamente el tráfico.
Cuando el tráfico esté ajustado, monitorea primero; no esperes a que llegue el correo de suspensión: Monitoreo de tráfico de VPS y alertas de exceso de cuota (2026).
A continuación se muestra una instantánea de la biblioteca de planes de Directus a fecha de 18 de julio de 2026, que solo sirve para mostrar cómo se comparan los niveles de 1 GB, 2 GB y 4 GB, y no constituye un aval de rendimiento. Los precios, el stock, las rutas de red y las reglas de renovación cambian; antes de pedir, prevalece la página de pago.
| Nivel | Ejemplo de plan | CPU / Memoria / Almacenamiento | Tráfico y puerto | Precio | Compra |
|---|---|---|---|---|---|
| 1 GB | RackNerd KVM VPS 1 GB (New Year 2026) | 1 núcleo / 1 GB / 24 GB | 2 TB / 1 Gbps | $11.29/año | Ver plan |
| 2 GB | VMrack L1.VPS.2C2G.Base | 2 núcleos / 2 GB / 40 GB | 2 TB / 5 Gbps | $3.66/mes | Ver plan |
| 4 GB | VMrack L1.VPS.2C4G.Base | 2 núcleos / 4 GB / 60 GB | 4 TB / 5 Gbps | $5.66/mes | Ver plan |
En los planes baratos, presta aún más atención a la virtualización, los reembolsos, las renovaciones, el centro de datos y la política de uso de CPU. Antes de comprar una máquina anual por primera vez, conviene buscar primero un plan mensual o una IP de prueba para verificar la ruta de red; no importa lo barata que sea la máquina, los datos importantes deben tener copias de seguridad externas.
No decidas actualizar basándote en "se siente lento". Primero observa de forma continua durante varios días, incluida la hora punta del negocio.
# 内存、可用内存和 Swap
free -h
# 每秒观察运行队列、换页和 CPU 等待
vmstat 1
# Docker 容器实时资源占用
docker stats
# 磁盘空间与文件系统
df -h
# 磁盘延迟、队列和利用率，需要安装 sysstat
iostat -xz 1
# 最近是否发生 OOM
journalctl -k --since "24 hours ago" | grep -i -E "oom|out of memory|killed process"
Las señales de que necesitas actualizar suelen ser:
- La memoria disponible se mantiene muy baja en horas punta, con Swap in/out continuo;
- Aparece OOM Kill en los registros;
- La CPU está al máximo durante largos periodos y la cola de ejecución se mantiene por encima del número de vCPU;
iowaity la latencia de disco se mantienen altas;- El espacio libre en disco es inferior al 15%–20%;
- Los contenedores se reinician repetidamente por límites de memoria;
- Los recursos siguen siendo insuficientes tras optimizar código, caché y consultas.
Un pico único no significa que debas actualizar. Las copias de seguridad, las actualizaciones, la compresión de registros y las tareas programadas pueden elevar brevemente la carga; juzga según la duración y el impacto en el negocio.
- ¿La carga de trabajo necesita x86 o es compatible con ARM;
- ¿La CPU es compartida o dedicada, y hay un límite de uso continuo;
- ¿La memoria incluye Swap utilizable, y se puede actualizar después sin pérdida;
- ¿El almacenamiento es NVMe, SSD o HDD;
- ¿El tráfico es unidireccional, bidireccional o ilimitado con uso justo;
- ¿El ancho de banda del puerto es compartido, y cómo se factura el tráfico excedente;
- ¿Se incluye IPv4, y cómo se cobran las IP adicionales;
- ¿Cuál es la ruta en hora punta nocturna desde el centro de datos hasta los usuarios objetivo;
- Reglas de reembolso, renovación, migración y cambio de IP;
- ¿Hay consola, modo de rescate, instantáneas y copias de seguridad;
- ¿Has probado el mismo centro de datos antes de pagar anualmente;
- ¿Los datos importantes tienen un plan de recuperación externo.
Sí, se puede instalar y puede ejecutar sitios de bajo tráfico, pero el sistema, el servicio web, PHP y la base de datos se apretarán en 1 GB. Con muchos plugins, procesamiento de imágenes o picos repentinos de tráfico, es más probable que use Swap. Para uso a largo plazo, es más recomendable partir de 2 GB.
No hay un número fijo. Unos pocos servicios pequeños Go/Node inactivos pueden ir bien, mientras que un solo contenedor de automatización de navegador o Java puede consumir la mayor parte de la memoria. Usa docker stats para ver el uso real de cada servicio y mantener margen del sistema.
Depende del tipo de sitio y del tráfico. Los sitios estáticos pueden ser muchos; varios WordPress dinámicos se verán afectados por PHP-FPM, la base de datos y los plugins. En lugar de contar sitios, mira la CPU en hora punta, la memoria disponible, las consultas lentas y la latencia de disco.
El sistema Windows y el escritorio gráfico consumen más memoria por sí mismos. Cuando necesitas escritorio remoto, navegador o software de escritorio, 4 GB suele ser más práctico que 2 GB; para ejecutar varios programas, sigue añadiendo más.
Sí, pero confirma si el proveedor admite escalado en línea, restricciones de reducción y reglas de reducción de disco. La CPU y la memoria suelen ser fáciles de aumentar; tras ampliar el disco, a menudo no se puede reducir sin pérdida. Antes de migrar, consulta: Guía de migración de VPS (2026).
Para solo sitios estáticos, monitoreo o herramientas pequeñas, compraría 1 GB, siempre que el servicio sea único, los registros estén controlados y los datos tengan copia de seguridad.
Para blogs personales y WordPress de bajo tráfico, empezaría con 2 núcleos/2 GB; si planeo instalar un panel, Redis, múltiples contenedores, o no quiero migrar de nuevo en unos meses, iría directamente a 2 núcleos/4 GB.
Cuando el negocio llega a 8 GB o más, no miraría solo "una máquina única más grande", sino que evaluaría también si la base de datos, el almacenamiento de objetos, las copias de seguridad y el monitoreo deberían separarse. Elegir bien la configuración no es comprar lo más grande de una vez, sino dar margen a la carga actual sin quedar bloqueado para futuras actualizaciones.