What exactly is txAdmin?
txAdmin has been bundled with FXServer by default since 2020: there is nothing to buy or install separately. On the first launch of FXServer, txAdmin starts automatically and exposes a web interface (default port 40120). It is the FiveM community standard, open-source and maintained by the Cfx.re team.
- Live console: real-time server logs, commands, history
- Recipes: automatic deployment of a full server base (QBCore, ESX Legacy, vanilla)
- Scheduler: scheduled restarts with in-game announcements
- Player management: bans, warns, whitelist, notes, per-identifier history
- Monitoring: crash detection with automatic restart
Requirements
- A VPS with at least 4 GB of RAM — 8 GB recommended for a QBCore/ESX base with players. On Linux, Debian and Ubuntu are the best-documented distributions: see our Debian VPS and Ubuntu VPS pages. On Windows, you need a Windows VPS with RDP access.
- A free licence key created on portal.cfx.re (mandatory for any FiveM server), set in
server.cfg through sv_licenseKey
- Ports 30120 in TCP and UDP (game) and 40120 in TCP (txAdmin panel) open in the firewall
- A MariaDB or MySQL database if you deploy a roleplay framework: both QBCore and ESX store characters, inventory and economy there
Installing on a Linux VPS
Download the latest FXServer build from runtime.fivem.net, extract it into a folder (e.g. ~/fxserver), then run ./run.sh. txAdmin starts automatically and prints a 4-digit PIN in the terminal, valid for a few minutes. Open http://VPS-IP:40120 in your browser, enter the PIN, then link your Cfx.re account: that becomes your admin identity. So the server survives an SSH disconnect, run it inside tmux, screen or as a systemd service — the next section gives the full unit.
Running FXServer as a systemd service
A server started by hand in a terminal dies with your SSH session, and does not come back if the VPS reboots. A systemd service fixes both. Create /etc/systemd/system/fxserver.service with the content below, replacing the user and paths with your own:
[Unit] — Description=FXServer FiveM then After=network.target mariadb.service: the server does not start before the network and the database are ready[Service] — User=fivem, WorkingDirectory=/home/fivem/fxserver, ExecStart=/home/fivem/fxserver/run.sh, Restart=always, RestartSec=10[Install] — WantedBy=multi-user.target- Then
systemctl daemon-reload, systemctl enable --now fxserver, and journalctl -u fxserver -f to read the startup logs — that is where the PIN appears on the first run
Run the server under a dedicated account
Do not run FXServer as root. Create a dedicated system user (adduser --system --group fivem), put the server folder there, and give it ownership of txData. A badly written third-party resource — and plenty circulate in the roleplay ecosystem — then only reaches the game files, not the rest of the machine. On a VPS that also hosts a website or a database, that separation is the bare minimum.
Installing txAdmin on a Windows VPS
FXServer also ships as a Windows build, and many roleplay communities stay on it because their development tooling runs there. The principle is identical: download server.zip from runtime.fivem.net, extract it, and run FXServer.exe. txAdmin starts, prints the PIN in the console window, and the panel answers on http://VPS-IP:40120. A few differences are worth knowing:
- The Windows firewall blocks by default: create two inbound rules, one for port 30120 in TCP and UDP, one for port 40120 in TCP (Windows Defender Firewall with Advanced Security, or
New-NetFirewallRule in PowerShell)
- The console window closes with the RDP session: to keep the server running, register
FXServer.exe as a Windows service (NSSM and WinSW are the two tools the community uses) or use a scheduled task triggered "at computer startup"
- Plan for more memory than on Linux: the operating system itself uses more. On our Windows VPS, the entry plan starts at 8 GB, which leaves the headroom a QBCore or ESX base needs
- The Microsoft licence is not supplied: it is an extra cost to plan for, unlike a Linux VPS
Deploying a base with recipes
On first access, the txAdmin wizard offers to deploy a recipe: a complete server base installed automatically (framework, database, starter resources). Pick QBCore or ESX Legacy for a roleplay server, or a vanilla base to start from scratch. The recipe also configures the MySQL/MariaDB connection — on a VPS, install MariaDB first and create a dedicated database.
Which ports to open, and why
Only three ports, but a classic mistake is opening 30120 in TCP only. FiveM uses the same port number in TCP and in UDP: TCP serves discovery and the server list, UDP carries the game traffic. A server that shows up in the list but that nobody can join is, almost always, forgotten UDP.
- 30120/tcp and 30120/udp: the game. Open to everyone. On Debian or Ubuntu,
ufw allow 30120 opens both protocols at once
- 40120/tcp: the txAdmin panel. Restrict it to your own IP address, see below
- 3306/tcp (MariaDB): do not open it to the outside. The database runs on the same machine as FXServer and is reached at
127.0.0.1. An exposed MySQL port is one of the fastest ways to lose a character database
- The game port can be changed (
endpoint_add_tcp and endpoint_add_udp in server.cfg): useful to run a production server and a test server on the same machine
How much hardware per player count
The RAGE engine leans heavily on a single core: processor frequency matters more than the vCore count. A VPS with 8 slow cores will hold fewer players than one with 4 fast ones. On the memory side, third-party resources decide — a full roleplay server easily loads a hundred scripts.
- Vanilla base, a handful of players: 4 GB of RAM is enough, the floor to run FXServer at all
- QBCore or ESX, 20 to 40 players: 8 GB. The fifty-odd scripts of a starting roleplay server take 2 to 4 GB on their own, and MariaDB asks for about one more
- Established server, 64 slots and beyond, custom scripts: 16 GB, and SSD storage — database round-trips are constant during sessions
- Disk: count the weight of your resources plus the database, and keep room for backups. Roleplay servers grow over time, never the other way round
The txAdmin console day to day
The Live Console tab shows server logs in real time and accepts every FXServer command (refresh, ensure my-resource, restart es_extended...). Sensitive actions are logged per admin account: every kick, ban or restart is traced, which helps when several moderators run the server.
- Scheduler: set 1 or 2 restarts a day with automatic announcements — a FiveM server's memory fragments over time
- Backups: back up your data folder and the MySQL database regularly (txAdmin does not back up the DB for you)
- Permissions: create one admin account per moderator with limited rights, rather than sharing the main account
Updating FXServer and txAdmin
txAdmin has no separate update: it is embedded in the FXServer artifact, so updating the server updates the panel. The operation is simple but must follow the order, or a configuration gets lost.
- Take a VPS snapshot from the client area, or at minimum a copy of the server folder and a database export
- Stop the server cleanly (
systemctl stop fxserver, or the Stop button in txAdmin)
- Replace only the artifact files — do not touch
txData/, your resources/ folder or server.cfg: those are your data, not the server's
- Restart, then check in the console that every resource loads. A resource incompatible with the new build shows up immediately in the logs
- Keep the previous artifact for a few days: rolling back then means putting the old folder back
Backing up what actually matters
One remark comes up often in support tickets: "txAdmin does backups, right?" It does, but not of what you think. The database is not backed up by txAdmin. Yet it holds the characters, vehicles, bank accounts and inventories — everything your community built and nobody will forgive you for losing.
- The database: a daily
mysqldump in a cron job, sent somewhere other than the VPS itself
- The
txData/ folder: it holds admins.json, the panel configuration and the sanction history
- Your
resources/ folder and server.cfg: especially if you edited purchased scripts, those edits exist nowhere else
- VPS snapshots cover the whole machine and restore in one click from the client area. They complement database exports, they do not replace them: a snapshot also restores the mistake you wanted to undo
Securing access to the panel
An admin panel exposed on a public IP is an obvious target. Three measures are enough:
- Restrict port 40120 to your IP:
ufw allow from YOUR_IP to any port 40120 then ufw deny 40120 — only your co-admins reach the panel, while the game port (30120) stays open to everyone
- Never disable authentication, even "just for testing": txAdmin's passwordless mode is meant for local dev only, never on a public VPS
- HTTPS reverse-proxy in production (optional): Nginx or Caddy in front with a subdomain and a Let's Encrypt certificate, rather than exposing
ip:40120 in the clear — make sure WebSocket headers (Upgrade/Connection) are forwarded, the live console depends on them
- One admin account per person, with the fewest rights needed: txAdmin logs actions per account, which is worthless if everyone shares the same login
Common issues and fixes
- Page 40120 unreachable: the port is closed — open it in the firewall (
ufw allow 40120/tcp) or check that txAdmin is listening (startup logs)
- The server shows in the list but nobody can join: port 30120 is open in TCP only. Open it in UDP as well
- Expired PIN: restart FXServer, a new PIN is printed in the terminal
- Lost admin access: stop the server and delete
txData/admins.json — txAdmin relaunches the first-start wizard
- "Invalid license key": the Cfx.re key is tied to an IP address. If you moved servers, regenerate it on portal.cfx.re and replace the
sv_licenseKey line in server.cfg
- The live console stays empty behind a reverse-proxy: WebSocket headers are not being forwarded. Add
Upgrade and Connection to the Nginx configuration
- The server restarts in a loop: read the logs just before the crash. Nine times out of ten it is a third-party resource added the day before — remove it from
server.cfg and restart to confirm
- Laggy server: watch the monitoring tab; if RAM is maxed out with your base and players, move to a bigger VPS plan. Plan changes are done from the client area, without reinstalling
- Repeated attacks during sessions: busy roleplay servers are targeted regularly. Network-level filtering is the only cure; see our guide Understanding Anti-DDoS
