txAdmin: qué es, cómo configurarlo y para qué sirve de verdad

Si has abierto un servidor de FiveM en los últimos años, has usado txAdmin sin decidirlo: viene dentro de los artifacts oficiales y es lo primero que te sale al arrancar FXServer. Y ahí está el problema, porque la mayoría de administradores lo usan solo para darle a “Start” y ver la consola, cuando lo que tienen delante es la herramienta que decide si su servidor se cae los sábados por la noche o no. Esta guía cubre lo que hace de verdad, cómo configurarlo bien y qué cuatro ajustes evitan la mayor parte de los sustos.

Qué es txAdmin exactamente

txAdmin es el panel de administración web de FXServer, mantenido por el propio equipo de Cfx.re y distribuido junto a los artifacts. No es un recurso que instales dentro de resources: es el proceso que arranca, supervisa y reinicia tu servidor, y que te da una interfaz de navegador para hacerlo.

Su papel es el de supervisor. Cuando ejecutas FXServer.exe sin argumentos, lo que se levanta es txAdmin, y es txAdmin quien lanza el proceso real del servidor con tu server.cfg. Eso explica cosas que confunden a mucha gente:

• Si el servidor se cuelga, txAdmin sigue vivo y puede reiniciarlo solo.
• Los cambios de server.cfg no se aplican con guardar el fichero: hace falta reiniciar desde el panel.
• La consola que ves en el navegador es la misma consola del servidor, con permisos de escritura. Quien entra en el panel puede ejecutar comandos.

Ese último punto es la razón por la que la sección de seguridad de esta guía no es opcional.

Primer arranque: del cero al servidor levantado

El flujo de un primer arranque limpio es corto. Descargas los artifacts para tu sistema, creas dos carpetas separadas (una para los artifacts y otra para los datos del servidor), y ejecutas el binario. txAdmin te da una URL local con un PIN de un solo uso, normalmente http://localhost:40120.

Dentro del asistente tienes tres caminos:

1. Popular templates (recipes): despliega una base conocida (ESX Legacy, QBCore) con sus dependencias y su base de datos. Es la vía rápida.
2. Remote URL: un recipe propio alojado en un repositorio.
3. Existing server data: apuntas a un directorio que ya tienes. Es lo que usarás en migraciones.

Necesitarás dos cosas antes de empezar: una clave de servidor de Keymaster y una base de datos MySQL o MariaDB accesible. Si el asistente falla en el paso de la base de datos, casi siempre es que el usuario no tiene permisos para crear esquemas, no que txAdmin esté roto.

Sobre los recipes conviene ser honesto: te dejan un servidor que arranca, no un servidor que puedas abrir. Lo que sale del recipe es una base vacía con el framework funcionando. El contenido, el balance de economía, los trabajos, el mapa y las reglas los pones tú, y ahí es donde se va el tiempo de verdad. Si estás decidiendo entre frameworks antes de lanzar el recipe, mira la comparativa entre QBCore, ESX y Qbox: cambiar de framework después es mucho más caro que elegir bien al principio.

Los cuatro ajustes que evitan la mayoría de caídas

Casi todos los servidores que se caen a las tres de la mañana lo hacen por una de estas cuatro razones, y las cuatro se configuran en txAdmin en diez minutos.

1. Reinicios programados

En Settings → Restarter defines los reinicios automáticos. FXServer acumula memoria y estado con las horas, y los scripts mal optimizados aceleran ese deterioro. Un reinicio cada 6 u 8 horas, avisando por chat con antelacion suficiente, evita el escenario clásico del servidor que va cada vez más lento hasta que revienta en el pico de jugadores.

Programa los reinicios en las horas de menor actividad. Si tu comunidad es española, la madrugada; si tienes población de LATAM, revisa tus propias estadísticas antes de decidir la hora, porque el pico se te desplaza varias horas.

2. Backups de verdad

txAdmin gestiona copias del directorio del servidor, y eso cubre los recursos y la configuración. No cubre la base de datos, que es donde viven los personajes, los vehículos, las propiedades y el dinero. Perder el directorio es un fin de semana de trabajo; perder la base de datos es perder la comunidad.

Monta un mysqldump programado aparte, guárdalo fuera de la máquina del servidor y prueba una restauración antes de necesitarla. Un backup que nunca has restaurado no es un backup, es una carpeta.

