txAdmin guide: admins, restarts, bans and backups

txAdmin is the web panel built into every FXServer artifact: start the server without +exec server.cfg, open port 40120, enter the PIN printed in the console, and you have a master account that controls the server, its restarts, its player database and its admins. Most servers stop there and use a tenth of it. The parts that decide whether a FiveM community survives its first year are the boring ones: admin accounts with narrow permissions, a restart schedule with warnings, bans that match hardware as well as names, a txData folder that is backed up, and a web panel that is not open to the whole internet with a weak password on it.

This guide assumes the server already exists. Getting the licence key, installing FXServer and writing server.cfg are covered in setting up a FiveM server with txAdmin. Here the subject is txAdmin itself, page by page, with the settings that matter and the mistakes that cost people their ban list.

What txAdmin is, and where it sits#

txAdmin is not a resource and not a separate program. Since early 2020 it has shipped inside FXServer, and when FXServer starts without a config to execute, it runs txAdmin instead, which then launches FXServer as a child process with your configuration. That arrangement is the whole point: txAdmin sits outside the game server, so it can notice when the server hangs or crashes, kill it and start it again, and keep a record of every player across restarts.

What it does, in one list:

• Deploys servers from recipes, including full framework installs with their database.
• Restarts the server on a schedule, with in-game warnings, and automatically after a crash or a hang.
• Keeps a player database of its own, a file rather than MySQL, with identifiers, play time, notes, warnings and bans.
• Whitelists by Discord membership, Discord role, approved licence or admin-only.
• Runs a Discord bot with a live status embed and a whitelist command.
• Shows a live console, CPU and memory graphs, a tick-time chart and a server activity log.
• Provides an in-game menu (/tx) for admins: NoClip, teleport, spectate, freeze, heal, vehicle tools, bans and warnings.
• Edits `server.cfg` in the browser, with a validator.

It does not replace ACE permissions. A txAdmin admin governs the web panel and the in-game menu; ACE governs in-game commands and resources. The two are separate systems, and the Discord permissions guide explains how to connect them.

First boot, the PIN and the master account#

On first start, txAdmin creates its data folder, binds to TCP 40120, and prints a four-digit PIN and the address to open:

[txAdmin] Use the PIN below to register:[txAdmin]     1234[txAdmin] Open http://203.0.113.10:40120/ in your browser.

The PIN is the only thing standing between the world and ownership of your server until an account exists. Anyone who can reach port 40120 and read that PIN can claim the master account, so do the registration straight away rather than leaving a fresh server sitting on the setup screen overnight.

Registration offers two ways in: link your Cfx.re account (the one you use on the forum and keymaster) or create a username and password. Linking Cfx.re is the better choice for the master account, because it also gives txAdmin your FiveM identifier, which the in-game menu needs to recognise you. You can still set a backup password on the account afterwards.

The account created here is the master. There is exactly one. It has every permission, it cannot be removed by other admins, and it is the only account that can edit other admins' permissions without holding all_permissions or manage.admins itself. Treat it like a root password: one person, a strong credential, never shared.

After registration comes the setup wizard. You name the server and choose a deployment type: a popular recipe, a remote recipe URL, a custom recipe pasted in, or existing server data (a server-data folder you already have). The exact labels have changed across versions, but those four paths have been stable. For an existing server, point it at the folder and at its server.cfg, and txAdmin takes over from there.

Lost the master account

If the master's password is lost and no Cfx.re account is linked, the usual recovery is blunt. Stop the server, delete txData/admins.json (keep a copy), and start again; txAdmin finds no admins, prints a new PIN, and you register a fresh master. Every other admin account goes with that file, so you recreate them afterwards. Stop the server first: txAdmin holds the admin list in memory and writes it back, so edits to the file while it runs are overwritten. Reports on the Cfx.re forum suggest the behaviour has not been identical in every version, so check the current txAdmin documentation if it does not behave as described.

Admins and permissions#

Every moderator should have their own txAdmin account. Shared logins destroy the one thing txAdmin is very good at: the action log that says who banned whom, who restarted the server at 21:00 on a Saturday, and who ran a console command.

Admins are created on the Admins page by the master or by anyone holding manage.admins. Each account gets a name, optionally a linked Cfx.re and Discord ID, and a set of permissions. The permission IDs as txAdmin stores them:

And the player and menu permissions:

The permissions are stored in txData/admins.json. A sensible split for a roleplay server:

• Trial moderators: players.warn, players.kick, players.direct_message, players.spectate, menu.viewids. Enough to deal with a problem in the moment, not enough to make a permanent one.
• Moderators: the above plus players.ban, players.whitelist, players.freeze, players.teleport, players.heal, players.playermode, and server.log.view so they can check what happened before acting.
• Administrators: the above plus control.server, commands.resources, announcement, console.view and settings.view.
• Developers: console.view, console.write, commands.resources, server.cfg.editor. Developers rarely need to ban anybody.

