txAdmin: Running a FiveM Server Without the Terminal

You set the server up by unzipping a folder of artifacts, running FXServer.exe, copying a four-digit PIN out of a black window, and clicking through a wizard. Since then txAdmin has been the thing you open to press Restart when someone says the server feels heavy. The port is still open to the internet. The password is one you also use somewhere else. Your database has not been copied anywhere since the day you installed it.

That is the normal state of a FiveM server, and it is worth fixing in a specific order, because one of those facts can lose you the whole community in an afternoon and the rest are merely inconvenient.

1. txAdmin is not an add-on, it is the server manager you already have

A surprising number of owners go looking for txAdmin as though it were a resource to download. It is a component of FXServer itself, maintained by Cfx.re in the open under the MIT licence and bundled since early 2020. If you have artifacts, you have it.

How it starts is the part that confuses people. Launch FXServer without a +exec server.cfg argument and txAdmin takes over the process, creates a txData folder and puts the web panel up. Point it at a config file on the command line and you have bypassed the manager entirely and are running a bare FXServer — which is what has actually happened when someone says their txAdmin disappeared. If you have not got a server running at all yet, the beginner install walkthrough covers the artifacts first.

First boot prints a PIN to the console. You use it to link a Cfx.re account, set a password, name the server and pick a deployment recipe. Lose access later and the recovery path is to stop the server and run it once with --reset-admin, which prints a fresh PIN so you can reclaim the master account. Admin accounts live in txData/admins.json; deleting the whole txData folder does reset access, but it also throws away your restart schedule, settings, bans and player history, so it is a last resort rather than a fix.

Configuration has moved to environment variables: TXHOST_TXA_PORT defaults to 40120, TXHOST_INTERFACE defaults to 0.0.0.0, and TXHOST_DATA_PATH sets where txData lives. The older txAdminPort, txAdminInterface and txDataPath ConVars, along with txAdminZapConfig.json, are deprecated and slated to stop working — a guide still using them is out of date.

2. The default binding is the single biggest risk on your server

Read that default again: 0.0.0.0, every interface. On a rented box with a public IP, the panel is on the internet from the moment it starts, and there is nothing between the world and your login form except one password.

The comfort people reach for is nobody knows my IP. Your IP is published. It is in the server list, deliberately — advertising a reachable endpoint is the entire mechanism by which players and server lists find you. Port 40120 is a fixed, well-known default sitting one scan away from an address you are actively broadcasting.

What is behind that form is worth being precise about, because "admin panel" undersells it. An account with console.write can run any command the server console accepts. server.cfg.editor reads and writes the file that contains your licence key and your database connection string. settings.write and manage.admins let an intruder lock you out of your own installation.

txAdmin is not a dashboard bolted onto your server. It is a remote console with a web page in front of it, and everything it can do is protected by one password on one open port.

That is the same reasoning that applies to RCON on any other game server, with the difference that txAdmin's surface is much larger. Fix it in this order:

1. Use Cfx.re login for the master account rather than a local password. Authentication moves to Cfx.re, where two-factor exists and account recovery is not your problem.
2. Never reuse a password here. txAdmin has brute-force protection on the login, which stops guessing and does nothing about a password that already leaked somewhere else.
3. Take the panel off the public internet. Set TXHOST_INTERFACE to 127.0.0.1 and reach it over an SSH tunnel or a VPN. The port is then closed to everyone and there is nothing to attack.
4. If you need remote access for staff, put a reverse proxy in front of it for HTTPS and add an IP allowlist or basic auth in the proxy. Exposing 40120 directly, in plain HTTP, is the configuration to avoid.

3. Scheduled restarts, and what they are actually for

A long-running FXServer accumulates. Resources leak memory, entities pile up, and a process that has been up for six days behaves differently from one that has been up for six hours. Restarting is not a repair — if performance degrades within an hour of boot you have a resource problem and the milliseconds are going somewhere specific — but a scheduled restart keeps slow accumulation from turning into a crash at peak time.

The scheduler lives in Settings under Restarter and takes clock times in 24-hour form, repeating daily. Two a day is a sane default for a roleplay server, timed against your own traffic rather than a number someone posted on a forum; the busiest-hour figures we publish per game are a better starting point than guessing, and how those are derived is set out in our methodology.

The part most owners never wire up is the events. txAdmin broadcasts txAdmin:events:scheduledRestart at 30, 15, 10, 5, 4, 3, 2 and 1 minutes before a scheduled restart, carrying secondsRemaining and a translated message, so a resource of yours can put a countdown on screen instead of players being dropped without warning. txAdmin:events:serverShuttingDown fires with a delay in milliseconds for any stop or restart, scheduled or not — that is your hook for flushing player state to the database before the process goes. If nothing listens to it, an unscheduled restart costs everyone whatever was in memory.

txAdmin also runs a health monitor and restarts the server on its own when heartbeats stop, which is where the FXServer is not responding lines come from. Note what that does and does not cover: it detects a hung process, not a running one that nobody can join.

4. Give staff the menu, not the console

