Gate: Building a Better Minecraft Network Proxy
gate (minekube/gate)
High-performance, resource-efficient Minecraft reverse proxy and library with robust multi-protocol version support. Designed as a scalable Velocity/BungeeCord alternative, suitable for both development and large-scale deployments. Proven in production environments, powering our global Connect edge proxy network.
If you've ever run a Minecraft server network, you know the proxy layer is everything. It's what routes players between your servers, handles disconnections smoothly, and lets you scale without melting your hardware. Gate is a high-performance alternative to Velocity and BungeeCord built in Go, and it's designed for teams who want something modern without the bloat or frequent maintenance headaches.
What Gate Does
At its core, Gate sits between your players and your backend servers. When a player connects, Gate intercepts them, handles authentication, then forwards them to the right server based on your rules. Simple enough. But Gate does this while consuming way less CPU and memory than the Java alternatives, which matters when you're running dozens of backend servers or expect traffic spikes.
Think of it like a bouncer at a club who's also fluent in three languages and somehow reads minds. Your players join, Gate figures out where they should go, and they're off playing before anyone notices the handoff happened.
The proxy supports multiple Minecraft versions simultaneously without juggling separate processes. Forge servers, vanilla servers, modded servers, even Bedrock players via the built-in Geyser integration - Gate handles all of them through a single proxy instance. No plugins required for Bedrock cross-play.
Why You'd Use Gate Instead of Velocity
Velocity is stable and widely used, sure. But it's also written in Java, which means memory overhead, startup time, and tuning JVM arguments like you're debugging production at 2 AM. Gate is written in Go - it starts instantly, uses a fraction of the RAM, and needs almost zero configuration tweaking to run well. On a 20-server network, you might be looking at Velocity using 800MB+ versus Gate at 150MB.
That matters. Especially for smaller communities where every MB of server RAM translates directly to whether you can keep your forum running on the same box.
Gate also has some features Velocity doesn't have out of the box. Modern Forge forwarding support for versions 1.13 through 1.20.1 is genuinely useful if you're running a modded network. Velocity requires the third-party Ambassador plugin for this - Gate just does it. And the latest version (v0.64.0) added lock-free protocol switching, which sounds like internal optimization minutiae until you realize it means fewer network hiccups during server switches.
It's also actively maintained by a team that actually uses it in production. The code is on GitHub, it's open source under Apache 2.0, and the maintainers aren't afraid to ship breaking changes when the tradeoff is better performance or correctness.
How to Install and Get Running
Installation is refreshingly straightforward. Pick your platform and run the installer:
# Linux/macOS
curl -fsSL https://gate.minekube.com/install | bash
# Windows PowerShell
powershell -c "irm https://gate.minekube.com/install.ps1 | iex"
# Or if you've Go installed
go run go.minekube.com/gate@latestThat's it. You'll get a config file, fill in your backend servers, point your players at Gate's IP, and restart. The documentation on their website walks through the YAML configuration pretty clearly. Most setups take 10 minutes to get working.
One tip: if you're running multiple backend servers, you might want to use Gate's "Lite Mode" to route players to different backend servers based on the hostname they join with. So players joining "creative.example.com" hit your creative server while "survival.example.com" goes to survival. That's a pretty clean setup for larger networks.
And if you need to manage your backend server settings, the Server Properties Generator over on minecraft.how saves a lot of manual typing - though you'll still need to SSH into each server to actually deploy the properties file. Also, if you're thinking about DNS routing for your backend servers, the site has a free DNS tool that's useful for internal network management.
The Features That Matter
Bedrock cross-play is baked in. Gate ships with Geyser integration, which means Bedrock players (mobile, console, Windows) can play alongside Java players with zero additional setup. You're not routing through a separate Geyser instance on a different port - it's all one proxy. That's a legitimately nice touch, and it's why it's become popular with networks that want to maximize their player base.
Forge modded servers get first-class treatment too. The v0.64.0 release finally added "Modern Forge" (FML2/FML3) login relay for versions 1.13 through 1.20.1. Previously, this was broken on both Gate and Velocity without workarounds. Now it just works. If your backend server runs Forge with Proxy-Compatible Forge, players switch servers without the full Forge handshake happening twice - Gate caches it and replays it. Faster, smoother, less laggy.
The protocol state switching I mentioned earlier is the kind of thing you don't think about until it breaks. Gate now uses atomic pointers to swap protocol states instead of blocking the network decoder on a mutex. Sounds niche, but it means fewer jitter spikes when dozens of players are connecting and switching servers at the same time.
What Trips People Up
Configuration ordering matters. Gate reads its config file in a specific way, and if you don't set up your backend servers in the right section, they won't route correctly. The docs are clear about this, but if your players keep hitting "connection refused," check that your servers are in the "servers" block and your routes are pointing to valid server names.
Firewall rules. If you're running Gate on a cloud VPS, make sure port 25565 is actually open inbound. That sounds obvious until you spend an hour thinking Gate is broken when it's just UFW silently dropping packets.
Player profile caching can cause headaches if you're testing locally and keep switching accounts. Gate caches player profiles by default - if you join as Player1, disconnect, then immediately try to join as Player2 from the same IP, you might get a stale cache hit. There's a config option to disable this, but most people discover it the hard way after wondering why their alt account won't load.
Alternatives Worth Considering
Velocity is the obvious comparison. It's heavier, requires Java, but it has an enormous plugin ecosystem if you need deep customization. For vanilla proxying, Gate beats it. For heavily modded setups with custom Velocity plugins, Velocity wins.
BungeeCord is older, slower, and honestly you should skip it unless you're maintaining legacy infrastructure. Gate or Velocity are both better choices today.
Waterfall is a BungeeCord fork that's lighter and faster, but it's still Java and still not as clean as Gate's architecture.
If you're building something brand new and don't have deep Velocity plugin requirements, Gate is the play. It's mature enough for production (1014 stars on GitHub, active development) but still feels like a tool built by people who actually run Minecraft servers.
