txAdmin is the FiveM management panel that ships inside FXServer

There is no txAdmin install step because FXServer starts it

The most surprising thing about txAdmin is that you cannot install it. Since early 2020 the panel has been a component of FXServer, so there is nothing to download and nothing to run separately.

The startup rule is a single condition. Run FXServer without any +exec server.cfg launch argument and FXServer starts txAdmin automatically. That single detail has a second consequence worth stating plainly: an operator who launches with that argument gets a plain FXServer with no panel at all. The panel is not a separate process that can be started alongside the server, it is a mode the server enters.

On first boot, a txData directory is created to hold txAdmin files, and the console prints a URL you open to configure your account and the server. So the practical flow is: start FXServer, read the URL from the console, complete the setup in the browser. There is no installer and no configuration file to hand edit for the initial setup.

Most configuration happens afterwards in the txAdmin settings page, but the README notes exceptions. Settings such as the TCP interface and port are only available through environment variables, which are described in docs/env-config.md.

The recipe deployer builds a server in under a minute

The headline feature is a recipe-based server deployer, documented separately in docs/recipe.md and described in the README as creating a server in under 60 seconds.

The idea is that a server owner does not assemble a server configuration by hand. A recipe describes the setup, and the panel applies it, which means a fresh instance can be standing up before the owner has finished thinking about configuration. For people who have never administered a FiveM server, this is the difference between a working server and a blank directory.

Around that sit the controls the README lists: starting, stopping and restarting the server instance or individual resources. Both levels matter, because a resource-level restart is the common case when a script misbehaves and taking the whole server down for it is disruptive.

The panel also includes FiveM's server CFG editor and validator. A validator catches mistakes in the cfg before they become a server that will not boot, which is one of those small features that removes more support tickets than it should. The rest of the configuration surface is documented across separate files: docs/permissions.md for the admin permission system, docs/events.md for scheduled restarts with warning announcements and custom events, and docs/custom-server-log.md for the server activity log.

Access control rests on Cfx.re login and a permission system

The panel exposes powerful actions, so who can trigger them matters more here than in a typical dashboard.

Two login paths are supported: Cfx.re or password. The Cfx.re route ties panel access to a Cfx.re account, which removes the need for a separate credential store for operators who already have one. On top of that sits an admin permission system documented in docs/permissions.md, and an action logging feature that records what admins did.

Action logging is the part that distinguishes this from a hobby panel. The monitor features and the in-game admin menu both include capabilities that can be disruptive to players, from teleporting and freezing to banning, so a log of admin actions is what lets a server owner answer the question of who reset the world area last Tuesday.

The panel can also listen to server events broadcast by txAdmin so that custom resources can react, which the README points to docs/events.md for. In other words the panel is not a closed loop: it can hand events back to your own server code.

One piece of configuration is deliberately outside the web UI, though. Environment variables are the only route for the TCP interface and port, so a deployment behind a proxy or on a non-default interface has to be configured outside the settings page.

Monitoring covers crashes, hangs, resource use and the console

The monitoring section is the broadest part of the feature list, and it covers three distinct needs that a server owner would otherwise assemble from separate tools.

First, continuity. FXServer is automatically restarted on crash or hang, which is what keeps a server online when a resource takes the process down or deadlocks it. Second, resource visibility, with the server's CPU and RAM consumption shown, plus a thread performance chart that includes the player count, so you can see a memory climb coincide with the arrival of a specific group of players.

Third, the live console, which includes a log file, command history and search. The history and search features are what turn it into a diagnostic tool rather than a scrollback buffer: when a player reports a problem you can find the relevant lines and the commands that preceded them.

Alongside that sits the server activity log, which records connections and disconnections, kills, chat, explosions and custom commands. The docs/custom-server-log.md file covers the custom command side, which is how you get your own server events into the same stream.

The trade-off is volume. This is a lot of instrumentation to run in-process next to the game server, and the README does not document what the overhead looks like, so an operator with a tight CPU budget has to judge that from their own monitoring.

The in-game admin menu operates on live players and their vehicles

Besides the browser panel, txAdmin ships an in-game admin menu, and it is far more hands-on than the web interface.

The README groups its abilities by target. Player mode offers NoClip, God and SuperJump. Teleport covers the waypoint, explicit coordinates and a return trip. Vehicle actions spawn, fix, delete and boost. Healing applies to yourself or everyone, and there are announcements and a world area reset. Player lists can be searched and sorted by distance, ID or name, and there is a player id display.

