Global ban lists across game servers

A global ban system is a single ban list that several servers read from, usually a database plus a plugin on each server and often a web panel for staff. For your own network of servers it is close to essential once you run more than two: one ban applies everywhere, one unban lifts it everywhere, and the record lives in one place. Sharing bans with other communities is a different decision with real risks - you import their mistakes and their grudges along with their cheaters - and it only works with agreed evidence standards, a scope limited to cheating, and a way to appeal.

This post covers both: the tools for each game family, how the shared database is wired up, what goes wrong, and the rules that make cross-community sharing workable. The single-server mechanics of banning and evidence are in handling cheaters and ban lists.

Two different problems with the same name#

"Global bans" is used for two quite different setups, and it helps to keep them apart.

The first is an operational convenience with few downsides. The second is a policy decision, and the technology is the easy part.

There is also a third kind you do not control at all: the anti-cheat vendor's and developer's global bans, which apply to every server running a game. Those are covered in BattlEye and Easy Anti-Cheat on servers.

How a shared ban system works#

Every shared ban system has the same shape. Each game server runs a plugin that checks connecting players against a central store, and writes new bans into that store. Staff manage bans through in-game commands, a web panel, or both.

Three properties matter when choosing one:

• What happens when the database is unreachable. A good plugin caches bans locally and keeps enforcing them; a weak one lets everybody in until the database comes back.
• Whether bans are checked on join only, or pushed to servers live. Live push means a player banned on one server is removed from another immediately rather than on their next join.
• What identifiers it stores. Account IDs at minimum; IP addresses for alt detection; history so that lifted bans are still visible.

Network-wide or per server

Not every ban should follow a player everywhere. A player who keeps breaking the building rules on your creative server may be perfectly welcome on the PvP one, and a ban for spawn-camping on a deathmatch server says nothing about how they behave in a co-operative campaign. Several of the tools below can limit a ban to one server or a group of servers rather than the whole network; where they cannot, keep a separate local ban list for rules that only make sense on one server.

A sensible split for most networks:

• Network-wide: cheating, ban evasion, threats, doxxing, hate speech, anything that would get someone removed from your community Discord too.
• Per server: rules tied to a game mode, a map or a server's culture.

Write the split down for staff. Without it, the default becomes "ban everywhere", and a minor rule break on one server locks a regular out of everything you run.

Source games: SourceBans++#

On Source games running SourceMod - Team Fortress 2, Garry's Mod, Left 4 Dead 2, Counter-Strike: Source and others - SourceBans++ is the standard. It is a maintained continuation of the original SourceBans and has three parts: a PHP web panel, a database, and a set of SourceMod plugins. The main plugin handles bans; companion plugins handle communication blocks (gags and mutes) and admin synchronisation, and there is an optional one that flags connecting players whose IP matches a banned account.

Each game server connects to the database through SourceMod's databases.cfg:

"Databases"{	"driver_default"	"mysql"	"sourcebans"	{		"driver"	"default"		"host"		"db-host-from-your-panel"		"database"	"sourcebans"		"user"		"generated-user"		"pass"		"generated-password"		"port"		"3306"	}}

Each server also needs its own server ID, set in the plugin's config file under configs/sourcebans/, matching the server you added in the web panel. With that done, sm_ban on any server writes to the shared database, and the ban applies on every server.

SourceBans++ expects a MySQL-compatible database for its web panel and plugins, so check that requirement against the database you have before you start.

SourceMod also has its own database-backed admin system, which is the simpler option if what you want to share is admins rather than bans: the admin-sql-threaded plugin reads admins and groups from a database defined as "admins" in databases.cfg, so promoting or removing a staff member is one change for the whole network. SourceMod admin flags and immunity covers the permission model those admins use.

Minecraft: one ban plugin, one database#

A Minecraft network usually has a proxy (Velocity or BungeeCord) in front of several backend servers. Ban plugins handle this in one of two ways: installed on the proxy, where a ban stops the player before they reach any backend; or installed on every backend with a shared database. Proxy installation is simpler and harder to bypass, as long as backends cannot be reached directly.

Each one documents which database engines it supports; read that before you create the database, because not every plugin supports every engine. All three provide temporary bans with durations, mutes, warnings, reasons and a history, which is the main reason to move off vanilla banned-players.json even on a single server. Most can import from vanilla files and from each other, so start with the vanilla list and migrate.

Run the ban plugin where joins happen. On a network that is the proxy, plus a database the backends can also read if a backend plugin needs ban information. Minecraft Velocity proxy network covers the network layout and MySQL for Minecraft plugins covers connecting plugins to a database.

Rust, DayZ, Arma and other RCON-managed games#

Many survival and military games are administered through RCON rather than an in-game plugin framework, and here the common shared-ban tool is BattleMetrics. Its RCON service connects to your servers, records players and their identifiers, and keeps bans in ban lists that you apply to one or more of your servers. An organisation can share a ban list with another organisation, or subscribe to one, which is how many Rust and DayZ communities exchange bans. Bans on a list are enforced by the service through RCON when a matching player joins.

