BungeeCord and Waterfall in 2026: Legacy Proxies and Moving to Velocity

If you are setting up a Minecraft network from scratch today, this is not the page you want — Minecraft Server Networks: Setting Up a Velocity Proxy is, and it will not send you back here. This page is for the other situation: you already run BungeeCord, or you inherited a Waterfall network from whoever ran the server before you, or you searched one of those names because every tutorial from 2019 uses them. It covers what each project actually is in 2026, what still works, and what moving off looks like.

Nothing here re-explains what a proxy does or how forwarding secrets work. That is all in Minecraft Server Networks; this page assumes it.

Where the Three Projects Stand

Two of those rows are the whole story, and they point in different directions.

Waterfall is dead and PaperMC says so. The end-of-life announcement is dated 26 March 2024 and is unambiguous about the reason: "We don't think we can find enough people from our team and contributors to put that work into Waterfall anymore, we want to focus our efforts on our flagship projects Paper and Velocity." It is not a soft deprecation, either — PaperMC's own build API still reports every Waterfall version as UNSUPPORTED with a support end date of 2024-03-26, and the Waterfall documentation carries a banner reading "We recommend you transition to Velocity."

BungeeCord is not dead. This is the part most "just use Velocity" advice gets wrong. SpigotMC still builds it — build #2086 landed on 9 August 2026 — and its protocol support list currently runs 1.8.x through 26.x, which means it speaks to a current client on a current server. If you are running BungeeCord today it works, and it will keep working.

Waterfall downloads still exist, and that is deliberate

The EOL announcement said explicitly: "All documentation will still be accessible, you will still be able to download all versions of Waterfall as usual. What will change is that you will see even more sporadic updates." That is exactly what happened — the repository has picked up occasional upstream BungeeCord merges since, including in June 2026. Sporadic is not the same as maintained. Nothing is being fixed on Waterfall, and nobody is on the hook if something breaks.

Why Velocity Replaced Them

The reason is not performance, though Velocity is more efficient. It is the security model, and it is worth understanding rather than taking on faith, because it changes what a mistake costs you.

Every proxy network puts its backend servers into online-mode=false, because the proxy does the authentication instead. SpigotMC's own BungeeCord installation guide states the consequence plainly: "As your servers will now be running without authentication, this poses a new security risk. Users may connect to your servers directly, under any username they wish to use."

BungeeCord and Waterfall forward the player's identity to the backend in a plain, unauthenticated format. Anything that can reach the backend port can send the same thing, claiming to be your administrator. Their answer to that is entirely external: firewall the backends, bind them to 127.0.0.1, run a VPN, or install an IP-whitelisting plugin. SpigotMC recommends BungeeGuard for the last of those, noting that the older IPWhitelist plugin "is exploitable if the attacker purchases a BungeeCord server on the same GSP as you."

Velocity's modern forwarding signs the forwarded data with a MAC code derived from a shared secret. A backend configured for it rejects anything that does not carry a valid signature, so reaching the port is no longer enough. Velocity's documentation is careful to add that this is "not a replacement for a firewall" — but on managed hosting, where you do not control the host firewall, it is the difference between one line of defence and none.

That is the honest case for moving. Not that BungeeCord is broken; that its security model requires a firewall you may not have.

If You Are Staying on BungeeCord for Now

There is no emergency, and mid-season is the wrong time to rebuild a network. Do these three things instead.

1. Confirm ip_forward is on. In BungeeCord's config.yml:

ip_forward: true
online_mode: true

SpigotMC's guide is blunt about what happens otherwise: without it, "serious data inconsistencies will occur" — online-mode UUIDs, name changes and IP bans all stop working correctly, because the backend only ever sees the proxy.

2. Confirm the backends match. Every backend needs online-mode=false in server.properties, and every Spigot- or Paper-based backend needs settings.bungeecord: true in spigot.yml. Both, on all of them. One backend with the wrong pair is the one that breaks.

3. Lock the backends down. If the proxy and backends are on the same machine, set server-ip=127.0.0.1 on each backend and point the proxy at 127.0.0.1:<port>. If they are not, you need a firewall, a VPN, or BungeeGuard. Never publish a backend's address anywhere — once it is in offline mode, its IP and port are a credential.

ip_forward: true with an unprotected backend is worse than either alone

