¿Qué plan VPS necesito para lo que ejecuto?

Ya has elegido la aplicación. Ahora tienes delante cuatro tarjetas de planes con etiquetas como Para aplicaciones ligeras y proyectos personales y Para aplicaciones en producción, mientras que la documentación de tu aplicación habla de gigabytes y núcleos, y una cosa no encaja con la otra por sí sola. Immich, por ejemplo, pide 6 GB de memoria como mínimo, lo que descarta Stack 4 y sus 4 GB antes de instalar nada.

Cada fila de abajo pone lo que publican los creadores de la aplicación junto al plan que le corresponde. Es nuestra estimación a partir de la documentación de cada proveedor, consultada el 2 de octubre de 2026. No hemos ejecutado estas aplicaciones en servidores de DreamHost, aunque sí probamos una combinación habitual en nuestra propia máquina de prueba, más abajo. Cuando un proveedor no publica ninguna cifra, la fila lo indica.

Qué incluye cada plan

Los cuatro planes incluyen acceso root completo, el sistema operativo Linux que elijas, Docker y la biblioteca de aplicaciones de un clic. Se diferencian en núcleos, memoria y disco:

Mira la columna de vCPU antes que la de memoria. Stack 8 duplica la memoria y el disco de Stack 4, pero mantiene las mismas 2 vCPU, así que una aplicación que se queda corta de CPU tiene que saltar a Stack 16, el primer plan con más núcleos. Stack 32 vuelve a duplicarlos, hasta 8.

Busca tu app en la tabla de tamaños

Busca la fila que más se parezca a lo que ejecutas. Empieza con el plan de la última columna. La columna central recoge lo que publican los creadores de la aplicación, con enlaces en las fuentes de abajo. La página de hosting VPS de cada aplicación está enlazada debajo de la tabla.

Páginas de hosting VPS de cada aplicación de la tabla: LAMP Stack, Node.js, PostgreSQL, Docker y Portainer, Dokploy, n8n, GitLab, Supabase, Immich, Pelican Panel, OpenClaw, Hermes Agent, Paperclip, Ghost, Umami, Uptime Kuma.

El mínimo de Immich es de 6 GB, así que Stack 4 no aparece en su fila, aunque Immich afirma que un sistema de 4 GB puede funcionar con el aprendizaje automático desactivado.

En la mayoría de las filas no encontrarás un número de usuarios, porque GitLab es el único proveedor de la lista que lo publica: su configuración de poca memoria está pensada para un máximo de cinco desarrolladores.

Las aplicaciones de un mismo servidor comparten su memoria, así que suma sus filas y deja espacio para el sistema operativo. Si pones n8n junto a Immich, sus mínimos suman 10 GB antes de que el sistema operativo se lleve su parte, que fue de unos 300 MiB en nuestra VM de prueba con Ubuntu 24.04 recién instalado. Eso es más de lo que tiene Stack 8, así que la combinación empieza en Stack 16.

Lo que usaron ambas apps en nuestra VM de prueba

Ejecutamos esa combinación en una VM de prueba con 2 vCPU y 8 GB de memoria, la configuración de Stack 8, el 22 de octubre de 2026. Era Immich v3.3.5 con la configuración de versión de Immich, con el aprendizaje automático activado y sin fotos, junto a n8n 2.44.5 con PostgreSQL a partir de los archivos Docker Compose del propio n8n, sin flujos de trabajo. La VM funcionaba en un Mac arm64, así que se trata de nuestra máquina de prueba, no de un servidor de DreamHost.

En reposo, ambas usaron menos de 2 GB, muy por debajo de los 10 GB que suman sus mínimos. Pero el reposo no es el límite. En una prueba aparte con una máquina del mismo tamaño, Immich por sí solo llegó a unos 6 GB mientras procesaba una importación de solo 300 fotos. Si a ese pico le sumas los 0,4 GB de n8n en reposo, salen unos 6,4 GB; es un cálculo, porque no ejecutamos las dos con carga a la vez. Eso deja poco margen en 8 GB, y por eso seguimos recomendando empezar con Stack 16 para ambas. Ejecutamos cada configuración una sola vez y eran instalaciones nuevas sin usuarios, así que tómalas como el consumo mínimo que verás, no como mínimos para dimensionar el servidor.

