On this page
- Map what the proxy connects and what plugins must share
- Protect backend access before inviting players
- Assign responsibility for backend isolation
- Give every plugin an installation location
- Choose shared storage by feature, not by habit
- Make moderation work across server boundaries
- Check staff visibility and player transfers
- Share inventories only between compatible game experiences
- Rehearse failures before opening the network
Key takeaways
6- Restrict direct backend access; Velocity modern forwarding does not replace a firewall.
- Record whether each plugin belongs on the proxy, the backends or both according to its documentation.
- Plan shared storage separately for permissions, punishments and player data.
- Test moderation with ordinary accounts across every relevant destination.
- HuskSync runs on backend servers and requires both a supported database and Redis.
- Rehearse unavailable backends and required-service failures before public launch.
This guide is for owners moving from one Minecraft server to a proxy network with a lobby and separate game servers. You will leave with a plan for backend security, plugin placement, shared data and staff checks before players start switching servers.
Map what the proxy connects and what plugins must share
Velocity accepts player connections and routes them to backend servers listed in its configuration. It provides the connection layer; permission management, punishments and inventory sharing need their own decisions.
If you are still choosing software, our Velocity vs BungeeCord comparison covers that choice. Here, the focus is operating the network after you choose a proxy.
| Layer | What belongs here | Decision before launch |
|---|---|---|
| Proxy | Incoming connections, backend destinations and proxy commands | Which servers players can reach and where they join first |
| Backend servers | The lobby and individual game servers | Which features stay local to each game |
| Plugin storage and messaging | Shared permissions, punishment records or synchronized player data, where supported | Which plugin owns each shared system and what services it requires |
Start by writing down a lobby and one game server, then define what should happen when a player moves between them. Should their rank follow them? Should their inventory change? Should a punishment prevent entry everywhere? Answer these separately.
Before choosing where to host, list the proxy, backends and storage services your chosen plugins require. Ask the host how backend isolation and database access would work for that layout.
Partner Need a server? Use code ARROWTAN for 15% off at iTitan.
Protect backend access before inviting players
The Velocity security documentationSource site warns that publicly accessible backends running in offline mode can allow player impersonation. Treat backend access restrictions as a launch requirement.
Velocity supports modern forwarding, legacy forwarding and BungeeGuard forwarding, with one mode active at a time. Modern forwarding authenticates forwarded player information using a shared secret. The documentation describes legacy forwarding as insecure without proper backend isolation.
When the proxy and backends share a machine, the documentation describes binding backends to 127.0.0.1. Across machines, it describes firewall restrictions and encrypted tunnels. Ask your host which arrangement applies before copying an address from somebody else's setup.
Assign responsibility for backend isolation
Use the operating system firewall to restrict backend connections to the proxy. For a same-machine layout, assess the documented loopback binding approach. For separate machines, follow the security documentation's firewall or encrypted-tunnel guidance, then test whether an outside connection can bypass the proxy.
Ask the host to confirm the addresses your proxy should use and how backend access will be restricted. Use the File Manager for the documented configuration changes, and check the Console during connection tests. Do not assume access to configuration files also gives you control over the host's firewall.
Ask the host which backend addresses to use and who controls their access restrictions. Use Files / FTP for the documented configuration changes and the console to inspect connection failures. Have the host confirm isolation before allowing public joins.
Use our backend access-control guide for the security checklist. If the connection itself is not configured yet, follow our Velocity setup guide rather than improvising forwarding settings.
Give every plugin an installation location
Velocity has its own plugin API. A backend plugin does not become a Velocity plugin because its description mentions network support. Check the supported platform and the installation instructions for each component.
Create a plugin inventory with these fields:
- Location: proxy, selected backends, or both according to its documentation.
- Scope: one game, a group of servers, or the whole network.
- Dependencies: storage, messaging and any required companion components.
- Owner: the staff member responsible for configuration and testing.
LuckPerms supports Velocity and BungeeCord as well as backend platforms. Its network documentation covers shared storage and messaging, making it relevant when planning ranks across multiple servers.
Follow the LuckPerms installation documentation to its network instructions. Do not assume that installing it on the proxy grants permissions to backend commands. Plan permissions for each location where staff or players need them, then verify the result with ordinary test accounts.
Keep a written distinction between network responsibilities and local gameplay responsibilities. For example, decide whether a moderator should be able to move players between servers, issue punishments, inspect a particular game, or perform all three jobs. Those are separate access decisions.
Choose shared storage by feature, not by habit
A database is not what routes a player from the lobby to a game server. Velocity's backend destinations handle routing. Shared storage becomes relevant when a plugin must retain or coordinate information across those servers.
The requirements differ by plugin. LibertyBans supports a local HyperSQL file or remote MariaDB, MySQL and PostgreSQL storage. HuskSync requires both a supported database and Redis. LuckPerms has separate network instructions covering shared storage and messaging.
| Data | Question to answer | Documented example |
|---|---|---|
| Permissions | Which ranks and permissions should apply across the network? | LuckPerms network installation covers shared storage and messaging |
| Punishments | Which punishments should apply across games or proxies? | LibertyBans supports remote databases and multi-proxy operation |
| Player state | Which servers should share inventories and related data? | HuskSync synchronizes player data using a database and Redis |
Do not choose database settings simply because another plugin uses similarly named fields. Follow each project's requirements, record which service it depends on, and include loss of that service in your launch tests.
Make moderation work across server boundaries
LibertyBans provides bans, mutes, warnings, kicks and temporary punishments. It supports Velocity and backend platforms, offers remote database storage, and lists multi-proxy support.
Use those capabilities as a starting point for a moderation plan, then follow its documentation for your deployment. Decide which actions should affect the whole network and which should remain specific to a game. Do not leave that decision to whichever console a moderator happens to use.
- Punishments: test whether a punished account can reconnect or switch to another game.
- Mutes: test chat in each relevant destination rather than checking only the issuing server.
- Staff access: verify ordinary moderators can do their assigned jobs without receiving every administrative permission.
- Staff communication: decide where cross-server reports and coordination should happen, then test the chosen arrangement.
Velocity also separates permissions for its own commands. The server-switching permission is available to everyone by default, while the player-list permission is not. Review those defaults against how you want players and staff to navigate.
Check staff visibility and player transfers
In game, use an authorized staff test account for the commands below. Check the proxy process's console if the transfer fails.
/glist all
/send TestPlayer lobbyUse an authorized staff test account in game for the commands below. Inspect the proxy's Console if the player does not reach the intended destination.
/glist all
/send TestPlayer lobbyRun the commands below in game with an authorized staff test account. Inspect the proxy's console if the result differs from your plan.
/glist all
/send TestPlayer lobbyReplace TestPlayer with your test account and lobby with a configured destination. The relevant permissions are velocity.command.glist and velocity.command.send. Repeat the permission check with an ordinary player account to confirm staff tools are restricted.
Share inventories only between compatible game experiences
HuskSync synchronizes inventories, ender chests, health, hunger, effects, advancements and statistics between proxied servers. It runs on the backend servers rather than on the proxy and requires a supported database plus Redis.
Before adopting synchronization, write down which game servers should share player state. For example, you might want continuity between survival servers while deliberately keeping a minigame inventory separate. Treat that as a design requirement to check against the synchronization plugin's documentation.
Rehearse failures before opening the network
Velocity's configured destination list includes a try order for initial joins and fallback attempts after a player is kicked from a server. Review that order against the destinations you actually intend to provide.
- Join through the public proxy address with a normal account and confirm the starting destination.
- Switch between the lobby and game server, checking permissions and any deliberately shared data.
- Apply a temporary test punishment and check reconnecting and changing destinations.
- Arrange a controlled unavailable-backend test and observe the configured fallback behavior.
- With the relevant plugin documentation at hand, test loss of a required storage or messaging service and record what players and staff see.
- Confirm an outside player cannot connect directly to a protected backend.
Our team recommends recording expected and observed results for each test. Resolve differences before adding more destinations, so every new server follows a network policy you have already checked.
Frequently asked questions
Do I need a database for a Minecraft network?
Choose storage around the features you want to share. Velocity routes players using configured backend destinations, while individual plugins define their storage requirements. LibertyBans offers local or remote database storage, and HuskSync requires a supported database plus Redis.
What plugins go on the proxy instead of the backend?
Install a plugin on Velocity only when it explicitly supports that platform. Velocity has its own plugin API, and backend support alone does not establish proxy compatibility. HuskSync, for example, runs on backend servers rather than the proxy.
How do I sync LuckPerms permissions between servers?
Follow LuckPerms' network installation instructions for shared storage and messaging. It supports both proxy and backend platforms. Verify the resulting permissions on each relevant server and on the proxy instead of assuming one installation covers every command.
How do I ban players across a Minecraft network?
Choose a punishment plugin with documented support for your deployment and define which punishments should apply throughout the network. LibertyBans supports Velocity, remote databases and multi-proxy operation. Test a punishment by reconnecting and attempting to reach each relevant game server.
Does Velocity automatically sync inventories?
Inventory synchronization is a separate plugin feature. HuskSync synchronizes inventories and other player data between backend servers using a supported database and Redis. Decide which games should share that data before configuring it.
