How to Install txAdmin and Create Your FiveM Server (Full Tutorial)

Almost every FiveM server running today was created with txAdmin — the web control panel bundled inside the official server build. It handles deployment, restarts, bans, the console and your server.cfg from a browser tab, and it can install a complete ESX or QBCore base for you in a few clicks.

This tutorial goes from an empty folder to a server your friends can join, explaining why each step matters — not just what to click.

What you need before you start

• A machine to run it on — your own PC for testing, or a rented host/VPS for anything public.
• A free Cfx.re account for your license key.
• MySQL or MariaDB — every serious framework needs a database.
• About 45 minutes.

On Windows, install the Microsoft Visual C++ Redistributable (x64) first. FXServer will not start without it, and the error it prints is cryptic — this single missing dependency causes a large share of “it just closes instantly” posts.

On Linux, you need xz-utils to extract the build, plus a MySQL/MariaDB server.

Step 1 — Get your Cfx.re license key

Go to keymaster.fivem.net, sign in with your Cfx.re (forum) account, and register a new server key.

• Choose “I’m using a server hosting provider” or a fixed IP if you know it — you can change this later.
• Copy the key somewhere safe. It looks like a long random string.

This key identifies your server to Cfx.re. Treat it like a password: never paste it in a Discord screenshot, never commit it to GitHub. A leaked key can be used by someone else and get yours revoked.

Step 2 — Download the server artifacts

The artifacts are the actual FiveM server build (FXServer). Download them from the official runtime:

• Windows — runtime.fivem.net/artifacts/fivem/build_server_windows/master/
• Linux — runtime.fivem.net/artifacts/fivem/build_proot_linux/master/

Pick the build marked recommended, not the newest one at the top. Bleeding-edge artifacts routinely break resources, and the recommended build is the one script developers actually test against. We track this in our server artifacts guide.

Extract it into a dedicated folder — for example C:\FXServer\server\ on Windows, or /home/fivem/server/ on Linux.

Step 3 — Set up your folder structure

Keep the build and your server data in separate folders. This is the single best habit you can start with: updating artifacts later becomes “delete and replace one folder” instead of a careful surgery around your own files.

C:\FXServer\
├── server\          <- the extracted artifacts (replaceable)
└── server-data\     <- your resources, server.cfg, database dumps

When you update FiveM in six months, you wipe server\, extract the new build, and everything you actually own is untouched.

Step 4 — Start the server for the first time

Run the executable:

• Windows — double-click FXServer.exe inside server\.
• Linux — cd into the folder and run ./run.sh.

A console window opens and txAdmin starts. You will see something like:

[txAdmin] Starting txAdmin v7.x.x
[txAdmin] Web UI: http://localhost:40120
[txAdmin] PIN: 4821

Open that URL in a browser and enter the PIN.

Step 5 — Create your master account

txAdmin asks you to create the master account — the top-level admin that can never be removed by other admins.

Use a real password, not admin123. This panel can execute console commands on your server; anyone who reaches it owns your community. You can optionally link a Cfx.re or Discord identity for easier login.

Lost it later? Stop the server and start it once with --resetadmin:

FXServer.exe --resetadmin

Step 6 — Prepare the database

Before the deployer runs, have MySQL/MariaDB ready. On Windows, the usual route is XAMPP or a standalone MariaDB install; on Linux, mariadb-server from your package manager.

Create an empty database (for example fivem) and a user with full rights on it. You will hand txAdmin a connection string in the next step, in this shape:

mysql://user:password@localhost/fivem?charset=utf8mb4

Use a dedicated user, not root, and give it a real password. A framework database ends up holding every player’s characters, money and inventory — it is the one thing you genuinely cannot rebuild.

Step 7 — Deploy a framework with the recipe deployer

Now the part that makes txAdmin worth it. The setup page offers several deployment types; choose popular recipes, then pick your base:

• ESX — the biggest ecosystem; easiest to find scripts, tutorials and staff who know it.
• QBCore — modern and roleplay-first.
• Qbox — a performance-focused continuation of QBCore.

Undecided? Read our ESX vs QBCore vs Qbox comparison before you commit — migrating later is real work.

