Guía paso a paso para montar un servidor privado de RuneScape
Servidores de jogos · Por Kevin Marcondes · Publicado el · Actualizado el · 10 min de lectura
Esta guía muestra cómo poner en marcha un servidor privado de RuneScape con enfoque técnico y de seguridad. Aprenderás a preparar el entorno, configurar la base de datos, ajustar puertos y automatizar el proceso. Usa únicamente emuladores y assets con licencia adecuada. Verifica los términos de uso y la normativa aplicable antes de exponer el servidor públicamente.
Requisitos previos y observaciones legales
Poner en marcha un servidor implica responsabilidad técnica y legal. Utiliza solo emuladores de código abierto y assets con licencia compatible. No distribuyas ni uses código, cliente o datos propietarios sin permiso. Revisa los términos del juego y la legislación local.
Requisitos sugeridos: Linux (VPS o máquina local), 2+ GB de RAM, CPU multinúcleo, puerto 43594 abierto, ancho de banda estable y conocimientos básicos de Linux y SQL. Un dominio y HTTPS ayudan, pero son opcionales.
Decide dónde hospedar: VM dedicada o contenedor. Para entender los pros y contras entre Docker y máquinas virtuales en alta disponibilidad, consulta el comparativo Docker vs máquinas virtuales.
Para producción, registra logs estructurados y correlacionables. La guía de logs en JSON y correlación de solicitudes ayuda a diagnosticar problemas en tiempo real.
- Sistema operativo: Ubuntu/Debian o similar
- Acceso sudo/SSH
- Java (OpenJDK), Git y MariaDB/MySQL
- Puerto 43594 disponible (TCP)
- Conocimientos básicos de red y firewall
1) Preparar el entorno y obtener la base del servidor
Instala Java, Git y un servidor de base de datos. Crea un usuario de sistema para ejecutar el servicio. Descarga una base de servidor legalmente licenciada. Prefiere repositorios con licencia clara y sin dependencia de archivos propietarios.
Crea también directorios separados para datos y logs. Esto simplifica las copias de seguridad y las actualizaciones sin perder configuraciones.
# Atualize pacotes e instale dependências
sudo apt update && sudo apt -y install default-jdk git mariadb-server ufw
# (Opcional) Criar usuário dedicado
sudo useradd -r -m -d /opt/rsps -s /usr/sbin/nologin rsps
sudo mkdir -p /opt/rsps/{app,data,logs}
sudo chown -R rsps:rsps /opt/rsps
# Obter um servidor com licença adequada (exemplo genérico)
cd /opt/rsps/app
sudo -u rsps git clone https://example.com/your-rsps.git .
# Se o projeto usar Gradle/Maven, garanta permissões
sudo -u rsps chmod +x ./gradlew || true
2) Base de datos y configuración inicial
Crea una base de datos dedicada con usuario y contraseña robustos. Evita usar la cuenta root desde la aplicación. Anota host, puerto, nombre de la base, usuario y contraseña. Usarás estos datos en el archivo de configuración del servidor.
Algunos emuladores soportan SQLite. Para múltiples jugadores, MariaDB/MySQL suele escalar mejor y facilitar la administración.
-- Acesse o MySQL/MariaDB como root
-- sudo mysql -u root
CREATE DATABASE rsps CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'rsps'@'localhost' IDENTIFIED BY 'senha-muito-forte-aqui';
GRANT ALL PRIVILEGES ON rsps.* TO 'rsps'@'localhost';
FLUSH PRIVILEGES;
-- (Opcional) Tabela de contas mínima de exemplo
-- Ajuste ao seu esquema real do emulador
CREATE TABLE IF NOT EXISTS rsps.accounts (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(32) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
rights INT DEFAULT 0,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Crie uma conta de teste (substitua por hash seguro)
INSERT INTO rsps.accounts (username, password_hash, rights)
VALUES ('admin', '{hash-bcrypt-ou-similar}', 2);
3) Configurar el servidor (puerto, base de datos y variables)
Ajusta el archivo de configuración del servidor. Define host 0.0.0.0 para aceptar conexiones externas, puerto de juego 43594 y credenciales de la base. Usa variables de entorno para evitar contraseñas en texto plano dentro del repositorio.
Guarda el archivo en la carpeta de configuración del proyecto. Consulta la documentación de tu emulador para claves adicionales (mundo, XP, tasa de drop, etc.).
# config.properties (exemplo genérico)
# Rede
server.host=0.0.0.0
server.port=${RSPS_PORT:43594}
# Banco de dados
db.driver=mysql
db.host=${DB_HOST:127.0.0.1}
db.port=${DB_PORT:3306}
db.name=${DB_NAME:rsps}
db.user=${DB_USER:rsps}
db.pass=${DB_PASS:troque-esta-senha}
# Logs
log.level=INFO
log.dir=/opt/rsps/logs
# Jogo (valores ilustrativos; ajuste ao seu emulador)
game.world.id=1
game.world.name=Community-World
game.player.save.interval=60
4) Compilar, ejecutar localmente y variables de entorno
Compila y ejecuta en modo local primero. Exporta variables de entorno para mantener secretos fuera del archivo. Si el proyecto usa Gradle, utiliza el wrapper. Si usa Maven, ajusta los comandos que siguen.
Supervisa la consola para mensajes de inicialización y posibles errores de base de datos o de puerto en uso.
# Variáveis de ambiente (substitua os valores)
export DB_HOST=127.0.0.1
export DB_PORT=3306
export DB_NAME=rsps
export DB_USER=rsps
export DB_PASS='senha-muito-forte-aqui'
export RSPS_PORT=43594
# Build e execução (Gradle)
cd /opt/rsps/app
sudo -u rsps ./gradlew clean build
sudo -u rsps java -Xms512m -Xmx1024m -jar build/libs/rsps-server.jar
# (Alternativa Maven)
# sudo -u rsps mvn -q -DskipTests package
# sudo -u rsps java -Xms512m -Xmx1024m -jar target/rsps-server.jar
5) Firewall, NAT y prueba de acceso externo
Abre el puerto del juego en el firewall. En redes residenciales, haz port forwarding en el router hacia la máquina que ejecuta el servidor en el puerto 43594 TCP. Prueba desde fuera de tu red o usando otra conexión. Si usas cloud, revisa las reglas de seguridad del proveedor.
Evita exponer servicios de administración en internet. Restringe IPs cuando sea posible.
# Habilitar UFW y liberar la porta del juego
sudo ufw allow 43594/tcp
sudo ufw enable
sudo ufw status
# Teste la porta externamente (de otra máquina)
nc -vz SEU_IP_PUBLICO 43594 || telnet SEU_IP_PUBLICO 43594
# Verifique localmente se está escutando
ss -lntp | grep 43594 || netstat -lntp | grep 43594
6) Logs, rotación y servicio con systemd
Ejecutar en primer plano no es práctico. Crea un servicio systemd para iniciar en el arranque y registrar logs. Haz rotación por tamaño o por fecha. Usa journalctl para seguir eventos en tiempo real.
Para aumentar la robustez del despliegue y reducir caídas, consulta la página de auditoría de procesos de deploy.
# /etc/systemd/system/rsps.service
[Unit]
Description=RSPS Server
After=network.target mariadb.service
[Service]
User=rsps
WorkingDirectory=/opt/rsps/app
Environment=DB_HOST=127.0.0.1
Environment=DB_PORT=3306
Environment=DB_NAME=rsps
Environment=DB_USER=rsps
Environment=DB_PASS=senha-muito-forte-aqui
Environment=RSPS_PORT=43594
ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/rsps/app/build/libs/rsps-server.jar
Restart=on-failure
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
# Ativar e verificar
# sudo systemctl daemon-reload
# sudo systemctl enable --now rsps
# journalctl -u rsps -f
7) Backups, actualización y mantenimiento seguro
Haz copias de seguridad periódicas de la base de datos y de los directorios de datos y configuración. Prueba las restauraciones. Actualiza el servidor con planificación y ventana de mantenimiento. Reiniciar el servicio desconecta a los jugadores en curso.
Registra métricas y alertas. Esto anticipa incidentes y ayuda a escalar el entorno cuando la base de jugadores crece.
# Backup do banco (substitua credenciais) — armazene fora do servidor
mysqldump -u rsps -p' senha-muito-forte-aqui ' rsps > /backups/rsps-$(date +%F).sql
# Backup de configs e dados
sudo tar -czf /backups/rsps-data-$(date +%F).tar.gz /opt/rsps/data /opt/rsps/app/config.properties
# Atualização (parada curta):
# 1) Anuncie, 2) Pare serviço, 3) Pull e build, 4) Inicie
sudo systemctl stop rsps
cd /opt/rsps/app && sudo -u rsps git pull && sudo -u rsps ./gradlew clean build
sudo systemctl start rsps && sudo systemctl status rsps --no-pager
Cómo confirmar que funcionó y solución de problemas
Comprobaciones rápidas: el proceso está escuchando en el puerto 43594; los logs muestran “Server started” sin errores de BD; los clientes pueden autenticarse desde otra red. Si algo falla, investiga una causa por vez.
Los problemas comunes incluyen puerto en uso, versión de Java incompatible, credenciales incorrectas y firewall/NAT bloqueando tráfico. Ajusta y reinicia el servicio entre intentos.
- Puerto en uso: cambia RSPS_PORT o termina el proceso que ocupa 43594.
- Java: alinea la versión requerida por el emulador (8, 11 o 17) y el PATH.
- Base de datos: prueba la conexión con el cliente mysql y revisa grants/host de conexión.
- Firewall/NAT: confirma regla en el host y el redireccionamiento en el router.
- Logs: habilita DEBUG temporalmente para detallar stack traces.
# Checar se o serviço está ativo e ouvindo
systemctl status rsps --no-pager
ss -lntp | grep 43594 || netstat -lntp | grep 43594
# Ver logs ao vivo
journalctl -u rsps -f
# Testar conexão ao banco
mysql -u rsps -p -h 127.0.0.1 -P 3306 -e "SELECT 1"
Preguntas frecuentes
¿Es legal ejecutar un servidor privado de RuneScape?
Depende de las licencias y de los archivos que uses. La guía recomienda emplear solo emuladores de código abierto y assets con licencia compatible, y no utilizar código, cliente o datos propietarios sin permiso. Revisa los términos del juego y la legislación local antes de exponer el servidor públicamente para evitar vulneraciones legales.
¿Qué puerto debo abrir para el servidor?
Muchos emuladores RSPS usan por defecto el puerto 43594/TCP, pero ese valor puede cambiarse en el archivo de configuración del servidor. Abre ese puerto en el firewall del sistema y, si corresponde, configura el redireccionamiento de puerto (port forwarding) en el router o las reglas de seguridad del proveedor cloud para permitir conexiones externas.
¿Puedo ejecutar el servidor en Docker?
Sí: la guía indica que muchos emuladores funcionan dentro de contenedores. Crea una imagen con Java, añade la aplicación, monta volúmenes para datos y logs y publica el puerto del juego. Evalúa pros y contras de usar containers frente a máquinas virtuales según alta disponibilidad, administración de recursos y el caso de uso concreto.
¿Qué recursos de máquina se recomiendan?
Para pruebas locales o grupos muy pequeños, la guía sugiere al menos 2 GB de RAM y una CPU multinúcleo; para más jugadores, aumenta CPU, RAM y prioriza disco SSD y baja latencia de red. Monitoriza uso real de CPU, memoria y I/O y ajusta la capacidad basándote en métricas y en el crecimiento de la base de jugadores.
¿Cómo proteger el servidor contra ataques?
Aplica políticas de seguridad: usa un firewall restrictivo, mantén el sistema actualizado, ejecuta el servicio con un usuario sin privilegios y limita accesos administrativos por IP. Monitoriza logs y métricas, habilita rotación y alertas y considera soluciones de mitigación DDoS del proveedor. Mantén backups actualizados para recuperación ante incidentes.
¿Cómo crear una cuenta de administrador?
Depende del emulador: muchas instalaciones permiten crear usuarios normalmente y luego ajustar su nivel en la base de datos. La guía recomienda modificar el campo de permisos (por ejemplo, rights) en la base de datos para otorgar nivel administrativo, usar hashes de contraseña seguros y restringir el acceso administrativo a IPs de confianza.
¿Necesitas ayuda técnica para estabilizar tu servidor?
Podemos revisar logs, automatizar el despliegue, configurar monitorización y orientar en buenas prácticas de seguridad y backup para tu proyecto.
Contactar al autorVer también
- Tutorial: implementar Canary releases con Traefik en Docker Compose usando headers y weighted routing para despliegues graduales de aplicaciones PHP
- Tutorial: configurar HAProxy con Let's Encrypt y healthchecks para balanceo de tráfico entre contenedores Docker en VPS (paso a paso)
- Tutorial práctico: implementar mTLS entre Nginx y microservicios usando smallstep CA en Docker Compose
- Tutorial: configurar cgroup v2 y systemd ResourceControl para limitar CPU, memoria e I/O de contenedores Docker en Debian