¿Cuánta RAM necesita tu servidor de Minecraft?

En 2015, un padre preguntó a una empresa de hosting en Hacker News si su plan de 1 GB dejaba el gigabyte entero para Minecraft o si el sistema operativo se quedaba con parte. Quería un servidor para sus hijos y los amigos de sus hijos y, como él mismo decía, un servidor de Minecraft necesita 1 GB solo para él.

En un servidor de Pelican Panel de 16 GB, la respuesta sigue siendo no. Unos 2 GB se van al sistema y al panel antes de que cargue tu mundo, y Java necesita memoria más allá de la cifra que le asignas.

Los requisitos de esta página vienen de quienes crean el software: la Minecraft Wiki, Paper, los archivos de servidor de los propios creadores de los modpacks y el código fuente de Pelican. La reserva de 2 GB y el margen que deja cada plan son cifras que hemos estimado nosotros. También ejecutamos Minecraft en nuestra propia máquina de pruebas (no en un servidor de DreamHost) para ver cuánto ocupa un ajuste de memoria; lo verás más abajo. Parte de la tabla y revisa la memoria cuando tu grupo ya esté jugando.

Memoria según lo que juega tu grupo

Busca la fila que coincida con lo que juega tu grupo. Cada plan de la columna derecha reserva unos 2 GB para Debian, el panel, Docker y Wings. Wings es el servicio de Pelican que ejecuta cada servidor de juego en su propio contenedor. Pelican no publica ninguna cifra, así que esos 2 GB son nuestra estimación para planificar. Después, Wings permite que el contenedor de cada servidor use entre un 5 y un 15 % más de la memoria que escribes; la parte mayor corresponde a los servidores de 4 GB o menos.

Descontando ambas cosas, te queda espacio para unos 1,7 GB de servidores de juego en Stack 4, 5,7 GB en Stack 8, 13,3 GB en Stack 16 y 28,6 GB en Stack 32.

La Wiki es la única fuente que relaciona la memoria con el número de jugadores. Y solo lo hace para vanilla en un mundo nuevo con la distancia de visión predeterminada. Su tabla principal lleva el encabezado since 1.11.2, una versión de hace años, así que toma Stack 4 como plan de partida para un mundo nuevo pequeño. Su tabla para servidores Linux va más allá: hasta 6 GB para 20 o más jugadores. Paper y los creadores de modpacks dimensionan según el software, así que el número de jugadores no cambia su cifra. No hay ninguna cifra oficial para vanilla con unos pocos mods, así que planifica según la fila del modpack ligero y su mínimo de 4 GB.

Stack 8 es la opción más ligera para Paper. Deja unos 5,7 GB, por debajo del mínimo de 6 GB de Paper antes de que Java se lleve su parte. La página de introducción de Paper arranca su servidor de ejemplo con 4 GB. Un grupo pequeño con un solo mundo de Paper puede empezar en Stack 8 y subir de plan cuando falte memoria. Si usas Purpur, es un sustituto directo de Paper, y la cifra de Paper también le sirve.

Por qué los mods importan más que los jugadores

La tabla de la Wiki da por hecho un mundo recién creado. Su propia nota al pie dice que un mundo grande con maquinaria de redstone, granjas y trampas de mobs can easily more than double the requirements. Si tu grupo lleva un año construyendo en el mismo mundo, planifica por encima de la tabla.

El paquete de servidor de All the Mods 10 es uno de los más grandes que existen y, aun así, su script de inicio reduce la distancia de visión y de simulación por debajo del valor predeterminado del juego, que es 10. La Minecraft Wiki sugiere bajar la distancia de visión cuando los jugadores tienen lag. En tu propio servidor, empieza con los valores predeterminados y bájalos hacia los del paquete si falta memoria o cae la tasa de ticks.

Los paquetes más nuevos piden más memoria que los antiguos. Ocho de los diez paquetes de la lista de más instalados de FTB, todos creados para versiones antiguas de Minecraft, piden 4 GB como mínimo y 6 GB recomendados. Sus paquetes para Minecraft 1.21 y posteriores indican sobre todo 6 GB y 8 GB. FTB da una cifra mínima y otra recomendada por paquete sin aclarar si son para el servidor o para tu propio ordenador. En cambio, los archivos de servidor de All the Mods 10 fijan el límite de Java en el propio servidor.

Unos investigadores de la Vrije Universiteit Amsterdam midieron de dónde viene el lag. El estudio Meterstick ejecutó vanilla, Forge y Paper en mundos de Minecraft 1.16. Sus máquinas en la nube tenían 2 vCPU y 8 GB de memoria, la misma configuración que Stack 8, y Java estaba limitado a 4 GB.

El mundo importó más que el número de jugadores. Las granjas y la dinamita hicieron el juego mucho menos estable que 25 jugadores emulados, y las entidades ocupaban la mayor parte de cada tick con carga. En ese estudio, Paper fue en general más estable que vanilla y Forge. Los retrasos llegaron a 20,7 veces la media, y los peores se produjeron justo después de que se conectara un jugador.

Qué hace Pelican con la memoria que escribes

Cuando creas un servidor en Pelican, escribes una cifra de memoria para él. Wings añade un 15 % a esa cifra en servidores de hasta 2 GB, un 10 % hasta 4 GB y un 5 % por encima de 4 GB. Usa el total como límite estricto del contenedor. El código fuente de Wings explica que ese extra existe porque Java no siempre se mantiene por debajo de su límite.