The trade-off is that your ban data and your RCON access sit with a third-party service. That is a reasonable trade for many communities, but it means the RCON password is held by that service, and anyone in your organisation with the right permissions there can act on your servers. Treat its accounts the same way you treat the panel: two-factor, least privilege, and offboarding when someone leaves. RCON safely covers the RCON side.

On Rust, plugin frameworks also offer database-backed ban plugins if you would rather keep the data yourself. On games with BattlEye, the local bans.txt is per server, so sharing means a tool that writes the same bans to each.

Some games have a URL-based list built in. Palworld's settings include a BanListURL, a list the server fetches over HTTP; the default points at the developer's list. Check what your version's default is before changing it, and understand that pointing it at your own file replaces whatever the default provided.

Sharing with other communities#

Exchanging bans with other server owners sounds like obvious collective defence. In practice it fails in predictable ways, and the communities that do it successfully agree the rules first.

The failure modes:

• One bad admin poisons every list. A moderator in another community bans their ex-friend for "cheating"; the ban arrives on your servers with the same weight as a real one.
• Different standards of evidence. Your community bans on recorded demos; theirs bans on reports in chat.
• Scope creep. Bans for toxicity, rule breaks specific to one server, or "drama" leak into a list meant for cheaters.
• No appeal path. A wrongly banned player is locked out of a dozen servers and has no one to ask.
• Retaliation. A dispute between communities turns into mass bans of each other's players.

The rules that make it work:

1. Share cheating bans only. Rule-breaking that depends on a server's own rules stays local.
2. Require evidence with every shared ban, stored where the other parties can review it: a demo, a recording, a log extract.
3. Agree an appeal route, normally to the community that issued the ban, with a commitment to lift bans that cannot be supported.
4. Subscribe read-only where you can, and review imported bans before they are enforced if the tool allows it.
5. Keep the ability to override. You should be able to unban a player on your servers regardless of a shared list.
6. Keep the group small. Three communities whose owners know each other share bans well. Thirty strangers do not.

Then run it like a shared resource rather than a fire-and-forget feed. Name one contact per community for disputes. Look at the imported bans now and then: how many there are, which community issued them, and whether the reasons still meet the agreed standard. If one partner's bans start to look careless - many bans, thin evidence, appeals they never answer - stop importing theirs before it becomes your problem, and tell them why. Leaving an agreement should be as easy as joining it, and the agreement should say what happens to bans already imported when a community leaves: usually they stay, and are lifted individually on appeal.

Privacy and the legal side#

A ban list is personal data: account IDs, often IP addresses, the time, and an accusation. Sharing it with other people is a further use of that data. For a group of friends this barely matters; for a community of any size, and especially one in or serving the EU, it does.

The practical minimum:

• Share the least you need. An account ID and a category ("cheating, confirmed by demo") is usually enough. Chat logs, real names and IP addresses rarely need to leave your servers.
• Say in your server rules or privacy notice that bans for cheating may be shared with partner communities.
• Expire what no longer matters. Old temporary bans and lifted bans do not need to be shared indefinitely.
• Be accurate. Publishing someone as a cheater when they were not is a different kind of problem from an incorrect local ban.

Game server privacy and player data covers the basics in more depth.

Hosting the database#

The ban database needs to be reachable from every server that checks it, reliable, and backed up. A few options:

• The database slot on a game plan. Every RE:NODE game plan includes one database slot, created in the panel with a generated host, user and password, and an "Open in phpMyAdmin" button for quick inspection. For a small network that is often all you need, provided the plugin supports the engine.
• A dedicated database server. The RE:NODE database lines are PostgreSQL and MongoDB, which suits ban plugins that support PostgreSQL. PostgreSQL remote connections covers connecting to one from a game server.
• A third-party service, such as BattleMetrics, which holds the data for you.

Whichever you choose, back it up separately from the game servers. A network that loses its ban database loses years of moderation in one go, and the people who were banned are the first to notice. Database backups and restores covers the routine, and the same advice applies: a backup nobody has restored is a hypothesis.

FAQ#

Do I need a global ban system for two servers?

Not strictly. Two servers can share bans by hand, or by copying ban files. Once you have three or more, or more than a couple of staff, a shared database saves time and prevents the mistake of a player banned on one server playing happily on another.

Can I subscribe to a big public cheater list?

On some platforms, yes, through services like BattleMetrics. Read the list's policy first: what it bans for, what evidence it requires, and how appeals work. You are responsible for who you keep off your servers, even when someone else made the decision.

What if the ban database goes down?

It depends on the plugin. Good ones keep a local cache and continue to enforce known bans. Check this before you rely on it, and monitor the database the same way you monitor the game servers.

Should shared bans include IP addresses?

Usually not. IP addresses change and are shared by households and carriers, so they cause false matches on other communities' servers. Share account IDs and keep IP-based alt detection local.

How do I handle an appeal for a ban another community issued?

Point the player to the community that issued it, and if that community will not support the ban with evidence, lift it on your own servers. Your agreement with partners should make this normal rather than a dispute.