Short answer: run Waterfall. Same config, same plugins, faster, more bugfixes. The only reason to pick stock BungeeCord is if you're running a plugin that explicitly refuses to load on Waterfall, and that's a list of approximately zero plugins as of 2026.

Long answer below — what each one is, where they came from, and the edge cases where it matters.

The lineage

BungeeCord — the original Minecraft proxy by md_5, started around 2013. Lets you stitch multiple Minecraft servers into one network: a lobby, a PvP server, a creative server, all behind one IP. SpigotMC maintains it.

Waterfall — fork of BungeeCord by the PaperMC team, started 2016. Same API, same config, drop-in replacement. Adds patches BungeeCord rejected: better thread handling, bug fixes that sat in BungeeCord PRs for years.

PaperMC announced in 2023 they'd stop active development and recommend Velocity for new networks. But Waterfall still gets security patches, and for existing networks there's no rush. Velocity is a separate post.

What they share

  • Identical config.yml syntax. My BungeeCord config.yml deep-dive applies to both.
  • Same plugin API. Drop the same .jar into the plugins/ folder.
  • Same IP-forwarding contract with backends.
  • Same start command, just a different JAR.

If you have a working BungeeCord setup, swapping to Waterfall is:

sudo systemctl stop bungeecord
cd /opt/bungeecord
mv BungeeCord.jar BungeeCord.jar.bak
wget https://api.papermc.io/v2/projects/waterfall/versions/latest/builds/latest/downloads/waterfall.jar
mv waterfall.jar BungeeCord.jar
sudo systemctl start bungeecord

(Yes, you can leave the filename as BungeeCord.jar — your systemd unit doesn't care, and rolling back is a one-line revert.)

Where they differ

Performance

Waterfall handles connections on a smarter event loop. On a small network (5 backends, 50 players), you won't notice. Past 200 concurrent players the difference shows up — Waterfall's CPU is maybe 30% lower under the same load, and pings are tighter.

For a friends-and-family network, irrelevant. For a public server, run Waterfall and don't think about it.

Security patches

This is the one that actually matters. BungeeCord upstream is slow. Waterfall picks up CVE patches (the proxy-tier ones, not the backend Paper ones) within days. BungeeCord can take weeks or skip them entirely if md_5 disagrees with the patch.

If you're internet-facing — and your proxy port is, by definition — Waterfall's faster patch cadence is reason enough.

Wider hardening reference: SSH hardening checklist. Same thinking applies — fewer days exposed, fewer ways in.

Plugin compatibility

Waterfall is a strict superset. Every BungeeCord plugin works on Waterfall. The reverse isn't quite true — a few plugins use Waterfall-only API hooks — but in practice, in 2026, no maintained plugin requires BungeeCord and refuses Waterfall.

LuckPerms-Bungee, BungeeTabListPlus, RedisBungee — all run unchanged.

Logging

Waterfall logs more by default and the format is closer to what you'd expect. BungeeCord swallows stack traces in places where Waterfall surfaces them. When something breaks at 11pm, Waterfall tells you what; BungeeCord tells you a plugin disabled itself.

When to pick BungeeCord anyway

Honestly: never, for a new setup. The cases I can think of:

  • You inherited a server with custom forks of BungeeCord internals. Migrate when you have time.
  • You're following a tutorial from 2018 and don't want to deviate. Just run Waterfall — every command in that tutorial works.
  • Your hosting panel only ships BungeeCord. Switch panels or upload Waterfall manually as a custom JAR.

That's the list.

When to pick neither — Velocity

If you're starting fresh in 2026, look at Velocity before either of these. Velocity is the PaperMC team's modern proxy, written from scratch. Different config format (velocity.toml), different plugin API, different IP-forwarding scheme (modern instead of BungeeCord's), but materially better: lower latency, better backpressure, active development.

Migration from BungeeCord/Waterfall to Velocity is a rewrite of the proxy config and a swap of every plugin, since the plugin APIs are incompatible. For an existing 3-backend network, that's an evening of work. For a 30-backend network, it's a weekend.

I'm running Waterfall on the network I maintain because it predates Velocity and I haven't had a reason to migrate. If I were starting today, Velocity.

Decision tree

  • New small network, just want it to work → Waterfall.
  • New large network, want the best stack → Velocity.
  • Existing BungeeCord network, no problems → swap to Waterfall this weekend, it's 30 seconds.
  • Existing BungeeCord network, hitting performance walls → Waterfall now, plan a Velocity migration.

The two failure modes when you switch

Plugins log warnings about unsupported API on first start. Read the warning. If the plugin still loaded, you're fine — the warning is informational. If the plugin failed to load, check its page — there's almost always a Waterfall-compatible build.

Config silently rewrites. Waterfall (like BungeeCord) overwrites config.yml on shutdown to add fields it added in newer versions. Diff your config after the first clean shutdown to see what changed. Don't panic — the new fields default to safe values.

Backing up before the swap

sudo systemctl stop bungeecord
cp /opt/bungeecord/BungeeCord.jar /opt/bungeecord/BungeeCord.jar.bak
cp /opt/bungeecord/config.yml /opt/bungeecord/config.yml.bak

Three lines. If anything breaks, revert and you're back where you started. Same idea, full pipeline: rsync backups on Linux.

If you want the full setup walkthrough rather than just the proxy choice, the BungeeCord / Waterfall network setup guide covers the proxy + backends + DNS + IP forwarding end-to-end.

Related posts