← All posts
minecraftserver-managementproxyvelocitybungeecord

Velocity vs BungeeCord vs Waterfall in 2026: Where Proxies Stand Now

Waterfall is deprecated, BungeeCord is still here, and Velocity is where new networks land. A clear look at plugin support, player info forwarding and modern version support.

ChunkPod Team · · 6 min read

Velocity vs BungeeCord vs Waterfall in 2026: Where Proxies Stand Now

A Minecraft proxy sits in front of your backend servers and lets players move between them without disconnecting. For years, admins had three real choices for that job: BungeeCord, Waterfall and Velocity. That list has shrunk, and the gap between what's left keeps widening.

Here's where each proxy actually stands right now, and why most new networks land on Velocity.

Who maintains what

BungeeCord is the original. It's maintained by md_5 and the SpigotMC team, the same people behind Spigot itself. It ships alongside Spigot and gets updates when the Minecraft protocol changes, but the pace is set by that team and their priorities.

Waterfall was PaperMC's fork of BungeeCord. It patched a bunch of long-standing issues, added a few config knobs and generally ran better under load. PaperMC has since deprecated it. New releases stopped, security fixes stopped, and the project's own docs point people at Velocity instead. If you're still running Waterfall today, you're running a fork that isn't being updated.

Velocity is also from PaperMC, but it isn't a BungeeCord fork. It was written from scratch, with a new plugin API, a different threading model and a different approach to player info forwarding. It's the proxy PaperMC actively works on.

Plugin support

The BungeeCord plugin catalogue is huge. It's been around for over a decade, so almost every proxy plugin you can name, from LuckPerms bridges to lobby balancers to Discord relays, has a BungeeCord build somewhere. Waterfall runs BungeeCord plugins directly, so the two share the same catalogue.

Velocity uses a different plugin API. That was a real hurdle a few years ago, and less of one now. The plugins most networks actually rely on, things like LuckPerms, ViaVersion, LibreLogin, PremiumVanish and most Discord bridges, all have Velocity builds. Some smaller BungeeCord plugins never got ported, and probably never will. If a very specific old plugin is load-bearing for your setup, check it before you migrate.

The direction of travel is one-way. New proxy plugins tend to target Velocity first, and some of them have no BungeeCord equivalent at all.

Player info forwarding

This is where the three proxies really pull apart, and it's the part most admins underestimate until something breaks.

The problem: a proxy sits in front of your backend servers. By default, the backend sees the proxy's IP and can't tell one player from another. To fix that, the proxy has to forward the player's real address, name and UUID to the backend. If it does that badly, anyone who can reach the backend directly can pretend to be any player they like.

Legacy BungeeCord forwarding is the old default. The proxy passes the player's data in the handshake, and the backend trusts it. It works, but the only thing stopping a stranger from connecting straight to a backend and claiming to be your admin is the firewall on that machine. If any backend port is reachable from the internet, you have a serious problem.

BungeeGuard is a plugin patch on top of legacy forwarding. It adds a shared token between the proxy and the backend, so backends reject connections that don't carry the token. It's a real improvement, but it's still a bolt-on, and you have to install and configure it on every backend.

Modern forwarding is Velocity's own scheme, and it needs Paper (or a Paper fork such as Purpur) on the backend. The proxy and each backend share a secret. When a player joins, the backend asks the proxy for that player's real info and checks the response against the secret. Backends refuse direct connections that can't prove they came through the proxy. There's no separate plugin to install, and no token file lying around that you have to rotate by hand.

Modern forwarding is the reason most new networks pick Velocity. It's built into the proxy, it's the default on Paper backends, and it removes an entire class of "someone joined my server as OP" incidents.

Waterfall supported legacy and BungeeGuard forwarding, but never Velocity's modern scheme. BungeeCord is the same story.

Modern version support

Every time Mojang ships a new Minecraft version, the protocol changes, and every proxy has to catch up. In practice:

  • Velocity usually picks up a new release quickly, often within days.
  • BungeeCord follows on the SpigotMC team's own schedule.
  • Waterfall doesn't follow anything anymore. New Minecraft versions may work by inheritance from BungeeCord for a while, but nobody is making sure they will.

ViaVersion and its sibling plugins can bridge protocol gaps on all three, letting older or newer clients connect to a backend that hasn't caught up. That's a rescue tool, not a substitute for the proxy actually supporting the version natively.

Why Velocity has become the default

Add up the pieces:

  • It's actively maintained, by the same team that maintains Paper.
  • Its plugin API is modern, and the plugins most networks need already run on it.
  • Its player info forwarding doesn't rely on firewall trust or a bolt-on plugin.
  • It picks up new Minecraft versions fast.
  • Its config is a single velocity.toml file that's easier to reason about than BungeeCord's mix of YAML and inherited defaults.

None of that means BungeeCord is broken. If you already run a stable BungeeCord network with plugins you trust and a firewall you've locked down, there's no fire drill. But if you're building a new network in 2026, Velocity is where the plugin scene is heading, and starting on Velocity means you don't have to migrate later.

Should you switch if you're already on BungeeCord or Waterfall?

Waterfall: yes, and the PaperMC team says the same. You're on an unmaintained fork. The migration path they recommend is Velocity, and the two share enough concepts that most Waterfall admins find it manageable. Your existing BungeeCord plugins won't come across with you, so audit them first.

BungeeCord: it depends. If your network is small, stable, and everything you rely on has a BungeeCord build, staying is fine. If you're planning a bigger network, adding new backend servers, or you've been fighting legacy forwarding and BungeeGuard configs, moving to Velocity pays for itself pretty fast.

Either way, the one thing worth doing before you migrate is writing your new proxy config from scratch instead of trying to translate the old one line by line. The two systems name things differently, and half of the "Velocity broke my network" threads you see online are actually old BungeeCord assumptions carried across.

If you're planning that config, ChunkPod's Velocity Config Builder at chunkpod.com/tools will generate a working velocity.toml from presets for different network sizes, including modern player info forwarding and forced hosts. It's free and runs in the browser. ChunkPod itself is a Minecraft host in early access, so if you want to be notified when hosting opens, the waitlist is on chunkpod.com.

The proxy layer used to be a genuine three-way choice. It isn't anymore. Velocity is the proxy that gets the attention, the version support and the security work, and that's where new networks should start.