Alojar servidores de juego en bare metal: por qué gana el hardware dedicado

La respuesta primero: por qué el bare metal gana para servidores de juego

Un servidor de juego no es un servidor web. Ejecuta un único bucle de simulación que hace avanzar todo el mundo del juego a un reloj fijo: física, entidades, jugadores, todo, en orden, en un solo hilo. Minecraft ejecuta ese bucle 20 veces por segundo, lo que le deja 50 milisegundos para terminar cada tick. Si no llega a tiempo, el tick se alarga, el servidor se retrasa y los jugadores lo notan como rubber-banding, impactos que se registran tarde y picos de lag. Así que las cifras que deciden si un servidor de juego va bien son la velocidad por núcleo y la regularidad del timing, no el número de núcleos ni el rendimiento total.

Ese es todo el argumento a favor del bare metal en un párrafo. Un VPS compartido coloca el planificador de un hipervisor entre tu bucle de tick y la CPU física. Cuando un vecino del mismo host se pone a trabajar, tu hilo espera su turno, y esa espera llega como jitter justo cuando un tick tiene que terminar a tiempo. El bare metal te da la máquina entera, sin nada que te quite la CPU para dársela a otro. Para un servidor entre amigos que pasa inactivo la mayor parte del día, nada de esto importa y un VPS vale. Para cualquier servidor con el aforo completo y un presupuesto de tick ajustado, la máquina física gana porque elimina lo único que un bucle de tick no tolera: que otro decida cuándo le toca ejecutarse.

Este artículo trata:

• qué significa «bare metal» frente a un VPS y a un panel de servidores de juego gestionado
• por qué una carga de servidor de juego se comporta de forma distinta a las aplicaciones web para las que se escribe la mayoría de consejos de hosting
• por qué una frecuencia alta supera al número de núcleos en la mayoría de títulos, y los casos en que muchos núcleos compensan
• cuánta RAM necesitan de verdad los servidores más populares, con las cifras públicas de cada uno
• el almacenamiento, las copias de seguridad y la realidad del DDoS al poner la IP de un juego en Internet
• cómo ejecutar un panel como Pterodactyl o su fork Pelican en tu propio hardware
• la lista honesta de casos en los que no merece la pena el bare metal

Si quieres profundizar en el timing, dos artículos complementarios van más allá de este panorama: bare metal frente a máquinas virtuales pone cifras a la diferencia, y por qué importa la latencia en los servidores de juego cubre la parte de red.

Qué significa «bare metal» en la práctica

Hay tres formas de ejecutar un servidor de juego, y lo que las diferencia es quién controla la CPU.

Hosting de servidores de juego gestionado. Alquilas un slot para un juego, el proveedor gestiona el hardware y un panel, y tú recibes una página web con un botón de arranque y un editor de configuración. Es la forma más rápida de tener un servidor en marcha y la que menos te obligará a pensar en la máquina. También te llevas la CPU, la RAM y la red que el proveedor decidió que tocaban a cada slot, en hardware compartido con los slots de otros clientes.

Un VPS. Alquilas una máquina virtual: una porción de un host físico, recortada por un hipervisor como KVM o VMware, o por una capa de contenedores como OpenVZ o LXC. Tienes root y puedes instalar lo que quieras. Lo que no tienes es la CPU entera. El planificador del host da ciclos reales a tus núcleos virtuales cuando están libres, y «cuando están libres» depende de lo que haga cada uno de los demás inquilinos de la máquina.

Bare metal. Alquilas el servidor físico entero. Sin hipervisor, sin otros inquilinos, sin planificador que decida cuándo se ejecuta tu proceso. La frecuencia que figura en la ficha técnica es la que recibe tu bucle de tick, siempre. También te quedas con todo lo que trae una máquina real: toda la RAM, el NVMe, el puerto de red, y las actualizaciones y copias de seguridad que un hosting gestionado se habría encargado de hacer.

Que esta división importe más en los juegos que en la mayoría de cargas se debe a ese planificador, y a cómo usa la CPU un servidor de juego desde el principio.

