How to Link Servers with Shared Chat, Economy & Inventory

The Problem: Every Server Is an Island

When you run a Minecraft network with multiple backend servers, say survival, creative and minigames, each server maintains its own data by default. A player's rank on survival does not exist on creative. Their balance resets when they switch servers. Chat messages stay local. This feels broken to players who expect a unified experience, and it makes administration a headache because you end up managing the same player data in multiple places.

The solution is a shared database backend. Instead of each server storing data in flat files or SQLite databases on local disk, you point every server at the same MySQL (or MariaDB) instance. Plugins that support remote databases will read and write to one central location, so a rank granted on survival instantly applies everywhere.

Setting Up MySQL as the Shared Backend

Most hosting providers offer MySQL or MariaDB as part of their panel. If you are self-hosting, install MariaDB on the same machine or a separate database server.

sudo apt update
sudo apt install mariadb-server
sudo mysql_secure_installation

Create a dedicated database and user for your Minecraft network:

CREATE DATABASE minecraft_network;
CREATE USER 'mcnet'@'%' IDENTIFIED BY 'your_strong_password_here';
GRANT ALL PRIVILEGES ON minecraft_network.* TO 'mcnet'@'%';
FLUSH PRIVILEGES;

The '%' wildcard allows connections from any host, which is necessary if your servers run on different machines. If everything runs on one machine, use 'localhost' instead for tighter security. Make sure port 3306 is open between your servers and the database host.

LuckPerms: Cross-Server Permissions

LuckPerms is the standard permissions plugin for modern networks, and it has first-class MySQL support. On every server in your network, edit plugins/LuckPerms/config.yml:

storage-method: MySQL

data:
  address: 'db.yourhost.com:3306'
  database: 'minecraft_network'
  username: 'mcnet'
  password: 'your_strong_password_here'
  pool-settings:
    maximum-pool-size: 10

Once every server points at the same MySQL database, permissions sync automatically. Grant a player the vip group on survival and they will have it on creative within seconds. LuckPerms also supports per-server and per-world contexts, so you can still assign permissions that only apply on specific servers, a player might have build permission on creative but not on the hub.

Shared Economy with Vault and MySQL

Vault is an API layer, it does not store money itself. The actual storage is handled by the economy plugin behind Vault. For cross-server economy, you need an economy plugin that supports MySQL. Here are the main options:

Plugin	MySQL Support	Notes
CMI Economy	Yes (built into CMI)	Full-featured server management suite with economy module
EssentialsX Economy	No (flat file only)	Does not natively support MySQL, not ideal for networks
MySQLEconomy / CoinsEngine	Yes	Lightweight, purpose-built for cross-server balances
PlayerPoints	Yes	Points-based economy with MySQL backend

If you are currently using EssentialsX for economy on a single server and want to go cross-server, you will need to migrate to a MySQL-backed economy plugin. Export balances, switch plugins, then import. It is a one-time pain that saves ongoing headaches.

Cross-Server Chat with RedisChat or BungeeChat

By default, chat messages only appear on the server where they were sent. Players on survival cannot see messages from players on creative. There are two main approaches to fix this.

BungeeChat (Simple)

BungeeChat runs on your BungeeCord or Velocity proxy and routes chat between all backend servers. Install it on the proxy, not on backend servers. It supports global chat, staff chat, private messages, and ignore lists. Configuration is straightforward, one config file on the proxy controls everything.

RedisChat (Scalable)

For larger networks, RedisChat uses a Redis pub/sub system to broadcast messages. Redis is an in-memory data store that handles message passing with extremely low latency. Install Redis on your database server:

sudo apt install redis-server
sudo systemctl enable redis-server

Then configure RedisChat on each backend server to connect to the same Redis instance. Messages published on one server are instantly received by all others. This approach scales better than BungeeChat because it does not route everything through the proxy, reducing proxy CPU load.

Bans and Punishments: LiteBans

Vanilla bans are per-server. If you ban someone on survival, they can still join creative. LiteBans solves this with a shared MySQL database for all punishments, bans, mutes, kicks, warnings and IP bans.

