Servidor Minecraft SMP en 2026 - Guía para Crear y Configurar

Mi primer "SMP propio" vivió en un chat de Skype del octavo grado. El formato no murió. En 2026 el SMP ya es una subcultura: canales de YouTube con medio millón de suscriptores, streams en Twitch donde gente ve a otra gente cavando en una mina, servidores de Discord con 50 mil miembros.

Técnicamente un SMP es solo un servidor de supervivencia con plugins. Sin minijuegos, sin lobby, sin kits de pago. Solo un mundo y gente dentro. Pero construir un SMP al que los jugadores sigan entrando un mes después del lanzamiento es trabajo de verdad. Hacia el sexto mes aparecen problemas totalmente distintos, y la mayoría de guías los omite.

Este artículo no va de "arranca el jar y listo". Va de un SMP duradero, que sobrevive a la primera oleada de griefers, al primer ataque de bots y al salto de 10 a 50 jugadores simultáneos.

Cuánto hardware necesitas de verdad

Las respuestas de foro tipo "con 4 gigas te va" suelen mentir. La versión honesta:

Minecraft es casi mono-hilo. El tick principal corre en un solo hilo, y 32 núcleos no van a acelerarlo. Lo que pesa: frecuencia de CPU, ancho de banda de memoria, IOPS del disco durante el auto-save.

Tabla honesta para SMP con plugins:

Online	RAM del servidor	CPU	Disco
5-10	4 GB	1 núcleo a 3,5+ GHz	20 GB SSD
10-20	6-8 GB	1 núcleo a 4+ GHz	40 GB SSD
20-50	10-12 GB	1 núcleo a 4,5+ GHz	80 GB NVMe
50-100	14-20 GB	1 núcleo a 5+ GHz o Folia	150 GB NVMe
100+	Folia o sharding	conversación aparte	NVMe RAID

Detalle importante: asignar más de 14-16 GB a una sola instancia de Java normalmente no sirve. El recolector de basura se atraganta con heaps grandes. Si necesitas más, cambia el core a Folia (multi-hilo), o divide a los jugadores entre varios backends con Velocity.

El disco es lo más subestimado. Un mundo SMP de seis meses con cien jugadores pesa 20-40 GB. Más los backups, más los logs del sistema. Compra 1,5x de lo que crees que necesitas. Análisis de RAM en este post.

Elección del core: más amplia que Paper vs Fabric

En 2026 la elección es más amplia, y cada core tiene fortalezas reales.

Paper es el estándar para SMP. Un fork de Spigot con montones de optimizaciones y desarrollo activo. Miles de plugins apuntan a él. Si no sabes qué elegir, elige Paper.

Purpur es un fork de Paper con ajustes extra. Regular la velocidad de crecimiento de árboles, deshabilitar explosiones por bioma, tocar HP de mobs. Si te gusta mover perillas, Purpur te da más. 100% compatible con plugins de Paper.

Pufferfish es otro fork de Paper enfocado en rendimiento. Pathfinding de mobs reescrito, entrega de chunks optimizada. En servidores grandes supera a Paper en 5-15% de TPS. Contra: los releases para nuevas versiones de Minecraft llegan con un retraso pequeño.

Folia es otra categoría. El mismo Paper, pero las regiones del mundo corren en paralelo en distintos núcleos. Suena a sueño, pero hay truco: la mayoría de plugins no funciona out of the box. Revisa cada plugin contra la lista de compatibilidad de Folia antes de migrar. Análisis completo aquí.

Fabric es un loader de mods, no una plataforma de plugins. Para SMP con mods como Create, Iris Shaders o Ad Astra, Fabric encaja. Pero los mods deben estar en el cliente también. Eso corta al 90% de los jugadores potenciales. Para un SMP público, Fabric solo tiene sentido si tu audiencia ya juega con mods.

Quilt es un fork de Fabric que ejecuta los mismos mods pero con su propio sistema de hooks. Audiencia menor, plan ambicioso.

Resumen: para el 99% de SMPs toma Paper o Purpur. Si apuntas a 80+ simultáneos, mira Folia. Si quieres mods serios, Fabric.

Java y flags de JVM: no copies a ciegas

Minecraft 1.21.x necesita Java 21. Adoptium Temurin es gratis y probado:

sudo apt install temurin-21-jdk
java -version