Por qué la carga de un servidor de juego es poco común

La mayoría de cargas de servidor son máquinas de rendimiento. Un servidor web atiende mil peticiones independientes en todos los núcleos que le des; una base de datos reparte las consultas entre conexiones. Añade núcleos y todo va más rápido. Un servidor de juego hace lo contrario. Hace avanzar un estado del mundo compartido en un orden estricto, porque a dónde se mueve la entidad B en este tick depende de a dónde se movió la entidad A en ese mismo tick, así que el trabajo no se puede repartir entre núcleos sin que la simulación se contradiga. Por eso la mayoría de servidores de juego ejecutan su bucle principal en un solo hilo y solo recurren a unos pocos hilos extra para tareas secundarias como la red, la generación de chunks y la E/S de ficheros.

Ese bucle único trabaja contra un plazo. Los 20 ticks por segundo de Minecraft suponen un presupuesto de 50 ms por tick; otros motores eligen su propia frecuencia, pero el esquema es el mismo. Cuando el trabajo de un tick cabe en su presupuesto, el servidor mantiene el tick rate completo y el mundo responde bien. Cuando no cabe, el tick se pasa de tiempo, el siguiente empieza tarde, y el servidor o baja a un tick rate efectivo menor o acumula lag hasta ponerse al día. Los jugadores lo perciben como un registro de impactos que falla y entidades que se teletransportan. La métrica que lo predice no es la carga media de CPU. Es el peor tiempo para terminar un tick, y el peor caso es justo lo que un planificador compartido vuelve impredecible.

Se suman otros dos rasgos:

• Sensibilidad a la latencia. Un tick que termina a tiempo no sirve de nada si el paquete tarda 120 ms en llegar al jugador. A los servidores de juego les importan el tiempo de ida y vuelta y la calidad de la ruta mucho más que el ancho de banda bruto, y por eso la ubicación del centro de datos y el peering de red importan tanto como la CPU. El artículo sobre latencia desglosa el presupuesto de ida y vuelta por género.
• CPU a ráfagas. La carga no es constante. Una raid contra una base de Rust, un mecanismo de redstone que se dispara, cuarenta jugadores que aterrizan a la vez en el mismo sitio: el tick que tiene que simular todo eso es el que revienta el presupuesto. Se dimensiona para el pico, no para la media.

El enemigo es el jitter, no el rendimiento. Un servidor que termina cada tick en 20 ms salvo un parón de 80 ms por minuto se siente peor que uno que tarda siempre 35 ms, porque ese parón es el momento en que a un jugador le disparan tras una cobertura. Es el mayor motivo por el que compartir host juega en contra de las cargas de juego, y es el tema de bare metal frente a máquinas virtuales.

La frecuencia gana a los núcleos, hasta cierto punto

La conclusión práctica de ese bucle de un solo hilo: para un único servidor de juego, una CPU con menos núcleos pero más rápidos gana siempre a una con muchos núcleos lentos. Nuestra guía de dimensionamiento lo dice sin rodeos: sesenta y cuatro núcleos lentos pierden frente a ocho rápidos, y lo señala como el error de dimensionamiento más común en servidores de juego. Un chip moderno por encima de 5 GHz con un buen rendimiento por núcleo, como el Ryzen 9950X de nuestras configuraciones para servidores de juego a 4,3 GHz de base y 5,7 GHz en boost, termina un tick pesado de Minecraft o Rust antes que una plataforma de servidor de 64 núcleos a 2,5 GHz, tenga los núcleos que tenga el chip grande, porque el bucle solo puede usar uno de ellos a la vez.

Eso no quiere decir que los núcleos sobren. Compensan en cuanto dejas de ejecutar un servidor y pasas a ejecutar muchos:

