txAdmin: what it is, how to set it up and what it really does

txAdmin is the web admin panel for FXServer, maintained by the Cfx.re team and shipped inside the official artifacts. It is not a resource you drop into your resources folder: it is the process that starts, supervises and restarts your server, and gives you a browser interface to do it.

Its role is supervisor. When you run FXServer with no arguments, what starts is txAdmin, and txAdmin is what launches the actual server process with your server.cfg. That explains three things that confuse people: if the server hangs, txAdmin stays alive and can restart it on its own; server.cfg changes do not apply on save, you have to restart from the panel; and the console you see in the browser is the real server console, with write access. Whoever gets into the panel can run commands.

Download the artifacts for your platform, create two separate folders (one for artifacts, one for server data), and run the binary. txAdmin gives you a local URL with a one-time PIN, normally on port 40120.

Inside the wizard you get three routes: a popular template (a recipe that deploys ESX Legacy or QBCore with dependencies and a database), a remote recipe URL, or pointing at existing server data for a migration. You will need a Keymaster server key and a reachable MySQL or MariaDB instance. If the wizard fails at the database step, it is almost always that the user lacks permission to create schemas, not that txAdmin is broken.

Be realistic about recipes: they leave you a server that boots, not a server you can open. What comes out is an empty base with the framework running. Content, economy balance, jobs, mapping and rules are on you, and that is where the time actually goes.

Scheduled restarts. FXServer accumulates memory and state over hours, and poorly optimised scripts accelerate it. A restart every six to eight hours, announced in chat with enough warning, avoids the classic server that gets slower until it dies at peak. Schedule them in your own quiet hours, which depend on where your players actually live.

Real backups. txAdmin backs up the server directory, which covers resources and configuration. It does not cover the database, and the database is where characters, vehicles, properties and money live. Losing the directory costs a weekend; losing the database costs the community. Set up a separate scheduled mysqldump, store it off the server machine, and restore it once before you need it. A backup you have never restored is a folder, not a backup.

Scoped admin permissions. Console access equals full control of the server, and resource management lets anyone stop anything. Give each staff member what their role needs and nothing more, and use individual accounts, never a shared one: txAdmin's action log only tells you who did what if each person has their own login.

Performance supervision. The performance tab shows server tick time. It is the best early warning that a resource is killing your server, and if the tick climbs steadily you have an optimisation problem, not a hosting problem. Cross-check it with client-side resmon to find the culprit.

Port 40120 should not be exposed to the internet as-is. Three measures, in order of importance: two-factor authentication on every admin account starting with yours; the panel behind a reverse proxy with HTTPS or reached over an SSH tunnel, never plain HTTP, which sends your credentials in the clear; and unique long passwords, because the panel gives console access and the console gives everything.

The common real-world case is a server that looks hacked when what happened is that someone reused their Discord password in txAdmin and the leak came from somewhere else entirely. The attack surface of a FiveM server is usually the panel, not the game.

Server boots and immediately closes: almost always the Keymaster key, invalid, expired or bound to another IP. The console says so explicitly in the first lines.

Server never appears in the list: ports. 30120 on TCP and UDP has to be open and forwarded. 40120 is only the panel and cannot be used by players.

server.cfg changes do nothing: you have not restarted from the panel, or you are editing a different server.cfg than the one txAdmin is configured to use. The settings tab shows the exact path.

A resource does not load even though the folder is there: missing ensure in server.cfg, or an error in its fxmanifest.lua.

Recipe deploy stops halfway: usually database permissions or a blocked download. Delete the data directory and start clean, because a half-applied recipe leaves the server worse off than not running it.

It does: start, stop and restart the server; web console; admin accounts with scoped permissions; scheduled restarts; directory backups; performance and player supervision; moderation actions with history; recipe deployment.

It does not: optimise your scripts, act as an anticheat, back up your database, run your store or payments, or replace a hosting panel.