txAdmin Guide: Permissions, Restarts and Recovery

Use txAdmin to manage an existing FiveM server through individual admin permissions, deliberate restart procedures and protected profile data. Give moderators the actions they need rather than shared owner credentials. Treat the web console and configuration editor as privileged access, and back up the application database separately from txAdmin’s own state.

Design permissions around responsibilities

Review the permissions supported by your installed release
Responsibility	Example permission to evaluate	Risk to consider
Read console output	console.view	Logs can contain sensitive operational information.
Issue console commands	console.write	Arbitrary commands can change service state.
Restart the server	control.server	A mistaken action interrupts players.
Edit server configuration	server.cfg.editor	Changes can expose secrets or alter the entire deployment.
Manage administrators	manage.admins	This can expand another person’s authority.

The current permission documentation distinguishes these capabilities. Review it after significant upgrades instead of assuming a role created long ago still matches its purpose. Avoid granting all_permissions for convenience, and remove access when a role ends.

Protect the administration path

Restrict the web interface to trusted administration access where your hosting setup permits it. Use individual identities and strong credentials. Account linking does not make a publicly exposed management service immune to credential theft or configuration errors. Keep a separate recovery route if your normal administrator account becomes unavailable.

Make planned restarts predictable

Identify which process manager owns the server lifecycle. Avoid two supervisors fighting to restart the same instance.
Announce the maintenance window and identify operations that should finish before shutdown.
Create an appropriate recovery point before updates, not merely before every routine restart.
Stop cleanly, verify the process exited, apply the intended change and start using the normal supervisor.
Check the console, a player join and persistent data after startup before announcing completion.

Scheduled restarts can be operationally useful, but repeated memory growth or crashes still need diagnosis. Keep timestamps and the first relevant error. A successful automatic restart does not explain why the previous process failed.

Know what txData contains and what it does not

Record the actual profile and txData paths for your deployment; they can differ between environments. Back up the required profile configuration and administrative state with restricted access. A backup of txAdmin’s player information is not evidence that a framework’s SQL inventory, economy or character data has been captured.

When the server keeps restarting

Preserve evidence before changing the schedule
Observation	Investigation
Immediate start/exit loop	Artifact/runtime compatibility, startup path and earliest console error
Failure during a resource start	Dependency order and the last deployed resource version
Failure at a predictable time	Restart schedule, backup jobs and external automation
Process killed with no application traceback	Host/container limit and platform event logs

Pause conflicting automation during a maintenance investigation and keep the last working configuration. Do not repeatedly restore an old database while players can still write to it. Reopen only after confirming which instance and data store are authoritative.

For initial installation, use txAdmin setup. For recovery, use the FiveM file/database backup guide. Check the administration access available with FiveM hosting before designing team roles around it.