Managing staff on a FiveM server

Staff permissions are a security boundary, not a reward for helping out. Every admin you add is another identity that can teleport, spawn, ban, and wipe, and another way into your server if that person's account or machine is compromised. Hand out the smallest set of powers that lets someone do their job.

Decide roles by the actions they need

Write the list down before you grant anything, because permissions drift upward on their own. A rough shape that works for most servers:

Those three moderation roles stack, which is what makes group inheritance below work. Developer is a separate ladder rather than a rung on this one: it needs to start, stop, and restart resources on staging and to read logs, and it does not need any moderation power at all.

Two rules that save arguments later. Spawning money, vehicles, or items is not a routine moderator power, and it should never sit with the people who handle disputes about the economy. And "trusted long-serving player" is not a role: if someone does not perform an action, they do not need the permission for it.

Least privilege, applied to game admins

• Deny by default and grant named actions. Give a group the specific commands its role uses. A group that has every command is not a role, it is a second owner.
• One principal per person. Never a shared staff identity. If two people share one account, your logs record an action with no author, and a departure means changing access for everyone.
• Use a stable identifier. Prefer the license identifier over ones that depend on another program running on the player's machine, such as Steam or Discord, because those disappear when the program is closed.
• Grant for the task, then remove. A developer who needs to restart a resource once does not need permanent resource control.
• Separate playing from administering. Staff should be able to play without their admin powers loaded. An on-duty toggle that logs when it is switched on is enough, and it makes "was an admin involved" answerable.

Groups and principals in server.cfg

FiveM's permission system has two halves. Principals are identities: a player's identifier, or a group. Aces are the things a principal is allowed or denied, such as a command or a resource action. You put a person into a group, and you grant the group its aces. Groups can inherit from other groups by adding one group as a principal of another, which is how a moderator group picks up everything support can do without repeating the list.

In server.cfg that reads as three kinds of line:

# put a person in a group, using a stable identifier
# (a real license identifier is a long hex string, shortened here)
add_principal identifier.license:4f9b2c8ad1e6b73f0c5a1d8e group.moderator
 
# grant the group the actions its role needs
add_ace group.moderator command.kick allow
add_ace group.moderator command.spectate allow
 
# make one group inherit another, so admins get everything moderators have
add_principal group.admin group.moderator

The command names are not a fixed list. Each resource decides what it registers, so read the resource to find out what to grant rather than guessing at a name.

Removal is the matching pair, remove_principal and remove_ace, with the same arguments as the line you are undoing. Use deny sparingly and only where it earns its place, which is withholding one action from a group that would otherwise inherit it: a deny beats an allow, so a stray deny high up a chain silently removes a permission you granted somewhere else.

Keep these lines in their own file that server.cfg execs, rather than scattered through the main config. See Configuring server.cfg for exec and how the file is ordered. A single permissions file can be reviewed on its own, and you can see who has what in one screen. Treat it as sensitive: it is a list of your staff's identifiers.

Two practical points that catch people out:

Permission lines are additive. Re-running exec on a config adds what is in the file. It does not remove what you deleted from the file. Taking a line out and reloading leaves that person an admin until the server restarts or you explicitly remove the principal. This is the single most common way a removed admin keeps their powers for a week.

A group is not a person. Adding someone to a group grants everything that group inherits, including whatever a parent group picks up later. When you widen a group's aces, check who is in it and in every group that inherits from it.

rcon_password and full admin

There is a small set of things that are owner-level, not staff-level, and they do not become staff-level because someone has been around a long time:

• rcon_password. If it is set, anyone who has the string gets your server console over the network, and the console sits above every ace you configured. Leave it empty, which keeps the remote console off, and use txAdmin instead. If you do set it, use a long random value, do not expose the port publicly, and change it whenever a person with access leaves.
• The Cfx.re server key. Anyone holding it can run a server as you, and anything they do with it lands on your key.
• Host access. Your Clouduxe account, SSH or RDP credentials, and the database credentials. See Opening a ticket if a departing staff member held the hosting account itself.
• The txAdmin owner account.

Logging admin actions

The point of logs is not catching people. It is being able to review a decision three weeks later when a player disputes it, and being able to answer "what did that admin actually do" without guessing.

• Capture the console. FXServer writes to its console; if you do not send that to a file and rotate it, it is gone at the next restart.
• Audit both permission systems. Ace principals in server.cfg and txAdmin accounts are independent. txAdmin ships with FXServer, keeps its own admin accounts, and records its own action history. Someone can hold a txAdmin account with no aces at all and still restart your server. A review that only reads server.cfg misses half your admins.
• Log the decision, not only the command. Who acted, the target's identifier, the action, the reason, the timestamp, and a link to the evidence. A ban with no reason cannot be reviewed, so it turns into an argument.
• Send logs off the game server. A Discord webhook channel or a log target on another host. Logs that only exist on the box are unavailable exactly when the box is the problem.
• Log these specifically: bans and unbans, kicks, permission changes, resource start and stop, money and item grants, teleports to a player, and anything that writes to the database.

When staff abuse the access

Assume it will happen at some point, and design so that it is visible and reversible rather than trusting that it will not.

Economy grants are the usual first sign, followed by bans with thin reasons and a pattern of the same names appearing in them. A monthly read of the grant log and the ban reasons catches most of it, and takes minutes.

When something is reported:

1. Remove access first, investigate after. Removing a permission is cheap and reversible. Leaving it in place while you decide is neither.
2. Remove it everywhere. The ace principal, the txAdmin account, the Discord roles, and any shared credential that person knew, which now needs rotating.
3. Reverse what you can. Unban the people who were wrongly banned, and undo economy changes you can identify. If you cannot identify them, that is a logging gap, and fixing it is part of the response.
4. Tell the community something. Silence gets read as tolerance. A short factual statement is enough, and you do not need to publish anybody's personal details to make it.

Never sell a staff position, and never let a store perk grant permissions. That is both a platform rules problem and a straightforward security problem. See Donations and revenue on a FiveM server.

The handover problem

People leave. Most access is never revoked, because it lives in more places than anyone remembers. Keep this list and run it every time someone leaves, regardless of how amicable it was:

• Remove the ace principal, then confirm it is gone after a restart rather than assuming the config edit did it.
• Delete the txAdmin account.
• Remove Discord roles, and rotate any bot token or webhook they held.
• Rotate the shared credentials they knew: database, hosting, rcon_password if set, and any API keys for your store or logging.
• Review the resources they wrote or changed before you keep running them. A departing developer can leave an event handler that grants access back. Redeploying from a known-good copy is faster than reading everything.

The other half of a handover is the knowledge, and it is worse than the access. The things that live in one person's head are which accounts exist, what runs where, and why a config decision was made. Two habits fix it: keep every account, including the store, the payment provider, the domain, and the hosting, in the name of whoever owns the server rather than a staff member's personal account, from the start, and keep a written note of what runs where alongside the config.

Related