El disco puede agotarse antes que la memoria. Una biblioteca de fotos o un servidor Git pueden llenarlo mientras la memoria sigue pareciendo correcta.

Si vas a trasladar una biblioteca de fotos, mídela primero y añade el margen de Immich antes de compararla con el disco del plan. La cifra de GitLab solo cubre la aplicación y, además, pide un almacenamiento para repositorios al menos tan grande como todos tus repositorios juntos.

Apps cuyos creadores piden más que Stack 8

GitLab

GitLab es el caso difícil. Sus propias páginas dan mínimos distintos. La página de requisitos de GitLab fija 8 vCPU y 16 GB como configuración base para una instalación de un solo nodo, y solo Stack 32 tiene 8 vCPU. Stack 16 tiene los 16 GB con la mitad de núcleos. La misma página dice que GitLab puede funcionar con al menos 8 GB cuando la memoria es limitada, y esa es la única cifra de CPU o memoria de la página que cumple Stack 8. Su guía para entornos con poca memoria baja aún más, hasta 2 GB más 1 GB de swap para un máximo de cinco desarrolladores cuyos repositorios no superen los 100 MB.

Las dos páginas tampoco coinciden en cuanto al swap. En una instalación estándar, GitLab recomienda desactivar el swap o disponer de memoria suficiente para que GitLab nunca lo use, mientras que la configuración de poca memoria da por hecho que el servidor usará swap durante el funcionamiento normal. Para el servidor GitLab de un equipo pequeño, recomendamos Stack 16, que te da la memoria base y 4 de los 8 núcleos; queda por debajo de la configuración base de GitLab, así que una prueba tiene que demostrar que da la talla. GitLab aconseja ejecutar los runners de CI en una máquina distinta de la de GitLab. Prevé un segundo servidor para tus pipelines. Un equipo que necesite la configuración base completa debe ir a Stack 32. El hosting VPS para GitLab incluye GitLab CE en todos los planes Stack.

Supabase

La documentación de autoalojamiento de Supabase considera que su mínimo de 4 GB, 2 núcleos y 40 GB de SSD es adecuado para desarrollo y para cargas de producción pequeñas y medianas, y tanto Stack 4 como Stack 8 lo cumplen. La especificación recomendada pide 4 núcleos o más y, como Stack 16 es nuestro plan más pequeño con 4, ahí es donde ejecutaríamos un proyecto de producción con mucha actividad.

Immich

Stack 8 cumple la recomendación de 8 GB de memoria de Immich con los 2 núcleos mínimos. Stack 16 cumple ambas recomendaciones. Su disco de 250 GB también admite una biblioteca más grande que los 150 GB de Stack 8, algo que puede importar tanto como la memoria cuando importas años de fotos familiares y vídeos del móvil.

Palworld y otros servidores de juegos

La guía de servidores de Palworld indica 16 GB de memoria y recomienda 4 núcleos, así que Stack 16 cumple sus requisitos. Según la guía, un servidor de 8 GB arranca, pero es más probable que se bloquee al quedarse sin memoria; por eso Stack 8 no aparece en la fila de Palworld. La guía también recomienda más de 32 GB. Stack 32 tiene exactamente 32 GB y es el plan Stack más grande, así que un servidor de Palworld que necesite la memoria recomendada debe ir en una máquina dedicada.

Lo que cuesta empezar con un plan demasiado grande

Si empiezas con un plan demasiado pequeño, la solución es cambiar de plan: eliges el plan más grande en el panel y tu entorno se mantiene. Empezar demasiado grande no tiene una solución equivalente. El Centro de ayuda de DreamHost indica que actualmente no puedes bajar a un plan Stack más pequeño, así que la vía que propone es comprobar que tus datos caben, aprovisionar un servidor nuevo con el plan más pequeño, trasladarlo todo, confirmar que funciona y cancelar el original.

Mientras tanto, pagas cada mes por memoria y núcleos que tu aplicación no usa. El Centro de ayuda de DreamHost indica que un VPS no incluye la garantía de devolución de dinero de 30 días, así que no hay plazo de reembolso al que recurrir. Empieza con el plan más pequeño que cumpla el mínimo de tu aplicación y cambia de plan cuando las comprobaciones de abajo muestren que se queda corto.