• Varias instancias. Diez servidores de Minecraft, o un servidor de Rust más un clúster de ARK más unos cuantos mundos de Valheim, son diez o más bucles independientes de un solo hilo. Ahí el número de núcleos vuelve a ser rendimiento: cada instancia recibe uno o dos núcleos propios y se ejecutan en paralelo.
• Un panel. Usar Pterodactyl o AMP para alojar muchos servidores de juego en una sola máquina es, por definición, el caso de muchos núcleos; más sobre ello abajo.
• Trabajo secundario. Incluso un único servidor usa hilos extra para generar chunks, comprimir y hacer copias de seguridad. Tener margen más allá del núcleo principal los mantiene fuera del camino crítico.

La regla es corta: núcleos rápidos para un servidor, más núcleos para muchos. La frecuencia alta es la opción por defecto, y el número de núcleos es lo que añades cuando el trabajo de la máquina es mover una flota y no un solo mundo.

Cuánta RAM necesitan de verdad los servidores más populares

La RAM es donde existen cifras públicas, así que aquí están, sacadas de las recomendaciones de cada juego y del consenso de quienes los operan. Tómalas como cifras por instancia, y recuerda que los plugins, los mods y el número de jugadores hacen subir todas ellas.

Las cifras de Minecraft salen de cómo usa la memoria el servidor Java. Las recomendaciones de ajuste de PaperMC aconsejan arrancar con los flags de Aikar, un conjunto de argumentos para el garbage collector G1, y fijar el heap inicial y el máximo al mismo valor para que la JVM nunca lo redimensione en mitad de un tick. Su propia nota merece repetirse: un heap de 6 GB bien ajustado rinde más que uno de 12 GB mal ajustado, así que aquí más RAM no significa automáticamente más rendimiento. La distancia de visión es el multiplicador que nadie espera, porque cada incremento carga más chunks por jugador y sube tanto la RAM como el coste por tick.

Counter-Strike 2 es ligero en memoria y exigente con el timing. Un servidor limpio ronda los 2,5–3 GB y pasa de 6 GB en cuanto añades plugins, mapas personalizados del Workshop y una plantilla completa de 64 slots. Lo limitan su bucle de tick y la velocidad por núcleo, no la RAM. Valve describe CS2 como un servidor de 64 ticks con una capa de entrada «subtick» que marca cada disparo y cada movimiento con el instante exacto en que ocurrió, con independencia del tick, lo que pone todavía más peso en que el servidor termine su trabajo de forma predecible; la descripción está en la página de Counter-Strike 2 de Valve.

Luego viene el extremo pesado. Los requisitos oficiales de Palworld recomiendan 16 GB, advierten de que con 8 GB «también arranca, pero aumenta la posibilidad de que el servidor se caiga por falta de memoria», y remiten a 32 GB para servidores más grandes. Los operadores cuentan de forma generalizada que su consumo de memoria sube cuanto más tiempo lleva el servidor encendido, y el remedio habitual es un reinicio programado cada pocas horas. ARK: Survival Ascended pesa aún más; los informes de la comunidad sitúan el binario del servidor en 6–10 GB antes de que se conecte nadie, 16 GB como mínimo para un solo mapa y 12–18 GB adicionales por cada mapa extra de un clúster. Rust queda en medio, con 8–16 GB según el tamaño del mapa y la población, y, al ser un servidor Unity, depende tanto de la frecuencia como de la RAM. Valheim es el más modesto: su propia documentación indica un mínimo de 2 GB, aunque 4–8 GB es la cifra holgada para un grupo pequeño en un mundo de larga duración.

Dos reglas valen para todos. Dimensiona para la noche de más actividad, no para la tarde vacía; y deja margen, porque un servidor de juego que se queda sin RAM no se ralentiza con suavidad: se cae o el kernel lo mata en plena sesión. La guía de dimensionamiento repasa en términos generales las cuentas del margen.

Almacenamiento: NVMe, guardados del mundo y copias de seguridad