With forwarding on and no protection, an attacker connecting directly to a backend can claim any username and have the backend believe it, including your own. That combination is how server takeovers happen. If you cannot firewall the backends, at minimum install BungeeGuard.

Moving to Velocity

There is no automated migration and no official BungeeCord-to-Velocity guide — PaperMC's Velocity migration page covers Velocity version upgrades only. You rebuild the configuration by hand. It is a couple of hours, and the map below is most of it.

The order that avoids an outage:

1. Take a backup, and note every plugin on the proxy and what it does.
2. Find Velocity equivalents for each before you start. This is the step that determines whether the migration is two hours or two weeks.
3. Stand the Velocity proxy up on a spare port, pointed at the same backends, and get it working while BungeeCord is still serving players.
4. Switch the backends to modern forwarding and restart them one at a time.
5. Move the player-facing port to Velocity, and stop BungeeCord.

Step 2 is the real work. BungeeCord plugins do not run on Velocity. The Velocity project notes that an unofficial compatibility layer called Snap exists for experimental support, but it is not maintained by or affiliated with them, and a proxy plugin failing to load takes the whole network offline at once. Plugins that only install on the backend and communicate over the BungeeCord plugin messaging channel are generally fine, because Velocity supports that channel natively.

Also check your Velocity version before you commit: 4.0.0 needs Java 25, while 3.5.1 still runs on Java 21 and has broader plugin support today. Minecraft Server Networks covers that choice and the full modern-forwarding setup.

When Staying Put Is Defensible

Three cases, and only three.

• You need 1.7.x clients. BungeeCord's own supported list starts at 1.8.x; Travertine was the Waterfall fork that added 1.7 support and its repository was archived in 2021. If genuinely ancient clients matter to you, you are in legacy territory whichever proxy you pick, and Velocity's legacy forwarding mode reaches 1.7.2 — so Velocity is still the better half of a bad choice.
• One plugin has no Velocity equivalent and no alternative. Real, and worth measuring rather than assuming. Check Hangar, PaperMC's plugin repository, before concluding it.
• You are mid-season on a working network. Plan the move for a wipe or season boundary, when you can redo forwarding cleanly rather than migrating it live.

Note that the middle case does not force you to stay: Velocity supports a bungeeguard forwarding mode — BungeeCord's format plus a shared secret — which is better than plain legacy forwarding and lets you run Velocity while keeping backend compatibility. It is a stepping stone, not a destination.

Not sure a network is the right shape at all?

Several worlds on one server is a Multiverse job, not a proxy job, and it is far less work than any of the above. The dividing line is in Minecraft World Management. And splitting a laggy server into three does not remove the load — profile first with Diagnosing Minecraft Server Lag.

Common Issues on a Legacy Network

• If you wish to use IP forwarding, please enable it in your BungeeCord config as well! — the backend has settings.bungeecord: true but the proxy has ip_forward: false. Set both, restart both.
• Players join with no skin and every connection comes from the proxy IP — ip_forward is off. UUIDs are wrong too, which is why inventories look reset.
• Inventories vanished after adding the proxy — the backends went from online to offline mode, which changes every player's UUID. Nothing is deleted; see Editing Minecraft Player Data for where the old files are.
• Someone joined as an admin who was not one — a backend is reachable from outside. Stop the network, lock the backends down, then work out what they did.
• A BungeeCord plugin does not load after switching to Velocity — expected, and not fixable in configuration.

What to Read Next

• Minecraft Server Networks: Setting Up a Velocity Proxy — the current guide, and where a migration ends up
• Minecraft Server Software Compared — what each backend should run
• How to install plugins for Minecraft Java Edition — proxy and backend plugins
• Minecraft server.properties: The Complete Reference — online-mode, server-ip and the rest
• Minecraft World Management — if several worlds is what you actually wanted
• Diagnosing Minecraft Server Lag — the performance work a proxy does not do for you
• Editing Minecraft Player Data — recovering players after a UUID-scheme change

Primary sources used for this guide (all checked 19 August 2026): PaperMC's Waterfall end-of-life announcement, the Waterfall documentation, Velocity's proxy comparison, player information forwarding and migration guide; PaperMC's Fill API for support status and Java requirements; SpigotMC's BungeeCord installation and configuration guide; the BungeeCord build server and its supported protocol list.

Made with 💜 by GameServerKings