Cómo crear un servidor RedM en 2026: una lista de comprobación completa

La mayoría de las guías sobre cómo crear un servidor RedM se detienen en cuanto la consola imprime «Server started». Eso es el 10 % fácil. El otro 90 % decide si todavía tendrás una comunidad dentro de tres meses: una base de datos que sobreviva a un crash, un staff que no pueda destrozar la economía por accidente, eventos que no se puedan abusar y una copia de seguridad que hayas restaurado de verdad al menos una vez. Esta es la configuración de un servidor RedM que seguiríamos nosotros en 2026, en el orden en que la necesitas.

Da por hecho un servidor de rol con un framework. Nada de lo que sigue exige comprarnos nada, y nuestro propio producto tiene una sola sección que puedes saltarte.

#Cómo crear un servidor RedM: lo que necesitas primero

• Una copia de Red Dead Redemption 2 y una cuenta de Cfx.re. Los jugadores necesitan el juego para entrar. Tú necesitas la cuenta para vincular txAdmin y pedir una clave de licencia.

• Una clave de licencia del servidor. Todo FXServer necesita una, que se pide gratis en el portal de Cfx.re (muchas guías aún lo llaman Keymaster). La clave está ligada a tu cuenta y va en server.cfg.

• Una máquina donde ejecutarlo. Un PC de casa sirve para construir y probar. Para los jugadores, alquila un VPS o un servidor dedicado con IP pública fija.

• Los artifacts del servidor. Los binarios de FXServer, disponibles para Windows y Linux en la página oficial de descarga del servidor. Cfx.re describe la versión de Linux como un port de cortesía y dice que los problemas tienen más probabilidades de corregirse en Windows. Si conoces bien Linux, sigue siendo una buena opción. Si no, Windows te costará menos tiempo.

En cuanto a especificaciones, no existe una tabla oficial para un servidor RedM de rol, así que tómalo como una regla empírica de haberlos gestionado, no como una garantía. FXServer hace la mayor parte de su trabajo en pocos hilos, así que la velocidad de un solo núcleo importa más que el número de núcleos. Cuenta con almacenamiento rápido (NVMe) y al menos 8 GB de RAM para un servidor pequeño. Tu framework y el número de scripts pesan más que el número bruto de jugadores.

#Crear un servidor RedM: instala FXServer con txAdmin

txAdmin viene dentro de los artifacts de FXServer y es la forma estándar de llevar un servidor: un panel web para arrancar, parar y reiniciar, leer la consola, gestionar jugadores y programar reinicios. La guía oficial de instalación de txAdmin cubre el primer arranque. En resumen:

1. 1

   Descarga la versión recomendada para tu sistema y extráela en su propia carpeta, separada de los datos del servidor.

2. 2

   Ejecuta FXServer.exe (Windows) o run.sh (Linux). Se abre una página de txAdmin con un PIN.

3. 3

   Vincula tu cuenta de Cfx.re y define la contraseña de administrador.

4. 4

   Pon nombre al servidor y elige una plantilla de despliegue (una receta), o apunta txAdmin a una carpeta de datos que ya tengas.

5. 5

   Introduce tu clave de licencia cuando la receta la pida, ejecuta la receta, guarda y arranca.

Algunos frameworks de RedM publican una receta de txAdmin que descarga el framework, sus dependencias y un conjunto base de recursos de una sola vez. Es la forma más rápida de llegar a una pila al estilo servidor RedM 2026, y puedes leer la receta antes de ejecutarla. Una receta instala software en tu máquina.

#Elige un framework y su base de datos

El framework decide qué espera cada script de tu servidor: personajes, inventario, trabajos, dinero. Cambiarlo más tarde supone rehacer la mayoría de tus recursos, así que elige una sola vez.

• VORP Core es uno de los dos grandes frameworks de rol, con un amplio catálogo de scripts y documentación pública.

• RSG Core es el otro, inspirado en QBCore de FiveM. Si conoces ese ecosistema, su estructura te resultará familiar.

• Existen otros frameworks, y standalone es una opción legítima si construyes una experiencia pequeña y con scripts, sin sistemas de rol completos.

Elige según los scripts que quieras ejecutar y la comunidad a la que puedas pedir ayuda, no según una tabla de funciones.

Los dos grandes frameworks necesitan una base de datos, MySQL o MariaDB, a la que se accede mediante el recurso oxmysql en las instalaciones actuales. Crea una base de datos y un usuario dedicados al servidor, mantén la base de datos en la misma máquina (o en una red privada) y no expongas el puerto 3306 a internet. Algunas guías de instalación lo abren a todas las direcciones por comodidad. No copies esa parte. Pon la cadena de conexión en server.cfg por encima de tus líneas ensure, con charset=utf8mb4 para que los nombres de jugador con acentos se guarden bien.