Two permissions deserve caution. console.write is effectively full control: the server console can stop resources, change convars and run anything a resource exposes as a command. server.cfg.editor can change the licence key, the database connection string and the ACE list, so it can grant in-game permissions to anyone. Give those two to people you would also give the master password to. players.troll is fun for about a week and then becomes the subject of a complaint; most serious servers leave it off for everyone.

For the in-game menu to work, the admin's account must have their Discord or Cfx.re identifier linked. Without either, /tx does nothing for them, which is the single most common "the menu is broken" report. The general argument for narrow access is the same one made in subusers and least privilege.

Recipes and the deployer#

A recipe is a YAML file that tells the deployer how to build a server: what to download, where to put it, which SQL to run and what to write into server.cfg. The popular recipes in the setup wizard (cfx-default, ESX, QBCore and others) are maintained in a public repository, and you can write your own for a server you rebuild often.

$engine: 3$minFxVersion: 5181$onesync: onname: Longship baseversion: 1.0.0author: Longship staffdescription: Default resources plus our own core pack.tasks:  - action: download_github    src: https://github.com/citizenfx/cfx-server-data    subpath: resources    dest: ./resources/[cfx-default]  - action: download_file    url: https://example.com/longship-core.zip    path: ./tmp/core.zip  - action: unzip    src: ./tmp/core.zip    dest: ./resources/[core]  - action: connect_database  - action: query_database    file: ./resources/[core]/install.sql  - action: write_file    file: ./server.cfg    data: |      endpoint_add_tcp "{{serverEndpoints}}"      endpoint_add_udp "{{serverEndpoints}}"      sv_maxclients {{maxClients}}      sv_licenseKey "{{svLicense}}"      set mysql_connection_string "{{dbConnectionString}}"      ensure [cfx-default]      ensure [core]  - action: remove_path    path: ./tmp

The $engine, $minFxVersion and build numbers above are illustrative; take the current values from the recipe documentation in the txAdmin repository. The task actions are a fixed set: download_github, download_file, unzip, move_path, copy_path, remove_path, ensure_dir, write_file, replace_string, connect_database, query_database and load_vars. Variables such as {{svLicense}}, {{dbConnectionString}}, {{serverEndpoints}} and {{maxClients}} are filled from what you type into the deployer.

Recipes are jailed to the deployment folder, so a recipe cannot overwrite admins.json or anything else outside it. That limits the damage, but it does not make a recipe from a stranger safe: it still downloads and runs whatever resources it names, and those run with full server-side access. Read a third-party recipe before deploying it, the same way you would read a resource. A recipe is a starting point, not a framework choice; the framework comparison is the place to decide which one you want.

If a deploy fails halfway, the usual causes are a GitHub rate limit (recipes with many download_github tasks should pin a ref), a database the deployer cannot reach, or a download link that has moved. The deployer log names the failed task; fix the cause and deploy again into an empty folder.

The live console and the server log#

The Live Console page is FXServer's own output in the browser, with a command line, history and search. Anything you can type into the FXServer terminal works here: ensure myresource to restart one resource, refresh to pick up a new resource folder, status for the connected players. Every command sent is recorded in the action log against the admin who sent it.

The server log is a different page and a different thing: a timeline of joins, leaves, deaths, chat, explosions and admin actions. When somebody appeals a ban, this is where you find out what happened before the ban, and it is why server.log.view is worth giving to moderators who issue bans.

The dashboard's performance chart shows how long the server's main thread takes per tick, bucketed, alongside the player count. It is the fastest way to tell a resource problem from a capacity problem, covered properly in the resmon and performance guide. Reading the console covers the general skill of picking the lines that matter out of the noise.

Scheduled restarts and crash handling#

FXServer and the frameworks on top of it are not built to run for weeks. Memory grows, entity counts drift, and a restart every few hours is ordinary practice on any busy roleplay server. txAdmin's Restarter settings take a list of times in 24-hour HH:MM format:

Restart schedule: 06:00, 14:00, 22:00

The times are in the host machine's timezone, which on a rented server is often not yours. Check the clock shown on the txAdmin dashboard before trusting a schedule. Before each scheduled restart, txAdmin announces it in game at 30, 15, 10, 5, 4, 3, 2 and 1 minutes, and fires the txAdmin:events:scheduledRestart event at the same marks with a secondsRemaining value. Frameworks and inventory resources listen for that event and for txAdmin:events:serverShuttingDown to save player data before the process ends, which is why a txAdmin restart is safe and a kill from outside is not.