Un mundo de juego es un almacén de chunks o regiones que el servidor lee y escribe sin parar a medida que los jugadores se mueven por él. En un disco mecánico, esa E/S aleatoria se convierte en lo que notan los jugadores cuando una zona nueva da tirones al cargar. La respuesta es el NVMe, y en un servidor de juego no es un lujo. La carga de chunks, los guardados del mundo y las escrituras de datos de jugadores caen todas en el camino del tick o cerca de él, y la latencia de lectura aleatoria del NVMe está en otra categoría que la de los SSD SATA, no digamos ya la de los discos duros.

Los guardados del mundo son la parte que se subestima. Un mundo concurrido de Minecraft o Rust puede llegar a decenas de gigabytes, y el guardado periódico escribe en disco una buena parte de ellos. En un disco lento, el propio guardado provoca un pico de lag; en NVMe termina lo bastante rápido como para quedar fuera del camino crítico. La documentación de Palworld lo dice sin rodeos, al advertir que un almacenamiento de bajo rendimiento «puede corromper los datos guardados».

Las copias de seguridad van aparte del disco rápido y no son opcionales. Un mundo está a un apagado brusco de perderse, y un mundo destrozado por griefers o que hay que devolver a un estado anterior se restaura, no se repara. La disciplina es fácil de enunciar: snapshots frecuentes, guardados en un sitio que no sea la misma unidad, y probados al menos una vez para saber que la restauración funciona. Las copias fuera de la máquina cubren además el fallo que el NVMe rápido no cubre: que muera la propia unidad. Un RAID 1 con dos unidades NVMe te mantiene en marcha si falla una, pero no es una copia de seguridad, porque replica fielmente un borrado o una corrupción en las dos unidades en el mismo instante.

La red y la realidad del DDoS

Poner un servidor de juego en una IP pública es publicar un objetivo. Los servidores de juego atraen ataques de denegación de servicio más que casi cualquier otra carga, por un motivo concreto: los jugadores conocen la IP, los juegos funcionan sobre UDP, y un rival, un tramposo baneado o un servicio de booter de pago pueden lanzarle un flood sin ninguna habilidad. Los floods UDP son la forma más habitual, porque el UDP no tiene handshake sobre el que limitar la tasa y su tráfico es fácil de falsificar y amplificar.

Aquí es donde una conexión doméstica o un VPS sin protección se vienen abajo. Una línea de consumo no tiene capacidad para absorber un flood ni ningún filtrado aguas arriba, así que el ataque satura el enlace y todos los jugadores se desconectan, llegue o no a tocarse el proceso del servidor. La mitigación tiene que ocurrir en la red, delante del servidor, donde hay capacidad suficiente para absorber el volumen y un filtrado que descarta los paquetes malos mientras deja pasar el tráfico UDP real del juego. Cómo funcionan estos ataques y las defensas contra ellos se explica en tipos de ataques DDoS y protección.

Dos apuntes prácticos. Un filtrado que entienda de juegos importa, porque las reglas DDoS genéricas que funcionan para una web pueden romper un juego: un filtro contra floods UDP tiene que saber cómo es el tráfico legítimo del juego, o descartará jugadores reales junto con el ataque. Y la máquina sigue necesitando bastionado a nivel de host, haya o no protección aguas arriba, porque un flood no es la única amenaza para un servidor público; la checklist de bastionado de servidores Linux es la base de la primera hora.

Ejecutar un panel en tu propio hardware

En cuanto gestionas más de uno o dos servidores, vas a querer un panel en lugar de un montón de sesiones de tmux y scripts de shell. Hay tres que conviene conocer.

Pterodactyl es el estándar de código abierto. Se divide en dos partes: el Panel, una aplicación web en PHP que necesita una base de datos (MySQL 8.0+ o MariaDB 10.6+), un servidor web e, idealmente, Redis; y Wings, el daemon que ejecuta cada servidor de juego dentro de un contenedor Docker en el host. Ese requisito de Docker es el detalle que decide tu hardware. Wings necesita un host Linux capaz de ejecutar Docker, y la propia documentación de Pterodactyl advierte que los VPS basados en contenedores, OpenVZ, LXC y Virtuozzo, normalmente no pueden ejecutar Docker en absoluto; KVM es el único que garantizan. En bare metal la pregunta ni se plantea, porque el kernel es tuyo.

