What would it take to allow BungeeCord to connect to another BungeeCord? One might ask: Why? For my example, we'll take a server that is under steady DDOS attacks. Attack hits the server, server goes down, life goes on. Now, in most cases, this can be waited out or we can do something about it - split the load. Bring up multiple VPSes, put BungeeCord on them and point them at your servers. This raises costs, but can generally be effective. For basic servers, this works well. Now let's take into consideration BungeeCord's growing library of different plugins; they have a single BungeeCord in mind. BungeeBans maintains a ban database, and if someone connects to that BungeeCord then they're subject to it. However, in our example, what if there are multiple Bungee instances and someone connects to another one of those servers? Now they've bypassed BungeeBan.Same with BungeeChat+, if you connect through a different Bungee server then your chat will not be synced with the other ones. This can be mitigated by various levels of syncing; MySQL for databases, maybe IRC for chat. Not ideal, when BungeeCord is a perfectly viable system already. But it does not scale well for additional frontend. So on to the solution: Bungee connecting to Bungee. We could have a single Bungee server (Prime Bungee), that communicates with all of the Minecraft servers, and multiple Bungee instances (Proxies) on VPSes. If we have BungeeBans, BungeeChat, and all the other various Bungee plugins we might need in the future on Bungee Prime - it can communicate with the various proxies, removing the need to adapt around limitations. I know there are networks that redid their locations.yml to be in a database, this would no longer be necessary - Locations.yml would be read/set by the Bungee instance closest to the MC server, the Prime. I've asked about this before, and was met with responses roughly equating "Why bother?" I still think this is a perfectly acceptable route to attack mitigation, when compared alternate solutions.