Minecraft anticheat guide
Setting Up an Anticheat on a Brand-New Minecraft Server
Follow this order to set up an anticheat on a new Minecraft server: stage it, install it, give staff alert access, and test in alert-only mode before bans.
In what order should a new server set up an anticheat?
Stage the anticheat on a copy of your server first. Install it with its required dependency, give staff alert access before the first player joins, and run in alert-only mode until your staff has reviewed real alerts. Keep automatic kick and ban off until then. Write down each setting you change, because you will need that record later.
Stage the server before it goes live
A staging copy shows you startup errors, permission gaps, and alert behavior without exposing players to a half-finished setup. Copy the world, the plugins folder, and the configuration files to a separate instance. Use the same server software, Java runtime, and plugin versions you plan to run live. Restrict the staging server to staff accounts.
This guide does not test your stack. Your server software, plugin set, and hosting can change how any anticheat starts and reports, so treat the staging run as the only evidence you trust.
How do you install FairPlay and PacketEvents together?
Per the FairPlay installation docs, PacketEvents is required to run FairPlay, so both plugins go into the server's plugins folder before the first start. Download each from its official source: FairPlay from its BuiltByBit listing and PacketEvents from its release page. The FairPlay installation checklist covers the full install in more detail.
Which staff permissions do you need before launch?
FairPlay alerts reach online staff who hold fairplay.notify. Staff who may be flagged while testing also need fairplay.notify.self. The reload command needs fairplay.command.reload, and the root fairplay.command permission must also be granted. Grant these to named groups rather than individual accounts, so a new admin inherits them cleanly.
| Permission | Give it to | Effect per FairPlay docs |
|---|---|---|
| fairplay.notify | Staff who review alerts | Receive alerts while online |
| fairplay.notify.self | Staff who may be flagged during testing | Receive alerts for their own account |
| fairplay.command | Admins who manage FairPlay | Root permission for FairPlay commands |
| fairplay.command.reload | Admins who edit configuration | Run /fairplay reload |
/lp group staff-alerts permission set fairplay.notify true
/lp group staff-alerts permission set fairplay.notify.self true
/lp group admins permission set fairplay.command true
/lp group admins permission set fairplay.command.reload trueHow do you configure the three policy files?
FairPlay's docs describe three policy files: config.yml, punishments.yml, and mitigations.yml. Change one area at a time, back up the generated file before each edit, and record the change. The table shows what to touch first on a new server.
| File | What it controls per docs | What to decide at setup |
|---|---|---|
| config.yml | Bedrock eligibility, cancel messages, model updates, player logs, alerts, checks, diagnostics | Who can read player logs and which alerts reach staff |
| punishments.yml | Violation expiration (10,000 ms default) and alert cooldown (1,000 ms default) | Keep defaults until you have alert data to justify a change |
| mitigations.yml | Per-check mitigation, reach compensation, separate kick and ban gates | Keep automatic kick and ban disabled at launch, since both default to disabled |
How do you run the alert-only test?
Run the server with automatic kick and ban off. Have a cooperating tester run controlled movements and combat in the staging instance, then check whether the expected alerts reached your staff. Set your own review window. This guide does not give a duration that fits every server.
Log each false alert with its time, player, and check. A false alert is a finding for your tuning notes, not a reason to skip the review.
When should you enable kick or ban?
Enable kick or ban only after staff have reviewed alerts from your own environment and written down the policy. The mitigation docs describe kick and ban as separate gates with separate allowlists, so enable one gate at a time and record it. The tuning article linked below covers threshold work in more detail.
If your server accepts Bedrock players, check the Bedrock eligibility setting in config.yml before you decide how those players are handled.
What have we not verified?
We did not test how any anticheat behaves on your Minecraft version, plugin set, or hardware. We also do not claim detection accuracy or performance numbers for your server. Those answers come from your staging run and your review records.
FAQ
Can we turn on bans on the first day?
You can, but the mitigation docs say automatic kick and ban both default to disabled. Keep them off until staff have reviewed alerts from your own players, then enable one gate at a time.
The install fails with PacketEvents errors. What do we check first?
Confirm PacketEvents loaded before FairPlay started. Then compare your server software, Java, and plugin versions with both projects' release guidance and save the first startup error before changing anything.
Do config changes need a restart?
Use /fairplay reload after backing up the file. Some settings need a restart, so check the startup output and the setting's guide if the change does not take effect.