Velocity vs BungeeCord: Building a Minecraft Server Network

A proxy is an intermediate server that players connect to and that forwards them on to separate backend servers for lobby, survival, creative and minigames, so they can jump between worlds without leaving the game. BungeeCord and Velocity both do that job: BungeeCord is older and widely supported, Velocity is more modern, faster and safer thanks to modern forwarding. The proxy itself barely needs memory — 512 MB is usually plenty and costs EUR 0.50 per month at MC-Node — but every backend server behind it needs RAM of its own.

What does a proxy actually do?

Without a proxy, your client connects straight to a Minecraft server. With a proxy, it connects to the proxy, which then opens its own connection to a backend server behind the scenes. When you switch servers, the proxy drops that rear connection and opens a fresh one to the next server. Your own connection stays up, so all you see is a brief loading screen rather than the server list.

The proxy does not run a world itself: no chunks (the 16x16 block sections a world is stored in), no mobs, no redstone. It holds connections open, shuttles packets around and manages the player list. That is why 512 MB is nearly always enough for a proxy, while the same amount of memory would get a survival server nowhere. There is a bonus, too: the proxy is the only address players know, which makes it the single point where you aim your DDoS protection.

What is the difference between BungeeCord and Velocity?

BungeeCord comes out of the Spigot camp and was the standard for years; almost every older tutorial is written around it. Velocity comes from the team behind Paper and handles two things differently: the way connections are processed, and the way a backend verifies that a player genuinely arrived through the proxy. Waterfall, the BungeeCord fork from that same Paper team, is no longer being developed and points users towards Velocity itself.

Plugins are not interchangeable: a BungeeCord plugin will not run on Velocity, because the API is different. The things you actually want on a proxy, such as LuckPerms and ViaVersion, do have Velocity builds. If you are starting now, Velocity is the obvious choice. If you have been running BungeeCord for years with plugins that have no Velocity version, staying put is fine — provided your security is in order.

How much RAM does a network need?

Budget per backend, not for the network as a whole. Every backend is a complete Minecraft server with its own world, its own plugins and its own Java process. Four servers therefore means reserving memory four times over; the proxy is the cheapest link in the chain.

Mind the trap here: 8.5 GB split across four servers is not the same as a single server with 8.5 GB. Each Java process carries its own overhead and loads its own chunks, so you lose memory purely to the fact that there are four of them. Only build a network once you genuinely need the separate worlds. For setting up a single server, see our walkthrough on making a Minecraft server.

How do you set up a Velocity proxy?

Proxy first, then the backends, then testing. On a panel such as Pterodactyl you create the proxy as a separate package with its own port.

1. Put Velocity on a 512 MB package and start it once so that velocity.toml and forwarding.secret are generated.
2. In velocity.toml, set online-mode = true and player-info-forwarding-mode = "modern".
3. Under [servers], fill in the internal addresses and ports of your backends, plus a try list that decides where players land on connect — usually the lobby.
4. On every backend, set online-mode=false in server.properties (the main settings file); the proxy handles authentication now.
5. On every Paper or Purpur backend, open config/paper-global.yml, set enabled: true under proxies.velocity and paste forwarding.secret into the secret field.
6. Restart everything, connect to the proxy address and use /server to hop between your backends.

BungeeCord works differently: there you set ip_forward: true in config.yml and bungeecord: true in spigot.yml on every backend. That combination has no verification built in whatsoever, which is exactly why you need BungeeGuard alongside it.

Why can anyone just walk into your backend servers?

In a network, only the proxy checks whether someone really is who they claim to be. That is why the backends set online-mode to false: all they should ever see is traffic the proxy has already vetted. That is perfectly fine, right up until a backend port is also reachable from the internet.

At that point anyone can drop that port into their server list, pick any username they fancy and walk straight in. There is no verification left, so the name of your owner account with OP rights is wide open too. A whitelist does not help: the server believes whatever name the client supplies, so an attacker simply types in a name from the whitelist. This is by far the most common reason small networks get griefed.

How to close the hole