#Configuración de un servidor RedM: lo esencial del server.cfg

Tu server.cfg es el archivo que marca la diferencia entre un laboratorio y un servidor de verdad. Aquí tienes una forma breve y funcional para RedM. Cada directiva de abajo sale del manual de servidor de Cfx.re.

# Run RedM, not FiveM
set gamename rdr3

# Network: change the port only if you must
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# OneSync is required above 32 slots
set onesync on
sv_maxclients 48

# Your licence key from the Cfx.re portal. Never publish it.
sv_licenseKey "YOUR_LICENSE_KEY"

# Listing
sv_hostname "My RedM Server"
sets sv_projectName "My RedM Server"
sets sv_projectDesc "Serious roleplay in the Old West."
sets locale "en-US"

# Block Script Hook clients (the default, kept explicit)
sv_scriptHookAllowed 0

# Database connection, above every ensure line
set mysql_connection_string "mysql://user:password@localhost/dbname?charset=utf8mb4"

# Optional: pin a game build. Cfx.re lists build 1491 for RedM; leave
# this commented out unless a script you rely on asks for it.
# sv_enforceGameBuild 1491

Unas notas sobre ese archivo. Por encima de 32 slots FXServer exige OneSync, y por encima de 64 exige onesync on, así que activarlo desde el principio te ahorra una migración. sv_enforceGameBuild es un ajuste que solo se aplica al arrancar y la tabla oficial lista una única versión de RedM, así que lo dejamos como opción y no como recomendación: tócalo solo si un recurso lo documenta. sv_scriptHookAllowed está desactivado por defecto, y Cfx.re advierte de que activarlo hace vulnerable al servidor a problemas de seguridad. Por último, ejecuta el servidor con +exec server.cfg desde tu carpeta de datos, o deja que txAdmin lo haga por ti.

#Recursos y orden de carga

Los recursos arrancan en el orden de las líneas ensure. Un script que necesita la base de datos o el framework debe ir después de ellos, o arranca, no encuentra nada y falla en el primer uso. El orden que funciona casi en todas partes:

ensure oxmysql
ensure your_framework_core
ensure your_framework_modules   # inventory, characters, menus
ensure security_and_moderation  # anticheat, logging
ensure gameplay_scripts
ensure maps_and_cosmetics

• Añade los scripts de uno en uno. Reinicia, lee la consola, prueba en el juego y añade el siguiente. Con veinte scripts añadidos de golpe y un error, tienes veinte sospechosos.

• Lee el script antes de ejecutarlo. El código de servidor corre con acceso total a tu base de datos y a tus archivos. Un script filtrado o crackeado es una forma clásica de perder un servidor.

• Prueba los cambios en una copia. No experimentes en el servidor en producción un sábado por la noche.

#Roles de staff y permisos

Da a cada miembro del staff el mínimo que necesita, y dáselo a una persona con nombre, no a una cuenta compartida. txAdmin tiene sus propias cuentas de administrador con permisos granulares para el panel. En el juego, FXServer usa un sistema de permisos ACE configurado en server.cfg:

# Moderators: can use the commands you grant them, nothing else
add_principal identifier.license:MODERATOR_LICENSE group.moderator

# Admins
add_ace group.admin command allow
add_ace group.admin command.quit deny
add_principal identifier.license:ADMIN_LICENSE group.admin

• Reserva el rol de propietario para quienes también pueden tocar el host y la base de datos. Esa es la verdadera raíz de tu servidor.

• Nunca des al staff en el juego poderes que les permitan crear dinero u objetos salvo que su trabajo lo exija, y registra cada uso. La mayoría de los desastres de economía empiezan con un comando de staff.

• Retira los accesos el mismo día en que alguien deja el equipo: en txAdmin, en server.cfg, en el host y en tu Discord.

#Copias de seguridad antes de tu primer jugador

Necesitas dos tipos de copia: la carpeta de datos del servidor (recursos, configuraciones) y tu base de datos. A los jugadores les importa la segunda mucho más que a ti. Guarda las copias fuera de la máquina, porque una copia en el mismo disco muere con el disco.

mysqldump -u youruser -p yourdatabase | gzip > /backups/server-$(date +%F).sql.gz