Cómo saber si tu plan se te ha quedado pequeño

Antes de pagar por un plan más grande, averigua si lo que falta es memoria, CPU o disco, porque cada caso apunta a una mejora distinta. El Centro de ayuda de DreamHost indica que los paneles de rendimiento y registros solo están disponibles en el VPS administrado, así que en un VPS tendrás que comprobarlo desde la línea de comandos mientras la aplicación está en uso. Estos comandos hacen las comprobaciones rápidas:

free -h
cat /proc/pressure/memory
uptime
df -h

1. Comprueba la memoria disponible

   Ejecuta free -h durante el uso normal. La columna available estima cuánta memoria pueden obtener los programas nuevos sin recurrir al swap. Si se mantiene cerca de cero, o el uso de swap no deja de subir, probablemente a la aplicación le falta memoria. Los registros de la aplicación también lo muestran: n8n registra JavaScript heap out of memory cuando un flujo de trabajo se queda sin memoria.

2. Comprueba la presión de memoria

   Ejecuta cat /proc/pressure/memory. La línea full indica la parte del tiempo en que todas las tareas en ejecución esperaban a la vez por memoria, y la documentación del kernel dice que una carga de trabajo que pasa mucho tiempo en ese estado sufre hiperpaginación (thrashing). Si es tu caso, pasa al plan siguiente para tener más memoria: de Stack 4 a Stack 8, de Stack 8 a Stack 16 o de Stack 16 a Stack 32.

3. Compara la carga con tus núcleos

   Ejecuta uptime y fíjate en el tercer número, la carga media de 15 minutos. La carga no se ajusta a tu número de núcleos, así que compárala con las vCPU de tu plan: 2 en Stack 4 y Stack 8, 4 en Stack 16 y 8 en Stack 32. Como regla general, si la carga de 15 minutos se mantiene por encima de esa cifra durante días, nosotros lo tomaríamos como señal de que te falta CPU. Desde Stack 4 o Stack 8, eso apunta a Stack 16.

4. Revisa el tiempo robado

   Ejecuta vmstat 5 y vigila la columna st, que muestra el tiempo que el hipervisor le quitó a tu servidor. Como regla general, si ese tiempo robado se mantiene por encima de un pequeño porcentaje, consulta al soporte antes de pagar por un plan mayor.

5. Comprueba el espacio en disco
   Ejecuta df -h para ver cuánto espacio ocupa cada sistema de archivos.
6. Cambia de plan en el panel

   El Centro de ayuda de DreamHost indica estos pasos: ve a Manage Account, busca tu VPS en Active Plans, haz clic en Manage y luego en Select Plan, dentro de Change Plan, y en Submit Order.

Un swap que crece también puede ser una alerta temprana. Como señaló un comentarista de Hacker News, vigilar el uso de swap puede avisarte de que algo va mal antes de que el kernel empiece a cerrar procesos por falta de memoria.

Si la carga se debe a un pico de tráfico, lee sobre cómo gestionar un pico de tráfico antes de cambiar de plan.

Cuándo te conviene más otro producto de DreamHost

Si prefieres que seamos nosotros quienes administremos el servidor, puede que DreamPress, el VPS administrado o el hosting de servidor dedicado administrado te encajen mejor. Si no tienes claro que necesites un servidor, empieza por ¿de verdad necesitas un VPS?.

El servidor dedicado administrado te ofrece un servidor administrado con root, y su plan Enhanced llega hasta 128 GB de memoria, así que, cuando Stack 32 se te quede pequeño, lee cuándo un servidor dedicado es el siguiente paso. Para sitios nuevos o sencillos, el alojamiento web es el punto de partida, y su plan Launch cubre 25 sitios web y unas 40 000 visitas mensuales estimadas. Si lo que ralentiza los sitios de tu VPS administrado es una base de datos MySQL, el complemento MySQL VPS le da recursos de base de datos aislados como servicio independiente.

Preguntas frecuentes sobre el tamaño del VPS