• Use modern forwarding. Velocity signs the player data with the secret from forwarding.secret; a backend that knows that secret rejects anything that is not correctly signed.
• On BungeeCord: install BungeeGuard. Legacy IP forwarding blindly trusts whatever arrives. BungeeGuard adds a shared token and covers the same gap.
• Restrict the network traffic. Have the backends listen on an internal address only, or use the firewall to allow nothing but the proxy IP. If you are not sure how that works on your panel, ask support.
• Test it yourself. Type a backend's address and port directly into your client. If you get in, the hole is still open; if you get an error about forwarding, you are fine.

Repeat that last test every time you add a backend: a new server starts out with default settings, and therefore without forwarding.

What changes for your plugins?

A network shares nothing automatically. Every backend keeps its own world folder and its own player data, so someone with a full inventory on survival arrives empty-handed on creative unless a plugin stores that data in a shared database. Ranks are simpler: point LuckPerms on every server at the same MySQL database and a rank applies everywhere. Run LuckPerms on the proxy as well, because proxy commands have permissions of their own.

Plugins tied to the world, such as WorldGuard, WorldEdit, CoreProtect and GriefPrevention, stay on each backend. ViaVersion and ViaBackwards move to the proxy instead, so mismatched client versions are handled at the front door; the same goes for Geyser with Floodgate for Bedrock players. Chat is what people forget most often: players in the lobby see nothing of survival chat by default, and DiscordSRV runs per server. Which plugins belong where is covered in our overview of genuinely useful Minecraft plugins.

When do you not need a proxy at all?

More often than you would think. If all you want is a creative world alongside your survival world, a single server with a world management plugin handles that. It saves you a proxy, an extra package and one more thing that can break. With a small, settled group of players, the money you save is better spent on RAM for your main server.

Modpacks are the second case. Proxies and modloaders are an awkward pairing, and heavy packs are expensive to duplicate: All the Mods 10 asks for at least 10 GB and 12 GB for a small group, so every extra backend immediately doubles that requirement. A single, well-tuned server is the smarter move — which is what our article on server optimisation is all about.

Bear in mind, too, that a proxy is a central point of failure: if it goes down, your entire network is unreachable even though the backends are still running. So do not start on one until you have a single server running smoothly. You can see what the individual pieces cost at Minecraft hosting from MC-Node, including the 512 MB proxy at EUR 0.50.

Frequently asked questions

Can I run my BungeeCord plugins on Velocity? No, Velocity has its own API and will not load BungeeCord plugins. The well-known names do have Velocity builds, including LuckPerms, ViaVersion and Geyser with Floodgate. Go through your list before you switch: it is the small, home-made plugins that most often have no Velocity version.

How much RAM does the proxy itself need? 512 MB is enough for most networks, EUR 0.50 per month at MC-Node, because a proxy does not tick a world or load chunks. If your network grows quickly you will hit CPU and network limits long before memory ones. Your RAM belongs on the backends.

Does online-mode have to be false on my backend servers? Yes, because the proxy has already verified the player with Mojang and a second check on the backend will fail. Set online-mode to true on the proxy and false on the backends, and make sure those backends are only reachable through the proxy using modern forwarding or BungeeGuard. Without that last step, anyone can walk in under any name they like.

Does a network share inventories and ranks automatically? No. Every backend keeps its own world and player data, so inventories and ender chests are entirely separate. You share ranks by pointing LuckPerms on all servers and on the proxy at the same MySQL database; for inventories you need a dedicated plugin with shared storage.

Can I put a modpack like All the Mods 10 behind a proxy? Technically it is sometimes possible, but it is usually not worth the effort. ATM10 runs on NeoForge with Minecraft 1.21.1 and asks for at least 10 GB and 12 GB for a small group, so every extra backend hurts. A single good server is the better choice.

Further reading

• Geyser and Floodgate: Bedrock Players on Your Java Server
• Paper, Spigot, Purpur or vanilla: which server software?
• Datapacks vs Mods vs Plugins: What Is the Difference?