The in-game admin menu opens with /tx or /txadmin, or a key the admin binds themselves under Game Settings → Key Bindings → FiveM. Pages are navigated with Tab by default, configurable via txAdmin-menuPageKey. The requirement people trip on: the admin's txAdmin account must have a Discord or Cfx.re identifier attached, or the menu will not open for them at all.

Permissions are per-admin and granular, and the names tell you what they gate. A moderator needs some subset of players.kick, players.ban, players.warn, players.spectate, players.teleport, players.freeze and menu.viewids. A moderator does not need console.write, server.cfg.editor, settings.write or manage.admins, and handing those out because it was quicker than reading the list is how a staff falling-out becomes an incident. Note that all_permissions is root and clears every other assignment — it is not "select all", it is "this person is now you".

Two settings worth knowing: txAdmin-hideAdminInPunishments defaults to true, so bans and warnings do not name the admin who issued them, which removes a common revenge vector; and txAdmin-menuPlayerIdDistance sets how far the ID overlay reaches, defaulting to 150 metres. Every admin action is logged, which is what makes a permissions argument settleable after the fact.

5. The console is for reading, not only for typing

The live console streams the same output a terminal would, writes it to a log file, keeps a command history, and — the part almost nobody finds — is searchable. If a resource has been throwing the same error every ninety seconds for a fortnight, that search box is how you discover it.

Reading a crash properly is worth a dozen support tickets. The last line before the process died is almost never the cause, it is the symptom. Scroll back to the first SCRIPT ERROR or the first resource that failed to load and start there; everything after it is fallout.

The other habit is stopping and restarting individual resources instead of the whole server. That is what commands.resources gates, and restarting one misbehaving script keeps forty people in the world rather than dropping them to fix a typo in one file. The CPU, memory and thread charts on the same page usually point at which resource to touch.

6. Bans in txAdmin are not bans in your framework

txAdmin keeps its own player database and needs no MySQL to do it — identifiers, hardware IDs, playtime, notes, warnings and bans, in playersDB.json under txData. Enforcement happens during the connection deferral, before resources load, which is also how the whitelist modes work: Approved License, Discord Member, Discord Role, or admin-only, each with its own rejection message.

Here is the thing that catches everyone running ESX or QBCore. Your framework has its own bans, in its own MySQL tables, enforced by its own code. txAdmin has no idea they exist and they have no idea txAdmin exists. Unbanning someone in the panel does not touch a framework ban, and a player let through by one can still be rejected by the other, which produces the maddening support ticket where an admin is certain they lifted a ban and the player is certain they are still blocked.

Pick one system as authoritative. If that is txAdmin, bridge it: txAdmin:events:playerBanned fires with author, reason, actionId, expiration, targetIds and targetHwids, and there are matching events for warnings, kicks and actionRevoked. A small resource listening to those can keep the framework's table in step. This is the same class of problem as the menu being unable to revive a player on a framework server — the framework owns the dead state, so the resource has to handle txAdmin:events:playerHealed itself. txAdmin publishes the event; wiring it up is yours.

7. txAdmin does not back up your database

Master Actions has a database backup button, and a great many owners have concluded from its existence that they are covered. They are not. That tool covers txAdmin's own player database — the JSON file above. It does not touch the MySQL or MariaDB schema where your framework keeps characters, inventories, vehicles, bank balances and property.

Everything that makes your server yours lives in three places, and txAdmin manages none of them for you: the resources folder, server.cfg, and the SQL database. A scheduled mysqldump written to storage that is not the same machine is the minimum, and the restore has to be tested at least once, because an untested backup is a belief rather than a backup. The full picture of what to save and how often is a separate job from anything in this panel.

8. The deployer is fine for a base, and not a shortcut past the hard part

The recipe system builds a working server from a template in about a minute — it fetches resources, prepares the database and writes a starting server.cfg. For a first server the default Cfx recipe is a genuinely good way to get something running that you understand.

What it cannot do is give you a community. A recipe that drops a complete roleplay framework in place leaves you administering several hundred resources you did not choose and cannot debug, which is the usual origin story for a server that dies at three weeks. Start from the plain base, add deliberately, and look at what the servers people actually stay on have in common before copying any of it.

The hardening checklist

• Master account on Cfx.re login, not a local password. No reused passwords for any admin.
• TXHOST_INTERFACE set to 127.0.0.1, reached over SSH tunnel or VPN. If it must be remote, HTTPS reverse proxy with an IP allowlist — never bare HTTP on 40120.
• Staff get players.* permissions only. console.write, server.cfg.editor, settings.write and manage.admins stay with the owner. all_permissions for nobody but you.
• Remove admin accounts the day someone leaves the team, not the week after.
• A scheduled mysqldump off the box, plus resources and server.cfg, with one restore tested.
• Something listening to txAdmin:events:serverShuttingDown so a restart saves state.
• Migrate off the deprecated txAdminPort / txAdminInterface / txDataPath ConVars before they stop working.

Once that is done, the panel is what it should be: the reason you never open a terminal. And with restarts scheduled and bans in one place, the remaining question is whether anyone can find the server — which is a listing problem, solvable by putting it on the FiveM directory and adding it here.