Minecraft anticheat guide
Where to Install an Anticheat on Velocity or BungeeCord
Install combat anticheats on each backend that runs gameplay, not just the proxy. Covers placement, per-backend installs, shared config, and staff access.
Should the anticheat go on the proxy or the backends?
On a Velocity or BungeeCord network, gameplay and combat happen on backend servers, so combat anticheats usually belong there. The proxy forwards connections and sees less of each player's actions. Install the anticheat on every backend where players fight or build. Check each vendor's documentation before adding it to the proxy.
Each backend runs its own server software. The anticheat, any dependency it requires, and its configuration live in that backend's plugins folder. A proxy install is a separate artifact and does not replace a backend install.
How do the proxy and backend roles differ?
Use this table to decide where each piece belongs. Confirm each row against the vendor's listing before you install anything.
Write the decision down per backend, including the reason. A later change to the network, such as adding a Folia backend or moving a game mode, is easier to review when each placement has a recorded reason.
| Location | Typical role | Check before installing |
|---|---|---|
| Backend (Paper, Folia) | Gameplay, combat, block placement, inventory | Supported server platforms and dependencies in the anticheat's docs |
| Proxy (Velocity, BungeeCord) | Routes connections and network commands | Whether the anticheat publishes a proxy build. The FairPlay docs reviewed for this article describe server plugin installs only |
| Lobby backend | Menus and hubs, usually no combat | Whether players can fight or build there. Install only where they can |
How do I install the anticheat on each backend?
Repeat the same install on every backend that runs combat or building. Use one anticheat version everywhere so alerts from different backends stay comparable.
If backends run different server builds, check each anticheat release's support list for each build. Do not assume that a release tested on one backend applies to the others.
How do I keep configuration consistent across backends?
Each backend reads its own config file, so a change on one backend does not reach the others. There are two common patterns. You can copy one config to every backend and track differences by hand. Or you can keep one template and sync it through your deploy tool. Either way, record every intentional difference between backends.
Keep the layout explicit so you can see what each backend loads.
velocity/
plugins/ proxy plugins only, no combat anticheat unless the vendor supports it
backend-pvp-1/
plugins/
<anticheat>.jar
<packetevents>.jar
config.yml
backend-pvp-2/
plugins/
<anticheat>.jar
<packetevents>.jar
config.ymlHow do staff tell which backend raised an alert?
Staff need to know which backend raised an alert before they act on it. Include the server name in your alert routing or log naming, and confirm that the alert text identifies the backend.
Limit commands per staff role. FairPlay's permission reference lists fairplay.command as the gate for its commands, with child grants for each function. Assign only the grants a role needs.
What if I run more than one anticheat?
Test the full path your players take. Move a test account between two backends and confirm that its alerts, permissions, and any stored state behave the way your staff expect, because a transfer changes which backend handles the player.
Running two anticheats on one backend can duplicate alerts or cause conflicts. Review the stacking guidance before you install a second one, and test the combined setup on staging.
Do not run a second anticheat on the proxy just to cover backends. Proxy-level plugins are a separate decision with their own vendor requirements, and mixing placements makes it harder to tell which layer raised an alert.
How should I roll out a new backend?
Add a new backend to staging first, with the same plugins, config template, and permissions as the production backends it will join. Then connect it to a staging proxy and move a test account through the same routes players use.
Only after that should you add the backend to production. Keep the previous proxy and backend configuration so that a bad backend can be removed from routing without rebuilding the network.
What have we not verified?
We have not tested any proxy version with any anticheat, and this article makes no claim that a given anticheat works on a proxy. Performance and transfer behavior depend on your network, so test a player moving between backends on staging before you rely on it.
FAQ
Can I install the anticheat on Velocity only?
Check the vendor docs first. Combat checks depend on backend gameplay, so a proxy-only install may not see the actions those checks need.
Do lobby backends need the anticheat?
Only if players can fight or build there. Install where gameplay happens, and leave menu-only backends alone.
Does one config file cover all of my backends?
No. Each backend reads its own plugins folder. Sync the file through your deploy process, and record every intentional difference.
Does a player's alert history follow them between backends?
This article does not establish that. Check whether your anticheat stores data per server, and test a transfer between two backends in staging.