Gate is an extensible, high-performance Minecraft proxy server written in Go that sits between players and backend Paper, Spigot or Vanilla servers so operators can run Java and Bedrock networks with multi-version support, aimed at teams running Minecraft server networks on cloud infrastructure. It is licensed Apache-2.0 and carries 1,081 stars and 109 forks on GitHub.

What it is

Gate is a standalone proxy process for the Minecraft ecosystem: players connect to it, and it forwards them to backend Minecraft servers. It accepts Java Edition traffic over the Java protocol and, through integrated Geyser and Floodgate, accepts Bedrock Edition players from mobile, console and Windows so they share the same network as PC players. The project is written in Go, published as the module go.minekube.com/gate, and packaged for cloud deployment with Docker and Kubernetes among its listed topics; the tagline describes a 10MB footprint and states that it powers the global Connect network at production scale.

The concrete problem it solves is version and platform fragmentation. A conventional setup forces either pinning every backend to one Minecraft version or operating a separate Via sidecar to translate protocols, and Bedrock cross-play traditionally requires Geyser and Floodgate installed as plugins on a backend server. Gate absorbs both concerns into the proxy itself: managed Via-powered backend translation runs through vialite, and Bedrock support is switched on with a single bedrock: true configuration line with zero plugins required. It is also extensible through a Go API, so networks can register backends programmatically rather than only through static configuration.

Key capabilities

• Built-in Bedrock cross-play: integrated Geyser and Floodgate accept Bedrock players on port 19132 and forward them to Gate on port 25567, with no plugins required on the backend.
• Managed Via version translation: setting config.via.enabled: true starts the native vialite subprocess, resolves the latest stable vialite release, downloads the checksummed artifact into a local cache, and routes backend connections through it, removing the need for a separate Via sidecar.
• Dynamic backend registration via Gate's Go API, where API-registered backends are added to vialite at runtime so Connect-style session backends follow the same version-compatibility path as servers declared in config.
• Lite Mode, a lightweight variant that exposes multiple Minecraft servers through a single port and IP address and reverse-proxies players to backends based on the hostname or subdomain they join with.
• Deployment flexibility across go run go.minekube.com/gate@latest, a curl install script for Linux and macOS, a PowerShell installer for Windows, and container-friendly packaging for Docker and Kubernetes.
• Controlled deployments remain possible through exact vialite release pins, offline mode, and local artifact paths, with embedded vialite mode available for configured servers.

Who uses it and how

• Networks running backends on differing Minecraft versions, where a single proxy tier handles translation instead of a sidecar per server.
• Cross-play communities where Java players on PC and Bedrock players on mobile, console and Windows join the same proxy and land on shared backends.
• Hosting setups that route by hostname: Lite Mode maps individual subdomains to individual backend servers over one IP and port.
• Cloud and container deployments, indicated by the Docker and Kubernetes topics and by the project's cloud-ready positioning.
• Modded networks, indicated by the forge and minecraft-forge topics alongside the documented Paper, Spigot and Vanilla backend types.

Getting started

Gate runs directly with go run go.minekube.com/gate@latest, or installs on Linux and macOS via curl -fsSL https://gate.minekube.com/install | bash and on Windows via the PowerShell installer. The quick start guide at gate.minekube.com walks through building a simple Minecraft network from there.

How it compares

The facts do not list paid products that Gate replaces, and they name no directly comparable proxy, so no licence or cost comparison can be drawn here. What it does displace is the separate Via sidecar and plugin-based Geyser/Floodgate arrangement, both of which it folds into a single self-hosted Apache-2.0 proxy; on that basis it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate the proxy process itself, and the managed Via path additionally runs a vialite subprocess that resolves, downloads and caches a checksummed artifact, which assumes outbound access or a preconfigured offline artifact path. Documentation lives largely on the external website rather than in the README, and the repository carries 55 open issues, so operators should expect to consult the site and the issue tracker. Teams running a single server that needs neither multi-version translation nor Bedrock cross-play should connect players directly rather than add a proxy tier.

bedrock: true

graph LR
    A[Java Players<br/>PC] -->|25565| D(Gate Proxy)
    B[Bedrock Players<br/>Mobile/Console/Win] -->|19132| C(Geyser)
    C -->|25567| D
    D -->|Java Protocol| E[Backend Server<br/>Paper/Spigot/Vanilla]

    style A fill:#b36b00,stroke:#333,stroke-width:2px
    style B fill:#007a7a,stroke:#222,stroke-width:2px
    style C fill:#1e90ff,stroke:#222,stroke-width:2px
    style D fill:#2e8b57,stroke:#222,stroke-width:2px
    style E fill:#a0526d,stroke:#222,stroke-width:2px

config:
  via:
    enabled: true

graph LR
    A[Player Alice] -->|Join example.com| C(Gate Lite)
    B[Player Bob] -->|Join my.example.com| C(Gate Lite)
    C -->|10.0.0.1| D[Backend A]
    C -->|10.0.0.2| E[Backend B]
    C -->|10.0.0.3| F[Another Proxy]

    linkStyle 0 stroke:orange
    linkStyle 1 stroke:purple
    linkStyle 2 stroke:purple
    linkStyle 3 stroke:orange