BungeeCord vs Velocity: a real comparison, and how to move

BungeeCord vs Velocity comes down to one question: are you starting fresh, or do you have a working BungeeCord network with plugins that only exist for BungeeCord? Starting fresh, Velocity is the answer, and it is not close. Its forwarding is secure without a bolt-on, it is the proxy PaperMC actively develops, and the plugin ecosystem has moved with it. An existing BungeeCord network is a different case: it still gets updates, and migrating costs an evening of work and some risk, so it is worth doing only if you get something for it.

Waterfall is the third name people search for, and the answer there is simple. PaperMC announced Waterfall's end of life on March 26, 2024, said not to count on updates for new Minecraft versions, and pointed everyone to Velocity. Treat a Waterfall network as a BungeeCord network that needs to move sooner.

What our list shows

Servers advertise their proxy in the version string our pinger reads. Among the roughly 2,500 online servers on our list at the time of writing: Velocity 983, Velocity-CTD (a community fork) 147, BungeeCord 77, Waterfall 23. Paper without a proxy accounts for 373 and Purpur for 84. So roughly one in two online servers we track sits behind Velocity or a fork of it, and BungeeCord plus Waterfall together are under 4 percent. That is not proof Velocity is better; it is proof that the plugin authors and hosts you will be asking for help have mostly moved.

The comparison, point by point

The PaperMC comparison page says the same thing with more words, and it is where the performance and forwarding claims above come from.

Forwarding is the real difference

Both proxies put your backends in offline mode. What differs is how a backend knows a connection really came from your proxy.

• BungeeCord's ip_forward writes the player's UUID and IP into the handshake. A backend with bungeecord: true in spigot.yml believes whatever is in that field. If the backend port is reachable, a crafted handshake logs in as any player. The SpigotMC install guide itself warns that unauthenticated backends "pose a new security risk" and tells you to firewall them.
• BungeeGuard fixes that by adding a secret token to the handshake on the proxy and rejecting logins without it on the backend. It is a separate plugin by lucko, MIT licensed, and it works on both BungeeCord and Velocity (Velocity has a bungeeguard forwarding mode for exactly this case).
• Velocity modern forwarding builds the secret in. The proxy signs the forwarded data with forwarding.secret, and Paper verifies it with the proxies.velocity.secret in paper-global.yml. No extra plugin, and Velocity's docs still call it "not a replacement for a firewall."

Plugin ecosystems, honestly

This is the one place BungeeCord can still win. Some proxy plugins, especially old network cores, custom queue systems and a few paid hub plugins, were written for the BungeeCord API and never ported. Before you decide, list every jar in your proxy's plugins folder and check each one:

If the last row is empty for you, there is nothing holding you on BungeeCord. If it has an entry you cannot replace, that is your reason to stay for now.

Migration checklist, BungeeCord to Velocity

Do this on a second port first so the live network keeps running until the last step.

1. Inventory the proxy plugins using the table above. Download the Velocity build of each. Anything with no Velocity build gets a decision now, not on switch night.
2. Install Velocity in a new folder with Java 25 or newer, start it once to generate velocity.toml and forwarding.secret, and stop it. Set bind to a spare port such as 0.0.0.0:25580 for testing.
3. Translate config.yml into velocity.toml. The mapping is direct: listeners.host becomes bind; each entry under servers becomes a line in [servers] as name = "ip:port"; priorities becomes try; forced_hosts becomes [forced-hosts]; motd stays motd but in MiniMessage, so convert &a codes to <green> tags; max_players becomes show-max-players; ip_forward becomes player-info-forwarding-mode = "modern".
4. Switch each backend to modern forwarding. In spigot.yml set settings.bungeecord to false. In config/paper-global.yml set proxies.velocity.enabled to true, online-mode to true, and secret to the contents of forwarding.secret. online-mode=false in server.properties stays as it was. Backends on Spigot without Paper cannot do this; use legacy or bungeeguard mode for those until you move them to Paper. Full detail in the Velocity setup guide.
5. Point LuckPerms at the same database. The Velocity LuckPerms uses the same storage-method and credentials as the Bungee one did, so groups and prefixes carry over. Set messaging-service to pluginmsg on the proxy and every backend. Set server in each backend's config if you use per-server contexts.
6. Move NuVotifier. Copy the token from the Bungee config.yml into Velocity's config.toml so server lists keep working without a token change, and keep forwarding.method as pluginMessaging.
7. Test on the spare port with the whole staff team: skins, UUIDs, /server, prefixes, a test vote, Bedrock if you run Geyser, and a backend restart to confirm the try fallback.
8. Switch. Stop BungeeCord, change Velocity's bind to the old port, start it. Players notice nothing except a new MOTD if you changed it.
9. Keep the BungeeCord folder for two weeks untouched. Rolling back is "stop Velocity, start Bungee, flip settings.bungeecord back to true" and nothing else.

When staying on BungeeCord is fine

Not every network should migrate this month. Staying is reasonable when:

• A plugin you cannot replace only exists for BungeeCord and Snap does not run it cleanly. Rewriting a network core is a bigger job than a proxy swap.
• Your backends are locked down and you run BungeeGuard. With a firewall and a token, BungeeCord's forwarding is safe in practice. Without those two, you are not "fine," you are exposed.
• You update the same day SpigotMC ships builds. BungeeCord's 26.1, 26.2 and 26.3 builds all landed this year, so version support is not a reason to leave. Falling behind is.
• Nobody on the team knows TOML or MiniMessage yet and the network is small. Learn it on a test proxy first; do not learn it live.

What is never fine is Waterfall in 2026 or a BungeeCord backend reachable from the internet. Fix those first; the proxy choice can wait.

Whichever proxy you end up on, the address you list is the proxy's. Make sure your listing carries it, tag every mode the network offers (servers listing four or more modes on our list have a median of 37 players online against 10 for the rest), and claim the listing from its server page so the description and 7-day chart are yours. Not listed yet? Adding a server is free and takes about two minutes.

Quick questions