Ahora las flags. Por internet circulan las "flags de Aikar". Es un conjunto de parámetros de G1GC que realmente funciona mejor que los defaults de JVM:

java -Xms8G -Xmx8G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
  -jar paper.jar --nogui

Dos cosas que importan:

Xms = Xmx es obligatorio. Muchos admins ponen Xms más bajo "para ahorrar memoria". Mal. La JVM va a expandir el heap y gastar CPU en eso. Compromete el tamaño objetivo desde el inicio.

Las flags de arriba están calibradas para 4-12 GB. Arriba de 16 GB sube G1NewSizePercent y G1MaxNewSizePercent a 40/50. Copiar flags de un post de foro de 2019 es error.

Si tienes más de 12 GB, piensa en cambiar G1GC por ZGC. ZGC casi no tiene pausas incluso en heaps grandes. Flag -XX:+UseZGC, eso es todo. Cuesta un poco más de CPU, a cambio te olvidas de las pausas de GC. Profundizar aquí.

server.properties: campos que de verdad importan

La mayoría de server.properties está bien con defaults. Estos campos vale entenderlos:

view-distance=8
simulation-distance=6

view-distance es cuántos chunks ve el cliente. simulation-distance es en qué chunks los mobs, plantas y granjas tickan de verdad. La diferencia importa. Los mobs solo aparecen dentro de simulation-distance. Poner ambos en 10 hace llorar a la CPU. 8/6 es un balance sólido para SMP público.

spawn-protection=0

Por defecto el spawn está protegido de no-ops en 16 bloques. Con GriefPrevention o WorldGuard es redundante y estorba. Ponlo en 0.

online-mode=true
enforce-secure-profile=true

online-mode=true significa que Mojang verifica la autenticación del jugador. Déjalo activo salvo que estés corriendo un servidor cracked a propósito. El modo offline y sus riesgos aquí aparte.

max-tick-time=60000

Timeout del watchdog. Default 60 segundos. En CPU potente puedes subirlo a 120000 para sobrevivir generación pesada de chunks sin bucle de crash.

Luego paper-world-defaults.yml. Cientos de opciones, pero para SMP estas pesan:

entities:
  spawning:
    per-player-mob-spawns: true

Distribuye el cap de mobs entre jugadores. Sin esto, un jugador con granjas se come el cap entero y el resto no ve mobs. En SMP es obligatorio.

chunks:
  max-auto-save-chunks-per-tick: 24

Chunks guardados por tick. Default 24 está bien en la mayoría de casos. En disco lento baja a 8-12.

Guía más amplia de seguridad y tuning de Paper aquí.

Pre-generación: por qué y las cuentas

Cuando un jugador entra a un chunk nuevo, el servidor lo genera al vuelo. Generar un chunk cuesta milisegundos de CPU. Un jugador, no pasa nada. 30 jugadores dispersándose en distintas direcciones, TPS cayendo.

Solución: generar el mundo antes. Plugin Chunky:

/chunky world world
/chunky radius 5000
/chunky start

Un radio de 5000 bloques tarda 30-90 minutos en CPU moderna. Después los jugadores pueden deambular a donde quieran sin cortes de generación.

Las cuentas: radio 5000 son 625 chunks por lado, unos 400 mil chunks. En disco son 10-15 GB para el overworld. Más el Nether (usualmente 1/8 del tamaño) y el End.

Truco práctico: lanza el pregen el día anterior al lanzamiento. Mientras el mundo se hornea, configuras plugins y preparas eventos en el spawn.

Protección de terreno: tres bandos

GriefPrevention es ridículamente simple. El jugador agarra una pala de oro, clic en dos esquinas, terreno reclamado. Cero comandos. Bloques iniciales, bonus con tiempo de juego. Para el 90% de SMPs es la elección correcta. Gratis, estable, con historia larga.

Lands es más moderno y premium. GUI, guerras, alquiler, impuestos, flags por chunk. Bonito, pero de pago (unos 20 euros en Polymart). Vale la pena si el servidor es serio.

Towny va de ciudades y naciones. Los jugadores fundan asentamientos, pagan impuestos, contratan ciudadanos. Una mecánica encima de los claims. Perfecto para SMP con roleplay. Exagerado para SMP de amigos.

