txAdmin : comprendre le panel qui pilote un serveur FiveM

txAdmin FiveM is the management layer that sits between raw server files and the person running them, turning console commands, ban lists and update routines into a web panel you can reach from any browser. This article breaks down what it actually controls day to day: deployments, live console, player administration, scheduled restarts and crash recovery.

What txAdmin FiveM Actually Controls Day to Day

txAdmin is the official management tool bundled with FXServer, the artifact that runs FiveM and RedM resources. It isn't a separate product you install on top of an existing setup — it's embedded directly in the server binary and exposes a web interface, usually on port 40120, that mirrors everything you'd otherwise do from a raw terminal.

In practice, txAdmin manages four distinct layers of a FiveM deployment: the resource recipe used to build the instance, the live console output and command input, the player/ban database, and the scheduled maintenance tasks (restarts, backups of server data, crash watchdog). None of these are optional add-ons — they're the core reason most communities running a FiveM server lean on the panel instead of raw SSH access.

If you're comparing management options before deploying, our FiveM server hosting includes the panel pre-configured, so the recipe system and live console described below work out of the box without manual compilation of FXServer.

Recipes: How Deployments and Updates Actually Happen

The first thing txAdmin asks for when you spin up a fresh instance is a recipe — a YAML file describing which base files to pull, which resources to clone from GitHub, which convars to set, and in what order to run each step. This is how frameworks like vMenu, ESX, or QBCore get dropped into a working instance without someone manually cloning a dozen repositories and wiring dependencies by hand.

Anatomy of a Recipe File

A recipe is a flat sequence of steps. Each step has a type (download_github, download_file, move_path, run_command, ensure_resource) and a target. txAdmin executes them top to bottom inside a staging area before anything touches your live resources folder.

name: 'My Base Server'
author: 'Community Team'
description: 'Base cfx-server-data + a starter framework'

tasks:
  - action: download_github
    src: 'citizenfx/cfx-server-data'
    ref: 'master'

  - action: download_github
    src: 'esx-framework/esx_core'
    ref: 'main'
    dest: 'resources/[esx]'

  - action: run_command
    cmd: 'echo "Recipe staging complete"'

Once staging finishes, txAdmin moves files into place, generates the initial server.cfg, and prompts for the license key and admin account before the first boot. Re-running a recipe later (for a framework update, for instance) follows the same staged process, which avoids leaving a half-updated resource folder if a download fails midway.

Updating an Existing Instance

For ongoing maintenance, most admins don't re-run the full recipe — they pull updates per resource through git directly on the machine, then use the panel's resource reload tools. A typical update cycle on the host looks like this:

cd /home/container/resources/esx_core
git pull origin main
# back in txAdmin console:
refresh
restart esx_core

That two-command sequence (refresh to rescan the resources folder, then restart on the specific resource) is one of the most repeated actions in day-to-day administration, and it's available directly from the live console tab without dropping to a shell.

Inside the Panel: Live Console, Players and Bans

The live console tab is a real-time mirror of FXServer's stdout, with input piped straight back into the process. It behaves exactly like a terminal attached to the game server, including coloured log output, resource error stack traces, and the ability to type raw console commands such as restart, refresh, or custom resource exports.

Player Management

The Players tab lists everyone currently connected, pulling their license, Discord, Steam and FiveM identifiers, plus their current ping and session duration. From that list an admin can kick, warn, or ban directly, with the action logged against the identifier set rather than just an IP, which matters since IPs rotate but hardware/platform identifiers mostly don't.

Action	Scope	Typical use case
Kick	Single session	Disconnect a player without a lasting penalty
Warn	Logged, no disconnect	Track repeated minor rule breaks
Ban (temporary)	Identifier set, time-limited	Cooldown after a conflict or exploit attempt
Ban (permanent)	Identifier set, indefinite	Cheating, chargebacks, repeated bans

Ban Lists and Identifier Logic

Bans are stored in a local database file (data/banDatabase.json by default) and checked against every identifier a connecting client presents, not just one. This is why a ban survives a client reinstall but can still be bypassed if someone spoofs an identifier that wasn't captured at ban time — a reminder that identifier coverage, not ban count, is what makes a ban list actually hold.

For communities running RedM server deployments alongside FiveM, the same ban and player database logic applies since both run on the FXServer core.

Scheduled Restarts and Crash Auto-Recovery

Resource leaks and memory creep are a fact of life on any long-running FiveM instance with dozens of active scripts. txAdmin's scheduler lets you define fixed restart times (for example, every 4 hours, or a specific set of clock times) with a countdown warning broadcast to connected players before the restart executes, so nobody loses progress mid-session without notice.

# txAdmin config.yaml excerpt
restarter:
  schedule:
    - '03:00'
    - '09:00'
    - '15:00'
    - '21:00'
  warnings:
    - 15
    - 5
    - 1

The warning intervals (in minutes before restart) trigger chat and console announcements, which most frameworks hook into to also save pending player data before the cycle fires.

Crash Detection and Watchdog Behaviour

Separately from the scheduled restarts, txAdmin runs a watchdog process that monitors FXServer's heartbeat. If the process stops responding — a hard crash, an infinite loop in a resource, or an out-of-memory kill — the watchdog detects the missing heartbeat and triggers an automatic restart without manual intervention. The event is logged with a timestamp and, where possible, the last console lines before the freeze, which is usually the fastest way to track down which resource caused the hang.

Combined with automatic backups of the server data folder, this auto-recovery loop is what keeps a community-run instance online overnight without someone watching a console at 4 a.m. It doesn't replace good resource code — a script with a genuine memory leak will still crash on a schedule of its own — but it caps the downtime window to the watchdog's detection interval instead of however long it takes someone to notice.

Backups Worth Pairing With the Panel

txAdmin's restart scheduler and watchdog cover uptime, but they don't replace off-box backups. Keeping a copy of the resources folder and database outside the restart cycle — whether through the panel's own backup feature or a cron job on the underlying machine — is what actually protects against a corrupted save or a bad recipe update.

0 4 * * * tar -czf /backups/fivem-$(date +\%F).tar.gz /home/container/resources /home/container/server-data

For a wider view of panel-based management across other titles, the All our game servers page and the Fly-Serv blog cover similar configuration workflows, and a Pterodactyl VPS is a comparable option if you're managing multiple instances through one dashboard rather than txAdmin's single-instance panel.

txAdmin turns FXServer from a blind console process into something you can monitor, schedule and recover without constant manual attention. Recipes handle deployment, the live console and player tools handle daily moderation, and the scheduler with its watchdog keeps an instance stable between the moments you're actually watching it.

FAQ

Why does txAdmin ask for a recipe before the first boot?

The recipe defines which base files and resources to pull before FXServer can start. Without it, txAdmin has no instructions for building the resources folder, so the setup wizard blocks until a valid recipe (or manual file structure) is provided.

Can a ban be bypassed after a client reinstall?

Only if the ban database didn't capture every identifier the client presents. Reviewing which identifiers were logged at ban time, not just relying on a single one, closes most of these gaps.

What happens if the watchdog restarts the server mid-crash loop?

The watchdog will keep restarting FXServer each time the heartbeat drops, but a resource causing repeated crashes needs to be isolated in the console logs and disabled or fixed — the watchdog limits downtime, it doesn't resolve the underlying fault.