txAdmin then asks for:

1. A server name and the data folder (server-data\).
2. Your database connection string from step 6.
3. Your license key from step 1.

Hit deploy. txAdmin downloads the framework, imports the SQL, writes a working server.cfg, and starts the server. Watch the log: it tells you exactly which piece failed if something does.

Step 8 — Check your server.cfg

The recipe writes a functional config, but you should understand what is in it. txAdmin has a built-in CFG editor (Settings → CFG Editor) so you never need to touch files over FTP for small changes.

The lines that matter most:

sv_hostname "My Roleplay Server"
sv_maxclients 48
sv_licenseKey "your-key-here"

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# OneSync — required for more than 32 players
set onesync on
sv_enforceGameBuild 3095

Two notes people learn the hard way:

• sv_maxclients is not a growth strategy. Start at 32–48. An empty 128-slot server looks dead; a full 48-slot server looks alive.
• sv_enforceGameBuild pins the GTA build your server expects. Change it only when a resource genuinely needs newer DLC content, and expect to test everything again afterwards.

Step 9 — Open the right ports

Players connect on 30120, TCP and UDP. If you only forward TCP, the server appears in the list but nobody can actually join — a classic afternoon-losing mistake.

Never expose 40120 publicly. If you need remote access, put it behind a VPN or a reverse proxy with HTTPS and a strong password. An open txAdmin panel on the raw internet is a full remote console for your server, and bots do scan for it.

Step 10 — Learn the panel

Spend ten minutes here; it pays for itself:

• Dashboard — live performance graph. When players say “the server is lagging”, this is where you confirm it.
• Live Console — the real server console in your browser. Read it top-to-bottom and always fix the first red error; the rest are usually cascades.
• Players — search, warn, kick, ban, and see history per identifier.
• Restarter — scheduled restarts. Set them from day one (see below).
• CFG Editor — edit server.cfg without FTP.
• Discord bot — optional; status messages and whitelisting via roles.

Set up scheduled restarts now

Under Settings → Restarter, schedule restarts every 6–12 hours. Long-running FXServer instances accumulate memory and slowly degrade, and a scheduled restart with a warning countdown is invisible to players. An unplanned crash at peak hours is not.

Step 11 — Add your first resources

With a framework running, resources go in server-data/resources/, each enabled with an ensure line. Order matters — dependencies start first:

# Core — these come first
ensure oxmysql
ensure ox_lib
ensure es_extended

# Gameplay
ensure my-inventory
ensure my-hud

Add resources one at a time, restarting between each. If you drop in fifteen scripts and the server dies, you have fifteen suspects. Add them one by one and you always know exactly what broke.

The systems players notice first are the inventory and the HUD — they are on screen constantly, so they define how your server feels more than any job script. Our best FiveM inventory scripts guide compares the field; if you want one that covers ESX, QB, QBCore and Qbox from a single codebase, Quasar Inventory is the polished all-rounder we keep coming back to in testing. For the step-by-step install, follow our inventory installation tutorial.

Step 12 — Test properly, then go live

Connect locally with connect localhost from the FiveM client (F8 console), then have a friend join via your public address.

Walk the full loop before you announce anything: spawn, get a job, earn money, open the inventory, store an item, buy and retrieve a car, relog and confirm it all persisted. Relogging is the real test — most “my server loses player data” reports are a database issue that only shows up on reconnect.

Back up your database — txAdmin will not do it for you

This is the most common gap in an otherwise well-run server. txAdmin manages your server; it does not back up your database. Set up your own dump on a schedule:

mysqldump -u fivem -p fivem > backup-$(date +%F).sql

Automate it (cron or Task Scheduler), and keep copies off the machine. A server you can rebuild in an afternoon is an inconvenience. A database you cannot restore is the end of the community.

Troubleshooting

Where to go next

You now have a running, restartable, backed-up server. The two things that decide whether players stay are performance and a coherent core loop — not how many scripts you have.

Read our server optimization guide before your first busy night, and how to reduce server lag when it inevitably arrives. Then lock the doors: our server security guide covers what to harden before you are worth attacking.