# LiteBans config.yml (same on every server)
storage:
  method: mysql
  mysql:
    hostname: 'db.yourhost.com'
    port: 3306
    database: 'minecraft_network'
    username: 'mcnet'
    password: 'your_strong_password_here'

When a staff member bans a player on any server, the ban applies network-wide immediately. LiteBans also has a web interface you can set up to browse punishment history from a browser, which is useful for moderation teams.

Player Count Sync with RedisBungee

If you run multiple proxy instances (for load balancing or redundancy), each proxy only knows about players connected to it. RedisBungee uses Redis to share player lists between proxy instances so commands like /glist show the true total and plugins can see all online players regardless of which proxy they connected through.

Even with a single proxy, RedisBungee is useful because it gives backend servers access to the global player count via PlaceholderAPI expansions, which you can display on scoreboards and holograms in your hub server.

Inventories: To Share or Not to Share

This is where things get tricky. Sharing inventories across servers sounds appealing, but it is technically complex and often undesirable. A player's survival inventory should not appear in a minigames server, they would have an unfair advantage or lose items.

When to Keep Inventories Separate

• Different game modes (survival vs. creative vs. minigames) should almost always have separate inventories.
• If servers run different Minecraft versions, item data may not be compatible.

When to Share Inventories

• If you have multiple survival servers with the same rules and items (e.g., survival-1 and survival-2 as overflow instances).
• Hub to server transitions where players should keep cosmetic items.

Plugins like MySQLPlayerDataBridge or Multiverse-Inventories can synchronize inventory data. MySQLPlayerDataBridge stores full player data (inventory, ender chest, health, food, XP) in MySQL and loads it when the player connects to any server. The catch: both servers must run identical item configurations. Custom enchants, modded items or different plugin items will not transfer cleanly.

Connection Pooling and Database Performance

When ten plugins on five servers all query the same MySQL database, you can easily hit connection limits. Every plugin listed above uses connection pools (usually HikariCP) to reuse database connections efficiently. Key settings to tune:

• maximum-pool-size: Set to 10 per plugin per server. If you have 5 servers with 4 MySQL-backed plugins each, that is 200 potential connections. Make sure your MySQL max_connections setting (default 151) can handle this, bump it to 300-500 in /etc/mysql/mariadb.conf.d/50-server.cnf.
• connection-timeout: Leave at default (30 seconds) unless you see timeout errors, in which case your database is overloaded and you need to optimize queries or add resources.
• minimum-idle: Set to 2-3 to keep warm connections ready without wasting resources.

# MariaDB: increase max connections
[mysqld]
max_connections = 500

Monitor your database with SHOW PROCESSLIST; to see active connections in real time. If you consistently see connections near the limit, consider splitting databases, one for permissions, one for economy, one for bans, to distribute load.

Shared Scoreboards and Placeholders

PlaceholderAPI with the PAPI-Proxy-Bridge expansion lets you pull placeholders from other servers. Display survival player count on the hub scoreboard, show a player's economy balance from survival while they are on creative, or list the top economy players network-wide. This ties the visual experience together and makes the network feel like one connected system instead of separate servers bolted together.

Summary: What Goes Where

Data Type	Plugin	Backend	Scope
Permissions	LuckPerms	MySQL	Network-wide with per-server contexts
Economy	CMI / CoinsEngine	MySQL	Network-wide or per-server
Bans	LiteBans	MySQL	Network-wide
Chat	RedisChat / BungeeChat	Redis / Proxy	Network-wide
Player count	RedisBungee	Redis	Network-wide
Inventories	MySQLPlayerDataBridge	MySQL	Selected server groups

Start with LuckPerms and LiteBans on MySQL, those two give you the most immediate quality-of-life improvement. Add cross-server chat next, then economy if needed. Inventory sync should be the last thing you tackle because it is the most fragile and least universally needed.

Need hosting for your network? Astroworld Hosting offers NVMe SSD, Pterodactyl panel, and DDoS protection. See features , plans from €6.39/mo.