Pelican es un fork de Pterodactyl, iniciado en 2024, que cambió la licencia del panel de MIT a AGPLv3. Su FAQ reconoce abiertamente que en 2026 sigue siendo software en beta, así que tómalo como la opción que avanza deprisa: elígelo si quieres el ritmo de desarrollo más reciente y puedes convivir con una beta, y quédate en Pterodactyl si prefieres la versión más asentada. Los dos siguen la misma arquitectura de panel más daemon y el mismo requisito de Docker, así que en cuanto a hardware no hay diferencia entre ellos.

AMP, el Application Management Panel de CubeCoders, es la alternativa comercial. Es de pago, funciona tanto en Linux como en Windows, y cambia la licencia de código abierto por acabado y soporte. Si prefieres comprar un producto con soporte a montar tú la pila, es el que debes mirar.

Los tres convierten un único servidor dedicado en un host de juegos multiinquilino, que es el caso de muchos núcleos de antes llevado a la práctica. Cada instancia de juego es su propio bucle de un solo hilo, así que una máquina con un panel necesita a la vez frecuencias altas, para que el bucle de tick de cada instancia siga siendo rápido, y suficientes núcleos y RAM para ejecutar varias a la vez sin que sus bucles se peleen por el tiempo de CPU. Dimensionar la máquina consiste en sumar las cifras de RAM por instancia de la tabla anterior, más unos cuantos gigabytes para el panel y el host, y después elegir un número de núcleos que cubra tus instancias más cargadas funcionando todas a la vez.

En nuestro catálogo, la configuración para un panel y de cinco a diez servidores es el Ryzen 9 9950X: 16 núcleos a 4,3 GHz de base y 5,7 GHz en boost, 192 GB de DDR5, una unidad NVMe de 1,92 TB y red de 10 Gbit/s, anunciado a 415 $ al mes el 24 de septiembre de 2026 (el listado de servidores de juego muestra el precio y el stock de hoy). Haciendo las cuentas con la tabla de RAM, ocho instancias suman 92 GB: dos servidores de Rust a 16 GB, tres servidores de Minecraft con mods a 12 GB y tres servidores de CS2 de 24 jugadores a 8 GB. Añade unos gigabytes para el panel y el host y la máquina queda algo por encima de la mitad de su memoria, con sitio para un mapa de ARK de 32 GB. Cada uno de los ocho bucles de tick tiene un núcleo para él solo, y los otros ocho se encargan de generar chunks, los guardados y las copias de seguridad. Con una sola unidad, las copias fuera de la máquina de la sección de almacenamiento son toda la respuesta a un fallo de disco.

Cuándo no necesitas bare metal

El bare metal es la herramienta correcta para un servidor con el aforo completo y un presupuesto de tick ajustado. Es la herramienta equivocada en muchos casos reales, y fingir lo contrario te costaría dinero.

Un VPS es mejor opción cuando:

• Sois unos pocos amigos. De tres a cinco personas en un Valheim vanilla o un SMP pequeño de Minecraft apenas cargan la máquina, y algún milisegundo suelto de jitter del planificador no se nota a esa escala. El mínimo de 2 GB de Valheim funciona sin problemas en un VPS pequeño.
• Es una sola instancia ligera. Un servidor con poca gente para un juego que no exige mucha CPU no necesita una máquina física entera para él. Estarías pagando núcleos que no hacen nada.
• Es una máquina de pruebas o desarrollo. Algo que levantas, rompes y vuelves a desplegar no gana nada con hardware dedicado. Lo barato y desechable se impone.
• Tiene picos y casi siempre está inactivo. Un servidor vacío la mayor parte de la semana y lleno una noche de raid es justo el patrón para el que están pensados los precios de una plataforma compartida.