AddEventHandler('txAdmin:events:scheduledRestart', function(data)  if data.secondsRemaining == 60 then    -- one minute left: save everyone now    TriggerEvent('longship:saveAllPlayers')  endend)

An admin can skip the next scheduled restart from the dashboard when an event is running long; the skip is announced through txAdmin:events:scheduledRestartSkipped. Pick restart times around your peak, not inside it. Restart schedules that help goes through choosing them.

Crash handling is automatic. If FXServer exits, txAdmin starts it again. If the server stops responding (the main thread blocked, the heartbeat silent), txAdmin kills and restarts it after a timeout. If a server restarts repeatedly on a hang, do not raise the timeout: something is blocking the main thread for seconds at a time, and profiling it is the fix.

On RE:NODE the panel's Schedules tab can run backups and power actions on a cron expression. For FiveM, leave the restarts to txAdmin and use the panel schedule for the nightly backup, timed a few minutes after a txAdmin restart so the database is quiet.

Players, warnings and bans#

txAdmin records every player who connects, against every identifier the client offers: license, discord, fivem, steam (if Steam is running), live, xbl and the IP. It also records hardware tokens (HWIDs), which are harder to change than any account. The player database is a file inside txData, not MySQL, so it works with no database at all and survives a framework change.

Clicking a player opens their record: play time, first and last seen, every identifier, notes left by staff, and the history of warnings and bans. Notes are underrated: "warned verbally about VDM, 14 Oct" in a note stops the same conversation happening four times with four different moderators.

Warnings are shown on the player's screen as a full overlay they have to acknowledge, and stored on their record. They are the right tool for a first offence because the player cannot claim they did not see it. If the player is offline, the warning is shown the next time they join.

Bans take a reason and a duration: one of the presets, a custom length, or permanent. A ban attaches to the identifiers and, if HWID banning is on in the ban settings, to the hardware tokens as well, so a banned player who makes a new Rockstar and Discord account is still caught. Recent versions let you save ban templates (reason and duration pairs such as "Combat logging, 2 days") so moderators apply the same rule the same way. Each ban gets an action ID that the player sees in the rejection message, and that ID is what they quote in an appeal.

Bans are revoked from the player's record or the history page, and the revocation is logged against the admin who did it. If a ban caught an innocent person who shares a household or hardware with a banned one, players.remove_ids lets a senior admin remove a specific identifier or HWID from a record rather than unbanning the original.

txAdmin can also prune its own database: players inactive for a long period, and old warnings, bans and whitelist entries, under the database settings. On a server with tens of thousands of drive-by visitors this keeps the file and the player search fast. Pruning deletes records for good, so take a backup first. For catching cheaters rather than punishing them afterwards, see FiveM anticheat options.

Whitelist modes and the Discord bot#

The whitelist modes are Disabled, Admin-only, Discord server member, Discord server roles, and Approved license. They live under the player manager settings, and setting them up with Discord roles, including the bot token, the guild ID and the members intent, is covered step by step in the FiveM Discord whitelist guide. Two points worth adding here:

• Admin-only is your maintenance switch. Set it before an update or a database repair; players already connected stay, new ones are told the server is closed. Switch it back afterwards, because it is easy to forget.
• Approved license produces a request with a short ID when an unknown player tries to join. Admins with players.whitelist approve it on the Whitelist page or through the Discord bot. You can also pre-approve someone before their first join.

The Discord bot does three jobs once its token and guild are set in Settings, Discord Bot. It posts a status embed that updates once a minute with player count, uptime and the next scheduled restart: type /status add in the channel where you want it, and give the bot Send Messages permission there. It accepts a whitelist command for approving players from Discord. And it can look up a player's info. The embed's content and its buttons (up to five, usually "Connect" and "Rules") are edited as JSON on the same settings page. txAdmin does not validate that JSON when you save, so if the embed stops updating, check the System Logs page for the error. More on bots in general is in Discord bots for game server admin.

txData: what is in it and how to back it up#

Everything txAdmin knows lives in one folder, txData, separate from both the artifact and your server-data:

txData/  admins.json          admin accounts and their permissions  default/             the server profile    config.json        txAdmin settings (restarter, bot, whitelist...)    data/              player database, bans, warnings, whitelist    logs/              txAdmin, server and FXServer logs

The exact layout inside the profile folder has changed between major versions, so treat the tree as a guide and look at your own copy. What matters is that the whole folder is one unit: back it up together, restore it together.

Where it lives by default is the detail that loses people their ban lists. Since txAdmin 8, the default is ../txData relative to FXServer on Windows (beside the artifact folder) and ../../../txData from the FXServer binary on Linux, which lands inside the extracted artifact folder. If you update on Linux by replacing that folder wholesale, txData goes with it. Either move it and point txAdmin at the new location with the TXHOST_DATA_PATH environment variable, or copy it out before every update.

