Minecraft anticheat guide
Anticheat Config Backups and Version Control
How to keep anticheat config files in git, back up plugin data off the server, keep secrets out of the repository, and test a restore before an incident.
Keep configs in git and backups off the server
Store anticheat configuration files in a private git repository, and keep a separate off-server backup of the full plugin data folder. Commit after each reviewed change, tag the commit that went live, and keep webhook URLs and other secrets out of the repository. Restore a backup to a staging server at least once, so the process is proven before an incident.
Decide what goes where
Commit files that people edit by hand. Back up files that the server writes or that hold data you must keep. Exclude anything that holds a credential, because a repository copy spreads that credential to everyone who can read it.
| Item | Commit to git | Back up off-server | Reason |
|---|---|---|---|
| Anticheat config files | Yes | Yes | Gives a reviewable history of settings |
| Messages and language files | Yes | Yes | Player-facing text changes need review too |
| Webhook URLs and API keys | No | Encrypted backup or secrets manager only | Anyone with repository access could reuse them |
| Plugin jars | No | No, record version and checksum in the change log | Jars are large and easy to re-download from a known source |
| Alert logs and player data | No | Follow your retention policy | Logs can contain personal data |
Set up the repository
Run these commands on the machine that holds the server files, not on a public host. Replace each placeholder with your own path or folder name. The server.properties file can contain an RCON password, so leave it out of the repository.
cd <path-to-server-root>
git init
printf '%s\n' 'logs/' 'cache/' '*.jar' '**/*webhook*' '**/*secret*' > .gitignore
git add .gitignore plugins/<anticheat-folder>/ plugins/<other-plugin-folder>/
git status
git commit -m "Baseline anticheat config before rollout"Commit and tag each reviewed change
Treat a config change like a code change. Make it on a branch, review the diff, then merge and tag the version that went live. This gives you one commit to point to during an appeal and one commit to revert to during an incident.
git checkout -b tune/<check-name>-<yyyy-mm-dd>
git commit -am "Adjust <check-name> after reviewing <n> labeled alerts"
git tag -a live-<yyyy-mm-dd> -m "Config live on <server-name>"Run backups and restore drills
Git history does not protect you from losing the full server folder or a damaged data file. Run the off-server backup on a schedule that matches how often staff change settings. After each backup cycle, restore a copy to staging and confirm the anticheat starts and reads its config.
Worked example: a bad live edit
On Tuesday, an admin edits a threshold on a local copy and uploads the file straight to the server, without a branch. On Thursday, reviewers see alert counts jump and cannot tell which edit caused it, because the change was never committed. The only record is the file's modified time. The team restores the file from the last tagged commit, reloads, and compares the next day's alert counts with the expected pattern. The outage of trust took longer to repair than the config did.
Common mistakes with config backups
These mistakes show up in almost every incident review. Each one is cheap to prevent and expensive to undo.
Know the limits of this setup
Version control shows what changed. It does not show whether the change was correct, and it does not stop someone with server access from editing files outside git. Pair the repository with the permission rules your staff already follow, and compare the live file with the tagged commit after each restart.
FAQ
Should we commit the whole plugins folder?
Usually not. Plugin data folders hold logs, caches, and player data that change constantly. Commit the files you edit by hand and keep the rest in backups.
How do we handle a change someone made directly on the server?
Copy the live file into the repository on a branch, review the diff, and commit it with a note that the change was made directly. Then restrict direct edits so the same thing does not happen again.
How long should we keep old backups?
Keep enough history to cover your appeal window and any incident you may need to reconstruct. Write the number down as part of your retention policy and review it on a fixed schedule.
Does git replace a change log?
No. Commit messages say what changed. A change log also records who approved the change, which alerts prompted it, and what you expected to happen, so keep both.
Can we keep the repository on the game host itself?
You can, but a host failure then takes out both the server and its history. Keep a copy of the repository somewhere else, and store secrets separately, as the table above describes.