El punto de cruce llega cuando el servidor tiene suficiente actividad, con suficiente frecuencia, como para que el presupuesto de tick empiece a apretar; o cuando las necesidades de RAM pasan del punto en que el precio de un dedicado mejora al de un plan VPS equivalente; o cuando la IP pública de un juego necesita protección DDoS de verdad por delante. Por debajo de esa línea, un VPS no es un término medio: es la respuesta correcta.

Tabla de decisión rápida

Dónde cae cada escenario y el factor que lo decide:

Desplegar en Serverside.com

Un servidor de juego premia las dos cosas que el bare metal hace bien: darle a un proceso toda la CPU, y rápida, y estar detrás de una red capaz de aguantar un golpe. Una máquina de Serverside.com para servidores de juego funciona en nuestra propia red (AS55285), con mitigación DDoS siempre activa delante del puerto UDP público y perfiles de filtrado ajustados por título, de modo que el flood que tumbaría un servidor alojado en casa nunca llega al bucle de tick. Las configuraciones de alta frecuencia, como el Ryzen 9950X, están elegidas justo para el bucle de un solo hilo del que trata este artículo, y el aprovisionamiento tarda menos de un minuto, así que una máquina nueva está en marcha antes de que termines de planificar el mundo que va a ejecutar.

Si estás valorando el hardware en general, la gama completa de servidores dedicados y la guía de dimensionamiento cubren el resto, y elegir una ubicación cercana a tus jugadores es una palanca de rendimiento por sí misma; nuestro centro de datos de Ámsterdam es el punto de anclaje europeo. Una vez que la máquina sea tuya, la checklist de bastionado es lo primero que debes aplicarle.

FAQ

¿Necesito bare metal para un servidor de juego o me basta con un VPS?

Depende de la carga. Para unos pocos amigos en un mundo vanilla, un VPS basta y sale más barato. El bare metal gana cuando el servidor funciona con el aforo completo y un presupuesto de tick ajustado, porque un VPS compartido coloca el planificador de un hipervisor entre tu bucle de tick y la CPU, y eso se nota como jitter justo cuando un tick tiene que terminar a tiempo.

¿Por qué importa más la frecuencia de reloj que el número de núcleos en un servidor de juego?

Porque un servidor de juego ejecuta su bucle de simulación en un solo hilo. El mundo avanza en orden, un tick tras otro, y ese trabajo no se puede repartir entre núcleos. Un núcleo más rápido termina cada tick antes, mientras que los núcleos adicionales quedan sin uso por parte del bucle principal. Más núcleos solo empiezan a ayudar cuando ejecutas muchas instancias, o un panel que aloja varios servidores a la vez.

¿Cuánta RAM necesita un servidor de juego?

Varía mucho según el título. Valheim funciona con 2 GB, un servidor Minecraft con Paper con 3–4 GB para un grupo pequeño, Rust con 8–16 GB, y tanto Palworld como ARK: Survival Ascended con 16 GB o más por instancia. Dimensiona para un servidor lleno en una noche de mucha actividad y deja margen, porque un servidor de juego que se queda sin RAM se cae en lugar de simplemente ir más lento.

¿Puedo ejecutar Pterodactyl en un VPS?

Solo en el tipo adecuado. El daemon Wings de Pterodactyl ejecuta cada servidor dentro de un contenedor Docker, y los VPS basados en contenedores como OpenVZ y LXC normalmente no pueden ejecutar Docker en absoluto. Un VPS KVM funciona, y un servidor dedicado funciona siempre porque el kernel es tuyo. Si piensas alojar muchos servidores detrás de un panel, el bare metal es de todos modos su sitio natural.

¿De verdad atacan con DDoS a los servidores de juego?

Sí, más que a la mayoría de cargas de trabajo. Los jugadores conocen la IP, los juegos funcionan sobre UDP y lanzar un flood no requiere ninguna habilidad. Una línea doméstica o un VPS sin protección se satura y todos los jugadores se desconectan. La mitigación tiene que estar en la red, delante del servidor, con capacidad para absorber el volumen y un filtrado capaz de distinguir el tráfico del juego de un ataque.