Haz también un volcado antes de cada actualización de recursos y de cada cambio de framework. Después, da el paso que la mayoría de los dueños se salta: restaura la copia en un servidor de pruebas y comprueba que los personajes y los inventarios están intactos. Una copia que nunca has restaurado es una esperanza, no una copia.

#Seguridad desde el primer día

El momento más barato para arreglar un agujero es antes de que los jugadores dependan de él. Tres cosas importan en el lanzamiento.

Eventos de servidor

Cada manejador de RegisterNetEvent es una puerta a la que cualquier cliente puede llamar, con los argumentos que quiera. Los scripts que se fían de que el cliente diga cuánto dinero ganó o qué objeto recibió son la forma en que ocurren la duplicación y los exploits de economía. Comprueba esto antes de añadir un script, y otra vez antes de escribir el tuyo. Los detalles están en nuestra guía para proteger los eventos de servidor de RedM, y el lado del daño en el artículo sobre el dupe de dinero.

Un anticheat desde el principio

Instalar un anticheat cuando ya ha aparecido el primer tramposo es la forma cara: para entonces, los jugadores han visto lo que tolera el servidor. Hay varias maneras de elegir uno, que explicamos en nuestra guía de compra de anticheat para RedM. Elijas el que elijas, comprueba que funciona con tu framework (mira anticheat para VORP).

Si eliges Baobab AC, la instalación es corta y está documentada paso a paso en la página de instalación. Lo que importa para un servidor nuevo:

• Tu servidor necesita HTTPS saliente hacia la API de Baobab, así que un firewall de salida restrictivo lo bloqueará.

• Creas el servidor en el panel y copias su clave de API en el momento de la creación, porque solo se muestra una vez.

• Pon la clave en server.cfg con set, nunca setr: un convar setr se replica a todos los clientes conectados, y eso haría tu clave legible por cualquier jugador.

• Cárgalo justo después del core de tu framework, y exime a tu staff mediante los grupos ACE de admin para que las pruebas no activen detecciones.

• Arranca en solo alertas: no se castiga nada hasta que decidas aplicar sanciones, lo que te da tiempo para leer primero lo que ve en tu propio servidor.

• El recurso se actualiza solo en el disco y aplica la nueva versión en tu siguiente reinicio.

Puedes ver cómo es el panel sin cuenta en la demo en vivo, y la página de funciones lista todas las detecciones.

Una política de baneos que se sostenga

Escribe tus reglas antes del primer baneo, y decide quién puede banear y con qué pruebas. Los tramposos vuelven con cuentas nuevas. Cómo funcionan los baneos por hardware e identificadores, y qué pueden y qué no pueden hacer, se explica en nuestro artículo sobre el baneo por HWID en RedM.

#Cómo crear un servidor RedM: la lista del día del lanzamiento

No abras las puertas hasta que cada línea sea cierta.

1. 1

   Clave de licencia definida en server.cfg, con el archivo en privado y fuera de cualquier repositorio público.

2. 2

   gamename rdr3, OneSync y endpoints configurados, con el servidor visible y accesible desde una máquina fuera de tu red.

3. 3

   Firewall: puerto del juego abierto, txAdmin restringido, puerto de la base de datos cerrado a internet.

4. 4

   Base de datos con un usuario dedicado, utf8mb4, y credenciales no reutilizadas en ningún otro sitio.

5. 5

   Orden de carga verificado: base de datos, framework, módulos, seguridad, gameplay.

6. 6

   Cada script leído, con su origen conocido, y sin archivos crackeados ni filtrados.

7. 7

   Eventos de servidor revisados en busca de todo lo que deje a un cliente decidir dinero, objetos o XP.

8. 8

   Cuentas de staff con nombre, permisos mínimos, cada una probada una vez.

9. 9

   Anticheat en marcha, staff eximido y una conexión de prueba comprobada en la consola y en el panel.

10. 10

    Política de baneos y reglas escritas y publicadas donde los jugadores puedan leerlas.

11. 11

    Copia de seguridad hecha, guardada fuera de la máquina y restaurada una vez en un servidor de pruebas.

12. 12

    Calendario de reinicios definido en txAdmin, con un mensaje de aviso para los jugadores.

13. 13

    Un anuncio que diga a los jugadores cómo reportar un problema, y un miembro del staff despierto durante la primera noche.

Las partes técnicas llevan una tarde. Las reglas del staff, las copias de seguridad y el hábito de leer antes de instalar son lo que mantiene en pie un servidor. Para el lado del anticheat, empieza por cómo funciona un anticheat RedM. La página de precios es pública cuando quieras comparar.