These environment variables arrived in txAdmin 8 and replace the older +set txDataPath, +set txAdminPort and +set txAdminInterface launch convars, which still work for now but are deprecated. If both are set, the TXHOST_ value wins.

A backup that matters has three parts: txData, server-data, and the database. Take all three before every artifact update, because a newer txAdmin may migrate its data in a way an older one cannot read; the artifacts guide has the update procedure itself. Stop the server, or at least avoid backing up during a restart, so config.json and the player database are not caught mid-write. Then restore one, once, onto a test copy - a backup nobody has restored is a hypothesis, as backups that actually restore puts it.

On RE:NODE, backups made from the panel cover the whole server's files, txData included, are stored off the machine, can be locked so rotation never deletes the pre-update copy, and restore with one button. The database sits in its own slot and needs its own export.

Securing the web panel#

txAdmin's web interface is plain HTTP on 40120, and by default it binds to every interface. A web panel that can run console commands is a high-value target, and the internet is full of scanners that know the port number.

• Use Cfx.re login or long, unique passwords. txAdmin has no TOTP of its own, so a Cfx.re account with two-factor authentication enabled is the strongest login available for each admin.
• Restrict the port. If you control the firewall, allow 40120 only from the addresses your staff use, or bind txAdmin to 127.0.0.1 with TXHOST_INTERFACE and reach it through an SSH tunnel. SSH tunnels and port forwarding shows the one-line command, and firewall rules that matter covers the rest.
• Put HTTPS in front if it must be public. A reverse proxy with a certificate stops passwords crossing the network in the clear. What a reverse proxy does explains the setup.
• Never move txAdmin to `30120`. It is refused anyway; the game port is FXServer's.
• Prune admins. When a moderator leaves, delete their account the same day. Their Discord role and their ACE group are separate, so remove those as well.
• Read the action log. A weekly glance at who ran console commands catches both mistakes and compromised accounts.
• Keep FXServer current. txAdmin security fixes ship inside artifacts, so a server three months behind is also three months behind on the panel.

The same thinking applies to the legacy RCON console: leave rcon_password unset, because txAdmin does everything it does over a better channel. Using RCON safely gives the general case.

On RE:NODE, FiveM plans come with two port allocations, and more can be added on the Network tab when txAdmin needs a port of its own. The hosting panel's own subusers are a separate layer: give a moderator txAdmin access only, and keep panel access (files, SFTP, backups) for the people who would otherwise need the master account.

Troubleshooting#

The PIN never appears. The server is starting with +exec server.cfg, which skips txAdmin entirely. Remove it from the start command. If txData already holds an admin, there is no PIN either: txAdmin goes straight to the login page.

The txAdmin page does not load. TCP 40120 is not reachable from outside, or txAdmin is bound to 127.0.0.1. Check the boot message for the address it printed, then test the port from another network.

The in-game menu does nothing. The admin account has no Discord or Cfx.re identifier linked, or the identifier does not match the one the client sends. Check the player record for the identifiers they actually connect with.

Settings and admins vanished after an update. txAdmin is reading a different, empty txData, usually because the artifact folder was replaced on Linux. Restore the folder or point TXHOST_DATA_PATH at it.

Scheduled restarts happen at the wrong hour. The host's timezone differs from yours. Convert the times to the clock txAdmin shows.

A banned player is back under a new name. HWID banning is off, or the player changed hardware. Turn on HWID matching in the ban settings and check their record for overlapping identifiers.

The Discord embed stopped updating. The embed JSON is invalid or the bot lost Send Messages permission in that channel. The System Logs page names the error.

FAQ#

What port does txAdmin use?

TCP 40120 by default. Change it with the TXHOST_TXA_PORT environment variable in txAdmin 8 and later, or the older txAdminPort convar on earlier versions. It cannot share 30120 with the game.

How many master accounts can txAdmin have?

One. Other admins can be given all_permissions, which grants every action, but the master account is unique and is the one recovery depends on. Keep its credentials with one person and a password manager.

Does txAdmin need MySQL?

No. Its player database, bans, warnings and whitelist are stored in files inside txData. Your framework still needs its own database; txAdmin does not use it.

Are txAdmin bans shared between servers?

Not automatically. Each txData profile keeps its own player database, so a ban issued on one server is not seen by another unless you use an external ban system or re-issue it by identifier.

Is it safe to give moderators console access?

Read-only console access, console.view, is fine for most staff. console.write lets someone run any server command, including stopping resources, so give it only to people you would trust with the master account.

What happens to players' unsaved data on a txAdmin restart?

txAdmin warns players and fires the restart and shutdown events first, so a framework that listens for them saves everyone. A process killed from outside txAdmin gets no warning, and anything not yet saved is lost.