Waterfall Server Hosting

What is Waterfall, and should you still run it?

Waterfall is PaperMC's fork of BungeeCord, created to improve performance and stability while staying compatible with the BungeeCord plugin API. Any plugin written for BungeeCord runs on it, which is why it served as the default proxy for a huge number of Minecraft networks for years.

The situation has changed, and it is worth being plain about it. On March 26, 2024, PaperMC announced Waterfall's end of life: the project no longer receives maintenance or support, and the team now focuses on Paper and Velocity. Old builds and documentation remain available. Automated builds that pull in upstream BungeeCord changes can still show up on the download page, but PaperMC states clearly that it does not test them.

So if you are starting a network from scratch, pick Velocity. Waterfall still makes sense as a waypoint for an established network that relies on BungeeCord plugins with no Velocity equivalent yet, or for admins who want to migrate on a calm timeline instead of in a rush.

Which config.yml settings define your network?

Waterfall inherits BungeeCord's config.yml as its main file, while Waterfall-specific extras live in waterfall.yml. Under servers, each backend gets a name, an address field holding the IP:port from its panel, and an optional restricted flag. Under listeners you set the host the proxy binds to, the motd and max_players shown in the server list, and the priorities list that decides where players land on login.

forced_hosts ties a hostname to a particular server. With force_default_server enabled, players always start at the top of priorities; with it disabled, they return to the server they last played on. ip_forward must be true, otherwise backends never receive real UUIDs and IP addresses.

Permissions are handled in the permissions and groups sections. The default file ships with an example admin called md_5 under groups, so replace it with your own username or hand permissions over to LuckPerms. connection_throttle slows down rapid repeat connections from a single IP, which helps when bots start hammering the login.

How do ip_forward and BungeeGuard keep backends safe?

BungeeCord-style forwarding sends player data without any signature. Backends run with settings.bungeecord set to true in spigot.yml and online-mode set to false in server.properties, so anyone who discovers a backend port can try to bypass the proxy and join under a forged identity, including the username of a staff member.

The traditional fix is a firewall rule that only lets the proxy reach backend ports. If you do not control networking at that level, BungeeGuard is the practical alternative: the proxy-side plugin attaches a secret token to each connection, and the backend-side plugin rejects anything that arrives without it. Keep that token in your config files only, and never paste it into screenshots or public support threads.

The other safeguard is online_mode on the proxy, which should stay true so accounts are verified with Mojang. Networks that open up to cracked clients switch it off, but at that point identity security rests entirely on your own login and authentication plugins.

How much RAM does Waterfall need?

Very little compared with the game servers behind it, because a proxy never loads a world. A network with a few hundred concurrent players sits comfortably on Bronze 4 GB with much of that memory idle. What really moves memory usage is the plugin list on the proxy: large permission datasets, session-tracking statistics plugins, or Geyser installed at the proxy level for Bedrock players.

As player counts grow, per-connection compression and encryption work increases, and at that point core count takes over from RAM as the thing to watch. Bronze through Diamond come with 4 vCores of Ryzen 9 9950X, Emerald with 6 and Xtreme with 12. If you are still running a network of several thousand players on Waterfall, those extra cores will help, though at that scale we would rather see you schedule a Velocity migration than keep growing on unmaintained software. Storage needs are modest; logs and plugin data rarely strain the 50 GB of NVMe on the entry plan.

A step-by-step route from Waterfall to Velocity

The least painful migration swaps the proxy first and touches the backends later. Velocity's legacy forwarding mode speaks the same format as BungeeCord, so backends with the bungeecord flag enabled in spigot.yml keep working behind Velocity; if you already use BungeeGuard, Velocity's bungeeguard mode supports the same token approach.

Begin with a plugin inventory. For each BungeeCord plugin, note whether a Velocity build exists or whether you need an alternative that does the same job. Plugins that store data in a shared database, LuckPerms being the obvious example, keep their data untouched. Then open a Velocity plan and translate the servers and priorities from config.yml into the servers block and try list of velocity.toml.

Once staff have tested everything, repoint your domain at the new proxy. After it settles, move the backends to modern forwarding one by one and turn off the bungeecord flag in spigot.yml. Keeping the old Waterfall server and its backups around for a while gives you a fallback if something unexpected surfaces.