The interaction set is the part with consequences for other players: Go To, Bring, Spectate and Freeze. The prank set is called player troll in the README and covers making a player drunk, setting them on fire and a wild attack.

From there the admin functions continue outside the game, through the player manager, which holds a warning system, a ban system and a whitelist system with Discord member, Discord role, approved license and admin-only options. There are notes on players, tracking of play and session time, and a self-contained player database that the README stresses requires no MySQL. That last point is the one that decides adoption for many small server operators, because a separate database server is the usual reason a player history system never gets installed.

The database can also be cleaned up, removing old players along with bans, warns and whitelist entries.

Discord integration and a scheduled restart system close the loop

Two features sit between the panel and the server community.

The Discord integration keeps a server configurable, persistent and auto-updated status embed, and it adds two commands, one to whitelist players and one to display player information. The whitelist is the useful half for many servers, because it means access decisions can be tied to a Discord role rather than to a list maintained by hand.

The scheduling side handles restarts with warning announcements and custom events, documented in docs/events.md. Warnings matter more than they sound, since a hard restart during a session loses whatever the server had in flight. The custom events part is the extension point, letting your own resources react to a restart that the panel initiated.

A couple of smaller items round out the panel. There is a real-time playerlist, and the interface is described as a responsive web interface with dark mode. The README states the project is translated into over 30 languages, with details in docs/translation.md.

The repository also keeps a docs/feature-graveyard.md file for features that are no longer among us, which is an unusually honest document to find. It means the feature list above is the current list, not the accumulated one, and it is the file to read if you are migrating from an older panel.

A four-workspace monorepo with its own build, test and licence pipeline

The repository layout shows a monorepo with npm workspaces. The root package.json lists core, nui, panel and shared as the workspaces, and the module entry point is./core/index.js with type set to module. Alongside them are directories named resource/, locale/, scripts/, web/, docs/ and entrypoint.js.

The root scripts describe how the project is assembled and checked.

"build": "rimraf dist tmp_core_tsc && npm run build -w nui && npm run build -w panel && npm run build -w core && npm run license:distfile",
"test": "npm run test --workspaces",
"typecheck": "npm run typecheck --workspaces",
"locale:rebase": "node scripts/locale-utils.js rebase",
"locale:check": "node scripts/locale-utils.js check --color"

The build runs the three workspace builds in order and then generates a third party licence file into dist/THIRD-PARTY-LICENSES.txt, which is the kind of step that matters for anyone who has to ship a licence attribution file with their distribution.

Dependencies are modest for a panel of this size: chalk, dequal, humanize-duration, jsonrepair, lodash-es and semver. The tooling is eslint 9, husky, commitlint with a conventional config, and esbuild.

The contribution rules are strict enough to mention here, because they affect whether you can realistically patch it. Pull requests should be based on the develop branch, including translation pull requests, and the README asks contributors to join the Discord server and discuss significant changes first, since a requested change may have been declined for a reason or may need context.

MIT for the code, permissive licences for the bundled audio

The licence field on the repository says MIT, and the README links to the MIT License file. The credits section is more nuanced, because the bundled sounds carry their own terms.

The kick button icons are credited to SeyfDesigner from flaticon.com. The warning sounds are licensed under CC 3.0 BY, the announcement sound under CC BY 4.0, and the message sound under CC0 1.0, each with individual credits and links in the README. Attribution obligations come with the CC BY variants, so a redistribution that keeps the panel intact generally means keeping those credits, while the CC0 message sound carries no restriction.

On versions, the recent releases are v8.1.0 on 2026-06-03, v8.1.1 on 2026-06-05 and v8.0.1 on 2025-03-08. The gap between 8.0.1 and 8.1.0 is more than a year, so the 8.1 line was a large step rather than a quick follow-up.

The repository is not archived and the last push was on 2026-10-22, so work on the project is current, and the README itself states the panel is in use by over 29,000 servers at any given time. Whether that number matches your expectations of the FiveM ecosystem is worth checking against the community rather than taking on trust.

Editorial conclusion

txAdmin is the right choice for anyone running a public FiveM or RedM server who needs a web panel, crash recovery and a player history without standing up a database server, and it costs nothing to install because FXServer already carries it. It is the wrong choice for a headless server you drive entirely from configuration files, because every management affordance depends on the panel being active. Before adopting it, read the recipe documentation, check which settings still require environment variables such as the TCP interface and port, and confirm that the features you relied on have not moved to docs/feature-graveyard.md.

Frequently asked questions

Official sources

1. citizenfx/txAdmin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases