FiveM Admin Guide (2026): Safe, Correct, and Fast Setup

TL;DR (Quick Start)

• Get permission first. Only the server owner may grant admin.
• Use correct identifiers. Prefer Rockstar license (identifier.license:...). SteamID64 is legacy.
• Bootstrap via ACE (server.cfg) or framework tools, then refine in‑game.
• QBCore: Add qbcore.god/qbcore.admin via server.cfg (ACE).
• ESX: Use /setgroup [id] admin (highest by default) or set users.group = 'admin' in DB.
• vRP: Give yourself the admin/superadmin group via in‑game admin menu or the vrp_user_groups table (vRP 1.x).
• Restart and verify. Test an admin‑only command, check logs.

Need tools? See Admin Tools & More for recommended admin menus and utilities (e.g., vMenu, logging, moderation helpers).

---

Prerequisites

• Owner approval (non‑negotiable). Unauthorized elevation → ban/remove.
• Access to server.cfg (or txAdmin CFG editor) and the database.
• Your identifiers: ideally the Rockstar license; optionally fivem, discord, or steam. Easiest: txAdmin → Players → select yourself → copy identifiers.
• Tools: a plain‑text editor (VS Code/Notepad++) and DB client (phpMyAdmin/MySQL Workbench).

---

Understanding ACE & Identifiers (Works with Any Framework)

ACE (Access Control Entries) is FiveM’s built‑in permission system. You grant permissions to principals (players or groups). Typical identifiers:

• identifier.license:xxxxxxxx (Rockstar license) ← recommended
• identifier.fivem:xxxxx (FiveM)
• identifier.discord:xxxxxxxxxxxxxxx (Discord)
• identifier.steam:1100001xxxxxxxx (Steam/HEX) ← legacy

Minimal safe pattern in server.cfg:

## Permissions
add_ace group.admin command allow                 # allow all commands for admin group
add_ace resource.qb-core command allow            # allow framework to run commands (QBCore example)

# Inheritance (QBCore example)
add_ace qbcore.god command allow
add_principal qbcore.god group.admin               # gods inherit admin
add_principal qbcore.god qbcore.admin
add_principal qbcore.admin qbcore.mod

# Players (replace with your license)
add_principal identifier.license:YOUR_LICENSE qbcore.god   # you

After saving, restart the server. You should now access your admin menu/commands. Once bootstrapped, use in‑game tools to manage staff.

---

Framework‑Specific Setup

QBCore: Grant Admin via ACE (Recommended)

1. Open server.cfg (or txAdmin → CFG Editor).
2. Ensure the permissions block exists (see above).
3. Add your principal: add_principal identifier.license:YOUR_LICENSE qbcore.god # or qbcore.admin
4. Restart the server.
5. Verify in‑game: /admin → Player Management → Permissions.
6. (Optional) Use the command: /addpermission [id] god

Notes

• Prefer license: over steam:; it’s more consistent in 2026.
• Keep day‑to‑day role at admin; reserve god for founders/tech.
• If permissions don’t “stick”, you likely edited the wrong CFG or placed entries above an auto‑generated txAdmin block. Put your lines at the end of server.cfg.

---

ESX: Set Group via Command or Database

Highest default group in modern ESX is admin.

Method A — In‑game (recommended):

1. Find your ServerID (e.g., via scoreboard or /id).
2. Run command in console or as an admin with RCON: /setgroup [ServerID] admin
3. Re‑log once to refresh.

Method B — Database:

1. Open your database → table users.
2. Find your row by identifier.
3. Set column group to admin.
4. Restart your server.

Common pitfalls

• Using superadmin on recent ESX builds: not valid; use admin.
• Wrong identifier (Steam vs license). Use the same identifier ESX stores.

---

vRP (1.x/“Dunko” style) : Add Yourself to a Group

vRP uses its own groups (defined in vrp/cfg/groups.lua), stored per user.

Method A — In‑game menu:

1. Open vRP admin menu.
2. Choose Admin → @Add_Group.
3. Enter your vRP user_id (not your temporary server ID).
4. Enter group name, e.g., admin (or superadmin if your config defines it).
5. Confirm, then re‑log.

Method B — Database (vRP 1.x):

1. In the DB, open vrp_user_groups.
2. Insert: user_id = YOUR_VRP_ID, group = 'admin' (or 'superadmin' if your server uses it).
3. Restart the server.

Group names are server‑specific. Check vrp/cfg/groups.lua for the exact roles and permissions in your pack.

---

Operational Responsibilities (What “Good Admin” Looks Like)

• Rule enforcement: Apply rules consistently. Document warnings/kicks/bans.
• Player support: Resolve reports quickly; educate, don’t escalate.
• Uptime & performance: Watch console, resource times, and logs; report anomalies.
• Auditability: Log all admin actions (Discord webhooks/txAdmin). Use unique staff accounts.
• Least privilege: Use admin day‑to‑day; reserve god/superadmin for break‑glass scenarios.

See Admin Tools & More for vetted admin menus, logging, and moderation resources.

---

Security & Compliance Checklist

• Written owner approval for each admin.
• Use license: identifiers; avoid Steam‑only setups.
• Keep cfg permissions in version control.
• Enable Discord/txAdmin logging for staff actions.
• No shared staff accounts.
• Rotate RCON/txAdmin passwords.
• Test staff access on a staging slot before live.

---

Troubleshooting

Symptom	Likely Cause	Precise Fix
No admin after restart	Edited wrong CFG or lines overridden by txAdmin	Put add_principal at end of server.cfg. Restart twice.
Admin menu opens but no powers	Wrong group (mod vs admin/god) or wrong identifier type	Use license: and match your framework’s group names.
ESX group change ignored	Using deprecated superadmin	Set admin via /setgroup or DB; re‑log.
QBCore perms reset on reboot	Used only /addpermission without ACE	Add persistent add_principal lines to server.cfg.
vRP group not applied	Inserted wrong user_id (used temp ID)	Use vRP user_id from DB, not server temp ID.

---

FAQs

Do I still need SteamID64?
No. Use your Rockstar license for modern setups. Steam may still work if your server tracks it, but it’s legacy.

What’s the difference between admin and god on QBCore?
god is the highest and often inherits all others. Use sparingly.

Can I grant admin without a restart?
Yes if you use in‑game commands/menus. For ACE changes, restart is safest.

Is /setgroup safe to use in ESX?
Yes for modern ESX, but ensure the target group exists (admin). Persisting via DB ensures it survives edge cases.

---

Recommended Tools & Next Steps

• Install a modern admin menu with Discord logging, spectate, teleport, and moderation tools.
• Enable txAdmin player monitoring & bans sync.
• Set up Discord webhooks for admin actions (joins, bans, kicks).
• Maintain a staff handbook: escalation ladder, ban durations, appeal process.

Explore our curated list: Admin Tools & More – includes vMenu and other vetted resources.

---

Outbound Resources (further reading)

• QBCore permissions guide (ACE, groups, examples).
• ESX command reference for /setgroup and admin workflows.
• ACE permissions primer (principals & inheritance) for safer configs.

---

Copy‑Paste Snippets

QBCore – Minimal, safe permissions block

## Permissions ##
add_ace group.admin command allow
add_ace resource.qb-core command allow

# Inheritance
add_ace qbcore.god command allow
add_principal qbcore.god group.admin
add_principal qbcore.god qbcore.admin
add_principal qbcore.admin qbcore.mod

# Players
add_principal identifier.license:REPLACE_ME qbcore.god  # Your main account

ESX – Set admin via DB

UPDATE `users`
SET `group` = 'admin'
WHERE `identifier` = 'license:REPLACE_ME';

vRP – Insert admin group (vRP 1.x)

INSERT INTO `vrp_user_groups` (`user_id`, `group`) VALUES (YOUR_VRP_ID, 'admin');

---

Change Log (what’s improved vs. typical guides)

• Replaced legacy Steam‑only approach with license: best practice.
• Corrected QBCore section to use ACE + persistent server.cfg entries.
• Clarified ESX highest role (admin) and provided safe DB & command paths.
• Added vRP in‑game/DB dual methods and group config pointer.
• Included security checklist, FAQ, and ready‑to‑paste snippets.

---

If you need implementation help, paste your server.cfg permissions block and I’ll spot‑fix it.