3. Administradores con permisos acotados

En Master Actions → Admin Manager creas cuentas de administrador con permisos por bloques. La tentación es dar todo a todo el mundo porque es más rápido. No lo hagas: el permiso de consola equivale a control total del servidor, y el de gestión de recursos permite parar cualquier cosa.

Da a cada persona lo que necesita para su rol de staff y nada más. Y usa cuentas individuales, nunca una compartida: cuando algo se rompe, el log de acciones de txAdmin te dice quién hizo qué, y eso solo funciona si cada persona tiene su cuenta.

4. Supervisión de rendimiento

La pestaña de rendimiento te muestra el tiempo de tick del servidor. Es el mejor indicador temprano de que un recurso te está matando el servidor: si el tick sube de forma sostenida, tienes un problema de optimización, no de hosting.

Cruza esa información con resmon en cliente para localizar al culpable. Aquí es donde se nota qué scripts están bien escritos y cuáles no, y por qué merece la pena mirar el consumo antes de instalar cualquier recurso nuevo.

Seguridad: el panel es tu servidor

txAdmin escucha por defecto en el puerto 40120 y ese puerto no debería estar abierto a internet tal cual. Tres medidas, por orden de importancia:

• Autenticación en dos pasos en todas las cuentas de administrador, empezando por la tuya.
• No exponer el 40120 directamente. Ponlo detrás de un proxy inverso con HTTPS y su propio certificado, o accede por túnel SSH. Un panel accesible por HTTP plano manda tus credenciales en claro.
• Contraseñas únicas y largas. El panel da acceso a la consola; la consola da acceso a todo.

Un caso real y frecuente: servidores que aparecen “hackeados” cuando lo que ha pasado es que alguien reutilizó la contraseña del Discord en txAdmin y la filtración vino de otro sitio. La superficie de ataque de un servidor de FiveM suele ser el panel, no el juego.

Errores comunes y qué significan

El servidor arranca y se cierra solo al momento. Casi siempre es la clave de Keymaster: inválida, caducada o asociada a otra IP. La consola de txAdmin te lo dice en las primeras líneas; el error de clave es explícito.

“This server is not accepting connections” o el servidor no aparece en la lista. Puertos. El 30120 en TCP y UDP tiene que estar abierto y redirigido; el 40120 es solo el panel y no sirve para conectar jugadores.

Los cambios de server.cfg no hacen nada. No has reiniciado desde el panel, o estás editando un server.cfg distinto del que txAdmin tiene configurado. En la pestaña de configuración ves la ruta exacta que está usando.

Un recurso no aparece aunque esté en la carpeta. Falta su ensure en el server.cfg, o hay un error en su fxmanifest.lua que impide cargarlo. El proceso completo de instalación y los fallos típicos están en la guía de cómo instalar un script en FiveM.

El deploy del recipe se queda a medias. Suele ser permisos de la base de datos o una descarga bloqueada. Borra el directorio de datos y repite en limpio: un recipe a medio aplicar deja el servidor en un estado peor que no haberlo lanzado.

Qué hace txAdmin y qué no

Vale la pena tener claro el límite, porque ahorra buscar en el sitio equivocado.

Sí: arrancar, parar y reinicar el servidor; consola web; gestión de administradores con permisos; reinicios programados; backups del directorio; supervisión de rendimiento y de jugadores; acciones de moderación (kick, ban, warn) con historial; despliegue de recipes.

No: no optimiza tus scripts, no es un anticheat, no hace backup de la base de datos, no gestiona tu tienda ni tus pagos, y no sustituye a un panel de hosting. Para la parte de protección, mira qué opciones de anticheat tienen sentido según el tamaño de tu servidor.

Por dónde seguir

Si estás montando el servidor desde cero, el orden que funciona es: artifacts y txAdmin primero, framework después, contenido al final. La guía completa para crear un servidor de FiveM paso a paso cubre ese recorrido, y la de optimización explica cómo mantener el tick bajo cuando el catálogo de recursos empieza a crecer.

Y una recomendación que no cuesta nada: antes de instalar cualquier recurso nuevo en producción, pruébalo en un servidor de desarrollo con txAdmin aparte. Tener dos instancias es gratis, y la diferencia entre romper el servidor de pruebas y romper el de tu comunidad un viernes por la noche es enorme.