Quick start
Tosun AntiCheat — Documentation
Everything you need to protect your FiveM server from cheats. The roadmap below shows where to start based on your situation.
Quick start — working in 15 minutes
If you're starting from scratch, follow this order:
| # | Step | Time | Guide |
|---|---|---|---|
| 1 | Prepare a database Already running QBCore/ESX? Your existing database is enough | ~5 min | Database (MySQL) → |
| 2 | Open your panel account Your license key is generated here | ~2 min | Panel & Site Setup → |
| 3 | Install the anti-cheat Download, extract, add 3 lines to server.cfg | ~5 min | Installation → |
| 4 | Apply platform hardening The highest-value step — blocks most cheats in one go | ~3 min | Installation § 7 → |
What do you need?
| Your situation | Go to |
|---|---|
| New install, starting from scratch | Installation guide — step by step, with the reason for each step |
| No database / can't connect | Database guide — three options, connection strings, troubleshooting |
| Want to self-host the panel | Panel setup — Nginx, SSL, cron, security rules |
| QBCore / ESX compatibility | Framework — detected automatically |
| Getting false bans | Settings & performance — confirmation windows, exemptions |
| Integrating with your own scripts | Exports — exemption, ban and whitelist API |
| Where's my license key? | License key |
| Something's wrong | FAQ · Panel → Support |
How the system works
Three components work together:
| Component | Runs on | Job |
|---|---|---|
tosun-ac | Your FiveM server | Detection, punishment, protection. The anti-cheat itself. |
tosun-ac-guardian | Your FiveM server | Restores the anti-cheat within a second if it's stopped. |
| Panel | Web | Bans, detections, live monitoring, settings. |
The panel and server talk both ways, automatically: detections land in the panel instantly, and setting changes reach the server in ~30 seconds. You do not need to restart the server to change settings.
Our protection approach
1. Platform layer (cannot be bypassed). FiveM's own routing convars —
sv_entityLockdown, sv_stateBagStrictMode, sv_filterRequestControl. With these on, the server simply never relays the malicious packet; what runs on the client is irrelevant.
2. Server-authoritative layer. Weapon grants, explosions and damage flow through the server as net events and are checked against server-side reality. An executor cannot skip this layer — it can only try to fabricate the contents, which is exactly what gets caught.
3. Client layer. Native integrity, OCR, menu signatures. A fast, cheap first filter — designed on the assumption that it will eventually be burned.
An honest note: no anti-cheat can promise "cheats absolutely cannot get in" — client-side detection has a hard physical limit against kernel-level cheats. That's why we put the weight on the server and platform layers, which cheats cannot bypass. Applying platform hardening is the single most effective thing you can do.
False-ban policy
We avoid both mistakes:
- Banning an innocent player. Physics-based detections (speed, teleport, noclip) require multiple consecutive readings and a minimum duration, and are skipped entirely during lag or desync.
- Letting a cheater slip. A cheater cannot deliberately induce lag to keep resetting the confirmation window — if total violations cross a threshold over a longer window, the punishment still lands.
Detections with a higher false-positive risk also use temporary bans (noclip is 7 days, for example), while definitive detections — menu signatures, dump attempts — remain permanent. All configurable: Settings & performance.