Los eggs de la comunidad de Pelican para Paper y Minecraft vanilla inician Java con -XX:MaxRAMPercentage=95.0. Eso permite que el heap crezca hasta el 95 % del límite del contenedor, así que, según nuestros cálculos, ambos ajustes casi se anulan. Si escribes 6144 MB, el heap podrá llegar a unos 6129 MB, lo que deja unos 322 MB para todo lo demás que hace Java.

Los consejos de memoria de Paper piden de 1000 a 1500 MB de ese margen. Su ejemplo: con 8 GB, usa 6500 MB para el heap.

Para mantener un heap de 6 GB y darle a Java ese margen, sube la memoria que escribes y baja el 95 en el comando de inicio de tu servidor. Si escribes 7000 MB y lo pones en 85, quedarán unos 1100 MB fuera de un heap de unos 6248 MB.

Esta es nuestra interpretación del código de Pelican y de la documentación de Paper, así que vigila la memoria después del cambio. Este margen sale de la cifra de cada servidor, y la reserva de 2 GB del plan se mantiene igual.

En Stack 16, ese mundo de Paper y un mundo vanilla de 4 GB ocupan unos 11,6 GB de contenedores, dentro de los 14 GB que quedan tras la reserva. Dos mundos de Paper configurados igual necesitarían unos 14,4 GB, así que solo cabrían si escribes menos para cada uno.

Cuánta memoria usó cada ajuste en nuestra máquina de pruebas

El 22 de octubre de 2026 ejecutamos Minecraft en dos de nuestras máquinas de prueba (no son servidores de DreamHost) con 2 vCPU (arm64), una con 4 GB y otra con 8 GB. Los servidores fueron vanilla 26.1 y Paper 26.1.2, con la imagen de Docker minecraft-server de itzg, una imagen de la comunidad muy utilizada, en lugar del egg de Pelican, y con jugadores de prueba (bots) que se repartían por el mundo.

Con los parámetros predeterminados, el servidor vanilla de 2 GB arrancó cerca de 1 GB. Cuando cuatro jugadores se dispersaron, superó su ajuste en unos 300 MB y conservó esa memoria cuando se fueron. Con los parámetros de Aikar, que usan muchos proveedores de hosting, el servidor ocupó todo su ajuste nada más arrancar, hubiera o no alguien conectado.

En cualquier caso, cuenta con el ajuste más unos 300 a 500 MB para Java. Es menos que los 1000 a 1500 MB que aconseja Paper, pero nuestra prueba fue corta y ligera, así que mantenemos la cifra de Paper en la tabla anterior. Nuestros bots se adentraron en terreno nuevo y no construyeron nada, así que un grupo con granjas y redstone dará otros resultados. En la prueba de Paper solo hubo un jugador conectado, porque el limitador de conexiones de Paper rechazó a los demás, así que solo la usamos para la memoria. Aun así, muestra por qué Stack 8 se queda justo para Paper: un ajuste de 6 GB dejó menos de 1 GB libre en una máquina de 8 GB, sin contar ningún panel.

¿RAM o CPU? Fíjate en el síntoma

Minecraft hace avanzar su mundo en ticks: 20 por segundo, es decir, uno cada 50 milisegundos. Cuando tu servidor no termina un tick a tiempo, la tasa de ticks baja y todo se ralentiza. Según la Wiki, el mundo sigue procesándose en gran parte en un único hilo principal. El servidor usa como mucho unos tres núcleos, así que importa más un núcleo rápido que muchos.

Según advierte la documentación de Paper, cuando falta memoria el servidor puede quedarse sin ella o ser cerrado por el OOM killer del sistema, el proceso que mata programas cuando se agota la memoria. Si hay lag mientras sobra memoria libre, el problema apunta a la CPU. En Paper, el perfilador spark incluido muestra qué consume cada tick. Ejecuta /spark profiler start --timeout 600 mientras se produce el lag y, al cabo de 10 minutos, te devolverá un enlace al informe. Desde la shell del servidor, dos comandos de Linux cubren la memoria y la carga:

free -h
uptime

La columna available de free -h indica cuánta memoria pueden usar todavía los programas nuevos sin recurrir al swap. uptime termina con la carga media de 1, 5 y 15 minutos. Esa cifra no está dividida entre el número de CPU, así que tendrás que compararla tú con tu plan. Una carga a 15 minutos cercana a 2 en Stack 8 significa que las dos vCPU están ocupadas. En Stack 16, esa misma carga usa la mitad de sus 4. Una carga cercana a 1 con lag puede deberse igualmente a un hilo principal saturado, algo que mostrará un informe de spark.

Cuando el plan se te queda pequeño

Subir de plan es un cambio de plan en el panel, y tu servidor se viene contigo. El Centro de ayuda explica cómo mejorar el plan en el panel. También puedes añadir capacidad de juego en un segundo servidor con la plantilla Additional Wings Node. No tiene panel ni inicio de sesión propios.

Tus mundos se guardan en el disco raíz del servidor, y las copias de seguridad corren de tu cuenta. Si todavía estás eligiendo entre tu propio servidor, un proveedor de hosting de juegos y Realms, consulta cuánto cuesta un servidor de Minecraft para un grupo. Para el panel en sí, lee Pelican vs. Pterodactyl. La guía de planes explica cómo dimensionar otras apps en un VPS.

Preguntas frecuentes sobre la RAM de un servidor de Minecraft