txAdmin as a supervisor, not a control panel

txAdmin is installed on most FiveM servers and used as a web console by nearly all of them. That is the smallest part of what it does, and treating it as a control panel means the two things it is genuinely good at go unconfigured.

Cfx.re documents setting up a server with txAdmin. What follows is which of its features earn their place.

It is a process supervisor first

txAdmin runs FXServer as a child process, watches it, and restarts it when it stops. That is the job: the web interface is how you talk to the supervisor, not the point of it.

The consequence people miss: if txAdmin dies, the server dies with it. So txAdmin itself needs supervising. On Linux that is a systemd unit around txAdmin, not around FXServer, and getting that layering backwards produces a setup where the thing meant to keep you alive is the single point of failure nobody watches.

Scheduled restarts, and why they are not a bandage

The scheduled restart feature exists because FiveM servers accumulate. Resources leak, entity counts drift upward, and performance degrades over hours in a way that a restart resets.

Using it is not an admission of failure. It is cheaper than finding every leak in thirty third-party resources you did not write, and a restart at 06:00 when nobody is on costs nothing.

What matters is the warning. txAdmin can announce a restart in advance, and a server that drops forty roleplayers mid-scene without notice loses more than it gains. Set the warnings. Five minutes, one minute, thirty seconds.

If restarts are needed every two hours rather than every twelve, that is a different problem and no schedule fixes it: that is a resource leak, and it belongs with the rest of the lag investigation.

Crash recovery, which is the feature you will actually rely on

When FXServer exits unexpectedly, txAdmin restarts it. It also records that it happened, which is the part with lasting value.

A server that crashes once a week and restarts in twenty seconds looks healthy from the outside and is not. The crash log is the evidence, and it is the only place the pattern is visible: the players saw a brief disconnect and reconnected, and nobody reported anything.

Read it weekly. A rising crash count is the earliest signal you will get that something recently added is unstable, and it arrives long before anyone complains.

The deployer, and when not to use it

txAdmin can deploy a recipe (a prepared framework install) in one step. For a first server this is genuinely useful and saves an evening.

For an existing server it is a trap, because a recipe expects to set up a database and a resource tree from scratch. Running one against a live server is how people lose a configuration they spent months on.

The undo is a backup you have already tested, and only that. There is no confirmation step that explains what is about to be replaced, because from the deployer's point of view nothing is being replaced: it is building a server, and you happened to point it at one.

What it should not own

Bans and whitelists. txAdmin can do both, and its implementations are tied to txAdmin: move away from it, or lose the install, and the data goes with you only if you thought about it beforehand.

If your server is small and txAdmin is your whole administration stack, that is a reasonable trade. If you are running a framework that already has its own ban tables, having two systems that both think they own bans produces the situation where somebody is banned in one and not the other, which is the same class of confusion as two permission systems disagreeing.

The admin log is the underrated half

Everything above is about keeping the process up. The feature that earns its place over months is the record of who did what.

txAdmin logs every action taken through it against an identity: the kick, the warn, the ban, the restart, the resource that somebody stopped at two in the morning. On a server with more than one person holding permissions, that log is the only thing that can answer "who did this" without an argument, and it is the difference between a moderation team and several people with the same password.

It is also the thing that makes handing over permissions reversible. You can give somebody access, watch how they use it for a fortnight, and have an actual basis for the conversation afterwards, which is most of what makes recruiting staff survivable.

A sensible arrangement

systemd supervises txAdmin. txAdmin supervises FXServer. Scheduled restart once daily, off-peak, with warnings. Crash log reviewed weekly. Deployer used once, at the beginning, and never again. Bans in whatever your framework uses.

That layout survives the things that actually happen: a host reboot, a bad resource, a crash at four in the morning. It is the same shape as any other server that comes back on its own — something above the game process is watching, and something above that is watching it.