Camino típico: arranca con GriefPrevention y migra a Lands cuando el online crece. La migración es molesta pero posible con sus propias herramientas. Más sobre protección anti-grief aquí.

CoreProtect: no vayas a producción sin esto

Plugin que registra cada acción de cada jugador en SQLite. Puso un bloque, rompió uno, abrió un cofre, sacó un ítem, se puso armadura. Todo queda grabado.

Config base:

use-mysql: false
default-radius: 10
api-enabled: true
rollback-items: true
rollback-entities: true
skip-generic-data: true
lang: "en"

Usos reales:

/co inspect

Modo inspección. Clic en un bloque roto, te dice quién lo rompió y cuándo.

/co rollback u:Pupkin t:1h r:50

Revierte las acciones de Pupkin de la última hora en un radio de 50 bloques. Comando favorito después de que un amigo "renovó" tu base con TNT.

/co lookup u:Pupkin a:container

Todas las interacciones de Pupkin con contenedores. Oro para investigar robos.

CoreProtect guarda 30 días por defecto. En servidor grande son gigas. Configura la rotación o limpia a mano:

/co purge t:30d

Anti-cheat: Grim o Vulcan

Debate eterno, lo cerramos.

Grim es gratis, código abierto, simula el movimiento del jugador en el servidor. Atrapa Speed, Fly y KillAura casi perfecto. Requiere online-mode y Paper actual. En offline una parte de las comprobaciones se cae.

Vulcan es de pago (unos 20 euros), código cerrado, misma base más heurísticas. Un poco menos de falsos positivos, mejor ajuste fino. Recomendado para servers de PvP.

En SMP donde PvP es secundario, Grim cumple. Esos 20 euros van mejor a backups o al dominio.

Regla: no corras dos anti-cheats a la vez. Pelean entre ellos y los dos trabajan peor. Elige uno.

Anti-bot: los plugins no bastan

Un SMP con 30+ online tarde o temprano recibe un ataque de bots. Alguien lanza 500 bots que se conectan al servidor y floodean el chat o simplemente ocupan slots.

Plugins como AntiVPN o IPWhitelist pillan bots tontos. Los bots serios imitan a jugadores reales lo bastante bien como para que el plugin no los distinga. Completan el handshake, responden keep-alive, mueven la cabeza.

Protección real es un captcha a nivel proxy, antes de que el bot llegue a tu Paper. Mecánica simple: IP desconocida cae en una página de captcha, lo resuelve, y solo entonces se reenvía al servidor. Jugador legítimo ve el diálogo una vez cada 30 días. Mecánica detallada aquí.

La diferencia importa: un plugin gestiona al bot después de que ocupó slot, comió banda y mantuvo la conexión. Un proxy gestiona al bot antes de que toque Paper. Capas distintas de defensa.

Voice chat: cambia la sensación

El voice cambia un SMP de raíz. Las cuevas dan más miedo. Las granjas son más divertidas. Las peleas de PvP son más vivas. Los nuevos se integran más rápido.

Plasmo Voice necesita mod en el cliente, pero da audio 3D, grupos, walkie-talkies, disfraz. Requiere Fabric/Forge o un loader de mods sobre Paper. Guía completa aquí.

Simple Voice Chat también va por mods, un poco más simple, se instala en 10 minutos. Para Paper puro hay un plugin puente.

En SMP de amigos, Discord alcanza. En SMP público, voice dentro del juego es una ventaja real.

Mapa del mundo: BlueMap vs Dynmap

BlueMap renderiza el mundo en 3D con un visor web. Precioso, parece el mundo real. Más pesado al instalar, más CPU al renderizar.

Dynmap es un mapa 2D plano. Rápido, ligero, se monta en 5 minutos. Parece Google Maps con chunks.

Combinación habitual: BlueMap para la página "mira nuestro mundo", Dynmap para "dónde vive Pupkin". Los dos corren a la vez sin conflicto.

Una economía que no muere en un mes

Colapso clásico en SMP: empiezas con 1000 monedas, tienda NPC de esmeraldas, subasta. En un mes la esmeralda vale 1 moneda y el único ítem valioso es un Faro con Prisa 2. Economía reventada.

Tres reglas para una economía viva:

El dinero tiene que salir. Si las monedas solo aparecen (venta de recursos a NPC) y nunca desaparecen, la inflación es segura. Mete sumideros: impuestos de terreno, coste de teletransporte, reparación, compras únicas.

Nada de diamantes de la nada. No vendas recursos raros por NPC. Todo lo que un jugador pueda "imprimir" rompe el balance.

Subasta abierta por encima de tiendas NPC. Los jugadores deben comerciar más entre ellos que con el servidor. AuctionHouse o ShopGUI+ en modo jugador-a-jugador.

Análisis completo aquí.

Backups: 3-2-1 y simulacro de restore

Regla 3-2-1: tres copias de datos, dos tipos de soporte, una copia fuera del sistema principal.

En la práctica para SMP:

1. Snapshot del mundo cada hora (plugin o cron más rsync). Vive en el mismo disco.
2. Copia nocturna en un segundo disco o un bucket compatible con S3.
3. Copia semanal a la nube (Backblaze B2, Wasabi). Barato y seguro.

Script simple para cron:

#!/bin/bash
WORLD_DIR="/opt/mc"
BACKUP_DIR="/backup/mc"
DATE=$(date +%F_%H-%M)
cd "$WORLD_DIR" && tar czf "$BACKUP_DIR/world_$DATE.tar.gz" world world_nether world_the_end
find "$BACKUP_DIR" -name "world_*.tar.gz" -mtime +30 -delete

Lo que la mayoría se salta: simulacros de restore. Una vez al mes, despliega el último backup en una instancia de test. Confirma que el archivo no está corrupto, el mundo carga, los plugins arrancan. Un backup del que no puedes restaurar no es un backup. Plan completo aquí.

World border y elección de seed

Un mundo infinito en SMP es malo. Los jugadores se dispersan a miles de km y el servidor se hincha a cientos de gigas en meses.

/worldborder center 0 0
/worldborder set 10000

Un círculo de 10000 de diámetro alcanza para 10-20 jugadores. Para 50+ pon 16000-20000.

Buen truco: ampliar el border como evento. "Llegamos a 40 online, el border crece 2000 bloques." Los jugadores lo comentan, vuelven por el evento, traen amigos.

Elegir seed es un arte aparte. No cojas uno aleatorio. Busca un seed donde:

• El spawn esté en llanura o bosque
• Haya 3+ biomas en 1000 bloques
• Haya una aldea a 300-500 bloques del spawn
• Haya una masa de agua y un desierto cerca (cactus, agua dulce)

Usa chunkbase.com. Mete el seed, mira el mapa, busca aldeas y biomas. Un buen seed se encuentra en 30 minutos y paga dividendos durante toda la vida del servidor.

Whitelist: cuándo activarla

SMP de amigos, actívala desde el día uno. Menos problemas.

white-list=true

/whitelist add Nickname

En SMP público la whitelist muchas veces funciona como filtro: el jugador aplica en Discord, el mod aprueba, el bot lo añade. Corta al 90% de los trolls y de los "solo a ver".

EasyWhitelist más DiscordSRV monta la conexión en media hora. Bonus: cada aplicación te da el Discord del jugador. Cuando lo necesites contactar luego (bug report, invitación personal a evento), tienes el contacto.

Discord como centro de la comunidad

DiscordSRV sincroniza el chat del juego con un canal de Discord. El valor real es otro: es un centro de comunidad que funciona incluso con el servidor apagado.

Conjunto mínimo de canales para SMP:

• #announcements (solo admins)
• #general (chat abierto)
• #ingame-chat (sync de DiscordSRV)
• #support (preguntas al staff)
• #applications (solicitudes de whitelist)
• #bug-reports (forum channel con plantilla)
• #off-topic (memes y random)
• #builds-showcase (screenshots de builds)

Activa un rol @online para jugadores que están en el juego ahora. DiscordSRV lo hace solo. Da vida al Discord.

Anuncia eventos con 2-3 días de antelación. La gente necesita organizarse.

Resource pack: no para todos

Un resource pack personalizado es potente. Cambia texturas de espada, añade sonidos, modifica la UI. ItemsAdder incluso añade ítems nuevos con modelos propios.

Contra: el pack hay que descargarlo. Primera entrada al servidor 30-60 segundos. En SMP de comunidad, ok. En servidor cazando tráfico, riesgo.

Regla: si entregas contenido custom (jefes, quests, magia), el pack es obligatorio. Supervivencia pura, te lo puedes ahorrar.

Retención: plan para los primeros tres meses

Lanzar el servidor es el 10% del trabajo. El otro 90% es retención. La estadística es dura: de 100 jugadores que prueban un SMP nuevo, 15-20 siguen tras un mes. A los tres meses, 5-8. Tu trabajo es maximizar esas cifras.

Qué funciona:

Eventos semanales. Viernes por la noche o sábado. Torneo de PvP, concurso de construcción, raid de dragón en equipo. Una razón para entrar.

Temporadas. A los 6-9 meses el mundo envejece. Bases gigantes, economía inflada, novatos sin nada que perseguir. Anuncia "Temporada 2" con reset del mundo y un hall de la fama. Los antiguos vuelven, los nuevos no se sienten un año por detrás.

Progreso público. Una web con "primer Dragón del End", "ciudad más grande", "línea de tren más larga". La gente compite por esos honores más que por premios en metálico.

Toque personal. Los primeros 50 regulares deberían conocerte por el nombre. Es cansado, pero funciona muy bien. No eres "el admin", eres "Pavel, el que responde en 30 minutos y arregla cosas".

Más sobre crecimiento de jugadores aquí.

Monetización sin pay-to-win

Pay-to-win mata un SMP más rápido que un DDoS. En cuanto tu tienda vende "kit de iniciación: armadura de diamante por 3 euros", tus jugadores gratis se van.

Qué puedes vender:

• Rangos cosméticos con prefijo en el chat
• Color del nick
• Slots extra de /home (por ejemplo de 3 a 5)
• Mundos privados (plugins de isla)
• Ítems cosméticos sin stats
• Emotes o mascotas sin buff de combate

Qué no debes:

• Recursos (diamantes, esmeraldas, netherita)
• Equipo encantado
• Llaves de cofres con loot OP
• Ventajas en PvP (más daño o armadura)
• Auto-minado, auto-crafteo

Una monetización sensata da 50-100 euros por cada 100 jugadores activos al mes. Suficiente para el VPS y parte del tiempo del admin. Hacerse rico con un SMP es raro, no lo planifiques así.

Soft launch: no abras en prime time

Error clásico: anunciar el servidor antes de probarlo. Día de apertura, entran 30 personas, un plugin se rompe, la DB se cuelga, los jugadores salen decepcionados. La mitad no vuelve.

Plan de soft launch:

1. Semana menos 2. Servidor arriba con 3-5 amigos de confianza. Cazan bugs, prueban comandos, validan plugins.
2. Semana menos 1. Invita a 10-15 beta testers. Wipe o no del mundo, decisión tuya. Recopila feedback.
3. Día 0. Anuncio público. A esta altura los bugs obvios ya están fuera. Servidor estable a 20-30 simultáneos.
4. Semana más 1. Monitoriza TPS, arregla pequeñeces, responde todo en Discord.
5. Semana más 2. Primer evento. Esto pesa. Demuestra que el servidor está vivo.

No anuncies a tus 1000 suscriptores hasta el paso 3. La reputación de un servidor nuevo es frágil, y el segundo intento cuesta más que el primero.

Cuando tu SMP se convierte en objetivo

40 jugadores estables, tu propio Discord, memes internos, primeras donaciones. Todo va bien. Y entonces el servidor cae. De nuevo. De nuevo.

Es un DDoS. Alguien baneado con rencor, un competidor que quiere tus jugadores, o un adolescente aburrido un viernes por la noche. El hosting normal no lo para. Cloudflare es para tráfico web, no para el protocolo de Minecraft. Necesitas un filtro que entienda Minecraft y tire la basura antes de que toque Paper.

MineGuard hace exactamente eso. Proxy de tu IP, atrapa SYN floods y UDP fragmentado a nivel de red, filtra bots de aplicación con captcha. Apuntas el tráfico de los jugadores a la dirección de MineGuard y MineGuard reenvía el tráfico limpio a tu backend. Los jugadores no se enteran.

El plan gratuito aguanta ataques pequeños y sirve para SMPs hasta 50-100 simultáneos. El de pago resiste botnets serias.

No esperes al primer ataque para pensar en protección. Un día de caída cuesta 10-20% de tus jugadores activos. Para un SMP joven es un mes de retroceso, a veces el final del proyecto.