--- url: https://connect.minekube.com/guide.md --- # Minekube Connect Introduction -> The Ingress Tunnel for Minecraft Servers Connect is a global gateway to a DDoS-protected Minecraft native Superproxy. A developer platform with public Anycast domains for localhost allowing admins to secure and scale servers/proxies to build durable Minecraft networks in any environment easily. *Sounds like techno marketing to you? Let's break the promises down, shall we?* -> No time to read! Get me started! [Quick Start](quick-start) / [Dashboard](https://app.minekube.com/) ## The Connect Platform The Connect Platform consists of the following components: * [The Connect Network](#the-connect-network) - A global edge network of router proxies * [The Connectors](/guide/connectors/) - Tunnels players <-> to servers through Connect Network * [The Connect Dashboard](#the-connect-dashboard) - A web interface for organizing your Minecraft network [//]: # "- [The Connect Browser](#the-connect-browser) - Server discovery for players" ## The Connect Network The Connect Network consists of highly available, scalable and self-healing edge proxies built on top of best-of-breed cloud native technologies and securely interconnects all active Minecraft server and proxy endpoints through [Connectors](/guide/connectors/) without noticeable overhead. The **Connect Network** is vital to the **Connect platform** and responsible for: * Establishing [Tunnels](/guide/tunnels) between players and your servers * Providing free public [domains](/guide/domains) to your public or [localhost](/guide/localhost) servers * [Advertising](/guide/advertising) your servers to players through multiple channels like the [Browser Hub](/guide/advertising#browser-hub) Connect can replace traditional proxies like BungeeCord or Velocity and become the largest shared Minecraft network in the world. *Core features of Connect are free and will always be free for everyone.* ## The Connect Dashboard The Connect Dashboard is a web interface for managing all resources of your Minecraft network in one place. -> https://app.minekube.com/ It allows you to manage your Endpoints, Connectors, Custom Domains, analyze statistics about your network, and much more. ## The Connect Browser The Connect Browser encompasses all the features that allow players to discover and join endpoints on the Connect Network. **Most notably, it's the in-game server browser that players can access with the `/browser` global command or by joining `minekube.net`.** Check out the [Advertising guide](/guide/advertising) to learn more! ## Connect Endpoints A Connect endpoint is a Minecraft server or proxy that is linked with the [Connect Network](#the-connect-network) through a [Connector](/guide/connectors/) and is identified by a globally unique human-readable name. Endpoints are also referred to as *servers* for simplicity. Endpoints are advertised to players and can be joined by using the [Connect Browser](#the-connect-browser). Any server that can serve Minecraft clients and is linked with the Connect Network can be an Endpoint. If you do not specify the Endpoint name in your [Connect Plugin](#the-connect-plugin) configuration, the plugin will ask the [Random Name Service](https://randomname.minekube.net/). **Related Guides:** * [Joining guide](/guide/joining) - Learn how to join endpoints. * [Advertising guide](/guide/advertising) - Learn about advertising your endpoints. * [Endpoint Domains guide](/guide/domains) - Learn how to use free domains for your endpoints. * [Bedrock support guide](/guide/bedrock) - Learn which Bedrock path applies to your setup. * [Offline Mode guide](/guide/offline-mode) - Learn how to allow offline mode players on your server. ## Connect Tunnels As soon as your server is started [Connectors](/guide/connectors/) link with Connect networking services and players can start joining your Minecraft server even if it's running [locally on your PC](/guide/localhost). Check out [How Tunnel connections work!](/guide/tunnels) for a technical explanation. ## Connect Sessions Connect defines two specific types of sessions: * **Endpoint Sessions**: These sessions are established by your [Connector](/guide/connectors/)'s Minecraft server/proxy to the Connect edge proxy to watch for incoming player sessions. * **Player Sessions**: These sessions are established by Connect edge proxies between players and available Endpoints that have an active Connector. ## Let's Speedrun the Quick Start! You have a Minecraft server locally or somewhere else? Let's get started and link it with the **Connect Network** for the first time! Just click the `Next page` button or click [Quick Start](quick-start)! ## The Connect Plugin Moved to [Connectors / Plugin](connectors/plugin). --- --- url: https://connect.minekube.com/guide/quick-start.md description: >- Connect a Minecraft server and let authenticated Java and Bedrock players join through one public address. --- # Quick Start *This page explains the steps to use Connect with your Minecraft server or network.* :::: info Prerequisites * You have a Minecraft server running anywhere (locally or remote). * You have a Java client, a Bedrock client signed in to Microsoft/Xbox, or an offline Java client for testing an endpoint that explicitly allows offline players. :::: ## Go to the Connect Dashboard! Optional Proceed the `Quick Start` from there: -> https://app.minekube.com If you want to use the Connect Dashboard after the set-up, follow the steps below. You can later import your Minecraft Endpoints to the dashboard to manage them. ## Step 1: Choose a Connector Connectors are the link between your Minecraft Endpoints and the Connect Network. -> [Go to Available Connectors](/guide/connectors/#available-connectors) ## Step 2: Launch your Connector Follow the guide of the Connector you chose to install and launch it. The first time the Connector is launched, the Endpoint will be protected with a token, that you can reset in the Dashboard at any time. -> If you face serious issues [get help](#getting-help) in the Discord. ## Done! Your Minecraft server is now protected by the Connect Network and players can join it at `.play.minekube.net`! Java and Bedrock players use the same endpoint address. Bedrock support is handled by the Connect edge for Connect-routed players, so Paper/Spigot, Velocity, and BungeeCord plugin users do not need to install Geyser or change Gate Bedrock settings. ::: info What works with the normal setup * Authenticated Java players can join. * Microsoft/Xbox-authenticated Bedrock players can join with or without a linked Java account. * Offline/cracked Java players require the endpoint owner to opt in. * Bedrock players without valid Microsoft/Xbox authentication cannot join the managed Bedrock path. See [Joining Servers](/guide/joining#who-can-join) for the complete address, port, identity, and configuration matrix. ::: **Next Steps:** Consider to import your Endpoints to the Connect Dashboard. ## Getting Help If you need help, join the Minekube Community Discord and post a support request in the **#support** forum. -> https://minekube.com/discord ::: tip Endpoint Token If you get an authentication error from the Watch service, check that the token your Connector uses still matches the token stored for this endpoint in the Dashboard. Resetting the token in the Dashboard invalidates the previous token immediately, so a Connector that keeps using the old one keeps failing with the same error until you place the new token and restart it. The token belongs in the Connector's **token file**, never in the Connector config that holds the endpoint *name*: the [Gate connector](/guide/connectors/gate) reads `connect.json` next to its config, the [Java Plugin](/guide/connectors/plugin#endpoint-token) reads `token.json` in its data directory, and both accept the `CONNECT_TOKEN` environment variable, which takes precedence over the file. Copy the token byte-for-byte: a trailing space or newline is a different token. If the endpoint name belongs to an organization, the token must have been created for this endpoint name inside that organization. A token from another organization, or for a different endpoint name, is rejected with the same error and cannot take the name over; if the name is not yours, choose a different endpoint name. ::: --- --- url: https://connect.minekube.com/guide/connectors.md --- # Connectors Overview Learn about Connectors, their function, and available options here. ## What is a Connector? A Connector at Minekube Connect is a software component that facilitates the secure communication between your Minecraft server/proxy and the Connect Edge Network by creating secure outbound tunnels for receiving player connections. ## Available Connectors **[Gate Connector](gate.md):** Recommended * Enable `connect` mode in the configuration to use it as a Connector for your server. Gate is updated most frequently and has the most capabilities. * Connect-routed Bedrock players are translated by the Connect edge before they reach your connector. Enable local Gate Bedrock only when Bedrock players should connect directly to your self-hosted Gate address. * If you have an existing Java proxy, switch to [Gate Lite mode](gate.md#gate-lite-mode) to use it as a Connector without installing the Connect Java Plugin. -> Continue with [Gate Connector Setup Guide](gate.md) **[Java Plugin](plugin.md):** Fast set-up * The Spigot/Velocity/Bungee Connect Plugin can be installed on your Minecraft server/proxy to use it as a Connector for your endpoints. * Bedrock players can join these connected endpoints through the same Connect addresses. No Geyser plugin or extra Bedrock proxy is required for the Connect-routed path. -> Continue wit [Java Plugin Setup Guide](plugin.md) ## Advantages using a Connector * You want to protect and hide your public IP address from attackers? Use a Connector. * You don't have a public IP address, like running your server on a private network or at home? Use a Connector. ### Anycast Public IP In any case, Connect gives your endpoints a shared public Anycast IP address reachable from anywhere to route your player traffic through the nearest Connect Edge region to your Minecraft server. ## How does a Connector work? To better understand how a Connector works, let's consider an example. Imagine a player named Alex from the US wants to join a Minecraft server running in Singapore. 1. **Initial Connection to Nearest Edge**: Alex's request to join the server first reaches the closest Connect Edge, located in Ashburn, for example. This step ensures Alex's connection benefits from an efficient data center network infrastructure, offering faster routing compared to a potentially slower ISP route. This optimized network path reduces latency from the outset. 2. **Session Proposal to Connector**: The Edge in Ashburn then sends a session proposal to the Connector that's associated with the target server endpoint in Singapore. 3. **Connector Connects to Local Edge**: Upon receiving the proposal, the Connector in Singapore connects to its own nearest Connect Edge in Singapore. This local Edge connection optimizes latency by ensuring server outbound connections use the most efficient network paths. 4. **Secure Tunnel Established Through Both Edges**: A secure tunnel is created from the Connector in Singapore to Alex through both the Singapore and Ashburn Edges. This tunnel ensures Alex's connection to the Minecraft server is secure and efficient, minimizing latency and enhancing the gaming experience. This process, utilizing both local and player-nearby Edge servers, ensures a high-quality connection for players globally, effectively reducing latency and securing the data path. ![https://mermaid.live/edit#pako:eNptkj1vgzAQhv-K5TksjAws\_diqVkpHlqt9Sq2Gs3u2W0VR\_nsNF0yqwMCHee78vHBnbbxF3emI3xnJ4KODA8M4kCpHAE7OuACU1NsRTsj360\_2gAqiXB3YbaKtSHR0jzx4IjTJb\_TfI\_8gz-Vkg3eUhBGfpu-nrt3SQSWvCIHnvQSU8\_R8hduuNCWrIsboPKnAPvgIxxVsC1mVOvXs-Rd4q0BKKto0vehWn4ILs5qsdNV5zenD56KUcnl3lARYE4hSc036Loy52eAmYtPLh\_lvoHd6RB7B2fKrzxM-6PSJIw66K7cW-GvQA10KBzn5\_YmM7hJn3OkcLKRlLJZFtK4EeJHRmSfo8gc8E8Vk](diagram.svg) ::: info When the Player and Connector are in the same region Note that if both the Player and Connector are in the same region, they will likely be routed to the same Edge, thus the Connector will create the Tunnel directly to the Edge the Player is connected. Only one Edge would be involved in the diagram. ::: -> Why all that? Checkout [Connect Tunnels](/guide/tunnels) explained! ## Load Balancing multiple Connectors You can run multiple Connectors for the same endpoint to load balance the player traffic between them. The Connect Edge will automatically distribute the player traffic between the available endpoint's Connectors randomly. ::: tip Regional Load Balancing Note that the Connect Edge will **currently** not take into account the accurate load or regional latency of the Connectors when distributing the player connections. If you want this behavior, let us know in our [Discord](https://minekube.com/discord)! ::: --- --- url: https://connect.minekube.com/guide/connectors/gate.md --- # Gate Proxy - Connector Guide Using Gate as a Connector for your Minecraft server or proxy. It is the best supported, most frequently updated Connector with the most capabilities. -> If you haven't already, checkout [Gate's Quick Start](https://gate.minekube.com/guide/quick-start) first, it's just a tiny binary. ## Enable Connect in Gate configuration First of all, in the Gate configuration, you: 1. enable Connect mode 2. choose your endpoint name -> See [Enabling Connect](https://gate.minekube.com/guide/connect) page for how to do it. ## Gate (standard) For an introduction to Gate, see [Gate Docs](https://gate.minekube.com/guide). As one of the most capable open source Minecraft proxy in the world, Gate has first class support for Connect with online-mode. Connect-routed Bedrock players are translated by the Connect edge before they reach your Gate connector. You do not need `bedrock: true` in your Gate config for that path. Enable `bedrock: true` only when Bedrock players should connect directly to your self-hosted Gate instance instead of through a Connect address. -> To customize Gate checkout the [starter plugin template](https://github.com/minekube/gate-plugin-template) ## Gate Lite Mode For an introduction to Gate Lite mode, see [Gate Lite Docs](https://gate.minekube.com/guide/lite). Gate Lite remains a thin Java protocol reverse proxy. It can sit behind Connect as a connector for Java traffic, while Connect-routed Bedrock translation happens at the Connect edge. Use standard Gate, not Gate Lite, if you want your own direct Bedrock listener. ### Current behavior In Lite mode, Gate does not terminate a player login as a full Minecraft proxy. It reads enough of the Java protocol to select a backend route, then forwards the connection, including ping and player authentication, to that backend. When Gate Lite is used behind Connect, the Connect edge is still the public ingress point. Gate Lite only sees the connection that Connect forwards to your connector and then pipes it to the selected backend route. This works well when the target behind Lite does not need to run its own Mojang online-mode login for Connect-routed players. For example, Lite can route to an offline-mode backend, or to a proxy/server setup that is already designed to trust the connector path you configured. ### Not supported today `Connect -> Gate Lite -> Online Mode Backend` That topology is not supported today by changing Gate Lite configuration alone. Gate Lite forwards the backend's authentication flow; it does not translate Connect's edge-authenticated player session into a backend online-mode session. Connect's [AuthSession API](../auth-api) and passthrough support are still unavailable, so an online-mode Velocity, Paper, Waterfall, or similar backend behind Gate Lite should not be expected to accept Connect-routed players through AuthSession yet. If you need online-mode players through Connect today, use standard Gate with Connect enabled or the Connect Java Plugin on a supported server/proxy. Use Gate Lite behind Connect only when the backend auth model is compatible with a thin reverse-proxy hop. ## Example Setups Minekube Connect advances the way players connect and developers architect secure Minecraft servers and networks. Let's take a look at some common example setups. ### #1 Example: Online mode Velocity `Connect -> [ Gate Lite -> [ Velocity -> Papers ] ]` ::: danger Not supported today This example depends on Connect passthrough/AuthSession support for Lite backend routes. That support is not available yet. Use standard Gate with Connect enabled, or install the Connect Java Plugin on Velocity, for online-mode Velocity behind Connect. ::: > We could only use Gate -> Paper without Velocity, but this topology would be useful for existing Velocity networks > after Connect passthrough/AuthSession support exists. * We have Velocity in online mode running on `localhost:25577` and want to use Connect through Gate. * Because Velocity is a proxy itself, we need to use Gate Lite mode for simple reverse proxying. * We enable `lite` in Gate config and add a wildcard route `*` to forward all traffic to Velocity at `localhost:25577`. * We enable `connect` mode in Gate config and choose a name for our endpoint. * This will require Connect passthrough/AuthSession support before online-mode players can join reliably through Lite. > Velocity here could have been replaced by another proxy like BungeeCord/Waterfall or even Gate standard > (reduce Gate layers: try to set up Example #2 instead). ### #2 Example: Paper online or offline `Connect -> [ Gate -> Papers ]` * We have Paper in online or offline mode running on `localhost:25565` and want to use Connect through Gate. * This time we chose to not enable `lite` mode in Gate config, because we want to use Gate's full proxying capabilities like switching servers with `/server` * We enable `connect` mode in Gate config and choose a name for our endpoint. * Done! We can now join to our Paper server at `.play.minekube.net` and online mode players from Connect Network can join as well thanks to Gate's first class Connect online-mode support. All without using port forwarding nor the [~~Java Plugi~~n](plugin.md) nor the [~~AuthSession API~~](../auth-api). ## Getting Support If you have any questions or need help, simply post a support request in the Minekube Community Discord forum!. https://minekube.com/discord --- --- url: https://connect.minekube.com/guide/connectors/plugin.md --- # Java Plugin - Connector Guide Using the Connect Java Plugin as a Connector for your Minecraft server or proxy. If you have a Minecraft Java server or proxy, this the most convenient Connector for you, but it is not as capable as the [Gate Proxy Connector](gate.md) in terms of routing features and performance. The Connect Plugin is a powerful multi-platform Minecraft plugin that tunnels your players through the global [Connect Network](#the-connect-network) to your Minecraft server/proxy. -> It supports PaperMC, BungeeCord and Velocity platforms. ## Downloading the Connect Plugin The installation steps are the same as for every other Minecraft plugin *(Download jar, put in plugins folder, start server)*. Download the Connect plugin right here! | Spigot/PaperMC Plugin | Velocity Plugin | BungeeCord Plugin | |------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------| | [connect-spigot.jar](https://github.com/minekube/connect-java/releases/download/latest/connect-spigot.jar) | [connect-velocity.jar](https://github.com/minekube/connect-java/releases/download/latest/connect-velocity.jar) | [connect-bungee.jar](https://github.com/minekube/connect-java/releases/download/latest/connect-bungee.jar) | Ready to experience Minekube Connect? Download the latest stable release for your platform! :point\_up\_2: ![Console showing public domain](/images/terminal-log.png) ## Disabling "enforce secure player profiles" Required Since Minecraft 1.19 the `enforce-secure-profile` property was introduced. Players joining through the [Connect Network](/guide/#the-connect-network) to your server won't be able to join if this setting is enabled. It is safe to disable this setting as it only affects chat messages. ::: code-group ```properties [server.properties Spigot/PaperMC] enforce-secure-profile=false # If you disable online-mode, then enforce-secure-profile has no effect online-mode=true ``` ```toml [velocity.toml Velocity] force-key-authentication = false # If you disable online-mode, then force-key-authentication has no effect online-mode = true ``` ```yaml [config.yml BungeeCord] enforce_secure_profile=false # If you disable online-mode, then enforce-secure-profile has no effect online_mode=true ``` ::: ## Joining your Server Every server has a unique configurable [Endpoint](/guide/#connect-endpoints) name that directly reflects the domain players can join the server with. If you leave this field empty, Connect will use a temporary random endpoint name for your server provided by the [Random Name Service](https://randomname.minekube.net/). You can always update that endpoint name in the config: ::: code-group ```yaml [plugins/connect/config.yml] endpoint: your-server-name ``` ```yaml [Gate config.yml] connect: name: your-server-name ``` ::: > The environment variable `CONNECT_ENDPOINT` takes precedence over the configuration file. ### Joining with free provided Public Domain After installing Connect plugin and starting your server you will see the [free public domain](/guide/domains) for your server that looks like `.play.minekube.net`. ::: code-group ```shell [Server Console] [connect] Enabling connect vX.Y.Z [connect] Enpoint name: live-beru [connect] Your public address: live-beru.play.minekube.net ``` ::: Use that same endpoint hostname in either edition: | Client | Server address | Port | | --- | --- | --- | | Java Edition | `.play.minekube.net` | `25565` (normally omitted) | | Bedrock Edition | `.play.minekube.net` | `19132` | Verified custom domains work the same way: Java and Bedrock use the same hostname and their edition's normal port. ![Console showing public domain](/images/terminal-log.png) Ping requests are also mirrored to the endpoint server. ### Joining from Browser Hub Players can also discover your server from the in-game [Browser Hub](/guide/advertising#browser-hub) at `minekube.net` and can join with the in-game UIs or with the `/browser join ` command. Offline/cracked Java players use `cracked.minekube.net` or `cracked.minekube.com` instead and can only enter endpoints that explicitly allow them. See [Who Can Join](/guide/joining#who-can-join) for the Java, Bedrock, account-linking, and offline-mode identity matrix. ## Example Setups Minekube Connect advances the way players connect and developers architect secure Minecraft servers and networks. Let's take a look at some common example setups. ### #1 Example: Velocity `Connect -> [ Velocity -> Papers ]` * We have Velocity in online mode running on `localhost:25577` and want to use Connect. * We install the Connect plugin to Velocity's `plugins` folder. * We choose a name for our endpoint in the Connect plugin config `plugins/connect/config.yml`. * We start Velocity and Connect Plugin will automatically tunnel players from the Connect Network. * Done! We can now join our Velocity server at `.play.minekube.net`. Online mode players from Connect Network can join thanks to Plugins's auth session injection mechanisms. ### #2 Example: Paper `Connect -> Paper` * We have Paper running on `localhost:25565` and want to use Connect. * We install the Connect plugin to Paper's `plugins` folder. * We choose a name for our endpoint in the Connect plugin config `plugins/connect/config.yml`. * We start Paper and Connect Plugin will automatically tunnel players from the Connect Network. * Done! We can now join our Paper server at `.play.minekube.net`. Online mode players from Connect Network can join thanks to Plugin's auth session injection mechanisms. ### #3 Example: Connect `passthrough` + AuthSession API Passthrough mode and AuthSession API are Coming soon. This is not required for the normal Connect Java Plugin setup shown above. The plugin integrates with Connect's current auth/session handling on supported platforms. Passthrough/AuthSession is planned for setups where the backend or proxy needs to run its own online-mode authentication for Connect-routed players. That includes topologies such as `Connect -> Gate Lite -> online-mode backend`, which are not supported today through Gate Lite configuration alone. ## Endpoint Token The endpoint **name** is what you set in `plugins/connect/config.yml`. The endpoint **token** does not belong there: the plugin reads it from `token.json` in the plugin's data directory (for example `plugins/connect/token.json`) or from the `CONNECT_TOKEN` environment variable, which takes precedence over the file. On first launch the plugin generates a token and saves it to `token.json`. * Resetting the token in the Dashboard invalidates the previous token. Copy the new token byte-for-byte into `token.json` (a trailing space or newline is a different token) or set `CONNECT_TOKEN`, then restart the server or proxy. * A Watch service authentication error (`the endpoint token ... does not match the token currently stored for this endpoint`) always reports this token mismatch, not a dashboard problem. If the endpoint name belongs to an organization, the token must have been created for this endpoint name inside that organization; a token from another organization, or for a different endpoint name, cannot take the name over. If the name is not yours, choose a different endpoint name. ## Bedrock Identity Connect-managed Bedrock is handled at the Connect edge. The plugin can verify the Bedrock identity that Connect already checked before forwarding the player to Paper, Velocity, or BungeeCord. Current plugin releases supply compatible identity defaults automatically, including for older configuration files that omit the legacy identity section. For the managed Connect service, install or update the plugin and keep its defaults. No identity URLs, public keys, or capability settings are required. Explicit operator overrides are preserved. The endpoint policy accepts Microsoft/Xbox-authenticated Bedrock players without a linked Java account by default. Connector identity settings verify what the edge forwarded; they cannot change an edge rejection such as `policy_linked_java_only`. See the [Bedrock support guide](/guide/bedrock#bedrock-identity-enforcement) for the current defaults, rejection reasons, and support checklist. --- --- url: https://connect.minekube.com/guide/auth-api.md --- # AuthSession API Coming soon > This feature is currently unavailable. > You can view a draft of the custom Mojang AuthSession API here: https://github.com/minekube/mojang-multiauth. > For support requests, join our Discord community. https://minekube.com/discord This page explains the planned Connect AuthSession API and what it does not support today. ::: info Requirements -> Requires a public IP address -> Only useful if you want to use Connect with online mode players. ::: ## Current Status The AuthSession API is not available in production yet. The example commands on this page are placeholders and should not be used as working setup instructions. Today, Connect supports online-mode players through connectors that integrate with Connect's current auth/session handling, such as standard Gate with Connect enabled or the Connect Java Plugin on supported platforms. Gate Lite behind Connect is different: Lite mode is a thin Java protocol reverse proxy. It forwards ping and player authentication to the selected backend route instead of acting as a full proxy that can translate Connect's edge-authenticated session into a backend online-mode login. Because AuthSession and Connect passthrough support are not available yet, the following topology is not supported by Gate Lite configuration alone: `Connect -> Gate Lite -> Online Mode Backend` Use standard Gate with Connect enabled or the Connect Java Plugin when you need online-mode players through Connect today. Use Gate Lite behind Connect only when the backend auth model is compatible with a thin reverse-proxy hop. ## How it Works The planned Connect AuthSession API is an adaptation of the Mojang AuthSession API. It is intended to securely authenticate online-mode players from the Connect Network to your server/proxy. The API distributes Mojang Sessionserver's "hasJoined" requests from online mode servers/proxies possibly behind Minekube Connect, Minehut Network, and regular Mojang. ## Using Connect AuthSession API The following examples are not active setup instructions yet. They show the type of configuration that may be needed once AuthSession support is released. ### Velocity ::: code-group ```shell [Terminal] java -Dmojang.sessionserver=[MINEKUBE AUTHSESSION API COMING SOON] -jar velocity.jar ``` ::: #### Gate TBD. Standard Gate has first-class Connect support today. Gate Lite backend-route AuthSession/passthrough support is not available yet. #### Waterfall ::: code-group ```shell [Terminal] java -Dwaterfall.auth.url="[MINEKUBE AUTHSESSION API COMING SOON]?username=%s&serverId=%s%s" -jar waterfall.jar ``` ::: #### Paper > Note: These instructions only apply if you are running Paper standalone and **NOT** under a proxy. > If you are using Gate, Velocity, Waterfall, or Lilypad, you should have already configured this, and you can safely skip > this section. Add the following CLI flags to your start script: ```shell -Dminecraft.api.auth.host=[MINEKUBE AUTHSESSION API COMING SOON] -Dminecraft.api.account.host=[MINEKUBE AUTHSESSION API COMING SOON] -Dminecraft.api.services.host=[MINEKUBE AUTHSESSION API COMING SOON] -Dminecraft.api.session.host=[MINEKUBE AUTHSESSION API COMING SOON] ``` When you are done, your script may look something like the following: ::: code-group ```shell [Terminal] java -Dminecraft.api.auth.host=[MINEKUBE AUTHSESSION API COMING SOON] \ -Dminecraft.api.account.host=[MINEKUBE AUTHSESSION API COMING SOON] \ -Dminecraft.api.services.host=[MINEKUBE AUTHSESSION API COMING SOON] \ -Dminecraft.api.session.host=[MINEKUBE AUTHSESSION API COMING SOON] \ -jar paper.jar ``` ::: In addition, ensure that you have set `enforce-secure-profile` to `false` in your [server.properties](http://server.properties) file. #### Lilypad Set the following environment variable: `LILYPAD_MOJANG_SESSIONSERVER_URL` to `[MINEKUBE AUTHSESSION API COMING SOON]` #### BungeeCord This proxy type is currently not supported due to [an issue in BungeeCord](https://github.com/SpigotMC/BungeeCord/pull/3201); please use Gate, Velocity or Waterfall instead. ## Compatibility Only the listed software allows changing the Mojang AuthSession API url. Bungeecord is not supported. --- --- url: https://connect.minekube.com/guide/joining.md description: >- Addresses, ports, and authentication behavior for Java, Bedrock, and offline Java players using Connect. --- # How to join your Connect Server ## Joining your Server Every server has a unique configurable [Endpoint](/guide/#connect-endpoints) name that directly reflects the domain players can join the server with. If you leave this field empty, Connect will use a temporary random endpoint name for your server provided by the [Random Name Service](https://randomname.minekube.net/). You can always update that endpoint name in the config: ::: code-group ```yaml [plugins/connect/config.yml] endpoint: your-server-name ``` ```yaml [Gate config.yml] connect: name: your-server-name ``` ::: > The environment variable `CONNECT_ENDPOINT` takes precedence over the configuration file. ### Joining with free provided Public Domain After installing Connect plugin and starting your server you will see the [free public domain](/guide/domains) for your server that looks like `.play.minekube.net`. ::: code-group ```shell [Server Console] [connect] Enabling connect vX.Y.Z [connect] Enpoint name: live-beru [connect] Your public address: live-beru.play.minekube.net ``` ::: Use that same endpoint hostname in either edition: | Client | Server address | Port | | --- | --- | --- | | Java Edition | `.play.minekube.net` | `25565` (normally omitted) | | Bedrock Edition | `.play.minekube.net` | `19132` | Verified custom domains work the same way: Java and Bedrock use the same hostname and their edition's normal port. ![Console showing public domain](/images/terminal-log.png) Ping requests are also mirrored to the endpoint server. ### Joining from Browser Hub Players can also discover your server from the in-game [Browser Hub](/guide/advertising#browser-hub) at `minekube.net` and can join with the in-game UIs or with the `/browser join ` command. Offline/cracked Java players use `cracked.minekube.net` or `cracked.minekube.com` instead and can only enter endpoints that explicitly allow them. See [Who Can Join](/guide/joining#who-can-join) for the Java, Bedrock, account-linking, and offline-mode identity matrix. ## Who Can Join This matrix applies when players use a Connect address and the server owner runs a normal Connect plugin or standard Gate connector: | Player identity | Accepted by default | Identity used by the endpoint | Server-owner action | | --- | --- | --- | --- | | Java client authenticated with a Java Edition account | Yes | Verified Java UUID and profile | None beyond the normal Connect setup | | Bedrock client authenticated with Microsoft/Xbox and authoritatively linked to Java | Yes | Linked Java UUID and profile | None | | Bedrock client authenticated with Microsoft/Xbox but not linked to Java | Yes | [Stable native Bedrock/XUID-derived profile](/guide/bedrock#what-a-bedrock-player-looks-like-at-your-backend) | None | | Offline/cracked Java client | No | Self-asserted offline Java name and UUID | Explicitly [allow offline-mode players](/guide/offline-mode#allowing-offline-java-on-an-endpoint) | | Bedrock client without valid Microsoft/Xbox authentication | No | None; Connect rejects the session | Unsupported on Connect-managed Bedrock | Account linking is optional for Connect-managed Bedrock. When Connect can verify an authoritative Java link, it preserves that Java identity; otherwise, the player's verified Xbox identity is enough. A backend plugin that is specifically written to require a premium Java UUID can still reject a native Bedrock profile, so diagnose that plugin rather than enabling offline mode or installing another Geyser instance. ## What the Server Owner Configures For authenticated Java and Microsoft/Xbox-authenticated Bedrock players, configure only the normal Connect connector. Connect handles Bedrock translation at the edge. Do not install backend Geyser or Floodgate, open a backend UDP port, or set Gate `bedrock: true` for Connect-routed players. Offline/cracked Java is a separate, explicit opt-in. The [Offline Mode guide](/guide/offline-mode) shows the setting for both the Connect Java Plugin and Gate. --- --- url: https://connect.minekube.com/guide/bedrock.md description: >- Let Microsoft/Xbox-authenticated Bedrock players join Connect endpoints with or without a linked Java account. --- # Bedrock Support Connect lets Bedrock players join connected endpoints through the same public addresses Java players already use: * `.play.minekube.net` * custom domains attached to the endpoint * endpoint routing through the Connect network For Connect-routed players, Bedrock translation is handled by the Connect edge before traffic reaches your connector. That means the usual Connect setup stays the same for Paper/Spigot, Velocity, BungeeCord, and Gate connectors. ::: tip Managed default Microsoft/Xbox-authenticated Bedrock players can join Connect endpoints without owning or linking Java Edition. If an authoritative Java link exists, Connect preserves the linked Java profile; otherwise it uses the player's verified native Bedrock/XUID identity. No Bedrock-specific server configuration is required. ::: ## Support Behavior Matrix | Setup | What to configure | Bedrock translation | Backend Floodgate API | Online-mode and account behavior | Custom domain coexistence | | --- | --- | --- | --- | --- | --- | | Connect-managed Bedrock with Paper/Velocity/Bungee connector | Install the Connect plugin normally. Do not enable backend Gate `bedrock: true` for Connect-managed Bedrock. | Connect edge | Supported only for the compatibility data Connect forwards. If a plugin expects a local Floodgate/Geyser runtime, collect logs and plugin names. | Java online-mode stays on the Java path. Microsoft/Xbox-authenticated Bedrock players do not need a linked Java account by default. | Supported. Bedrock and Java can use the same endpoint subdomain or custom domain. | | Connect-managed Bedrock with standard Gate `connect` enabled | Enable the Gate Connect connector normally. Do not add local Bedrock settings only for Connect players. | Connect edge | Same Connect-managed compatibility behavior as plugin connectors. | Microsoft/Xbox-authenticated Bedrock players do not need a linked Java account by default. Do not switch the backend to offline mode only for Bedrock. | Supported. Connect addresses and custom domains stay shared. | | self-hosted Gate direct Bedrock | Add `bedrock: true` to the standard Gate instance that Bedrock clients join directly. | Your Gate instance | Local Gate/Floodgate behavior belongs to that Gate setup, not Connect-managed Bedrock. | Follow Gate's direct Bedrock and account-linking requirements. | Use a separate direct Bedrock hostname or port unless you intentionally route that hostname outside Connect. | | Standard Gate with both Connect and direct Bedrock | Enable Connect for Connect addresses and `bedrock: true` only for the separate direct Bedrock listener. | Connect edge for Connect addresses, Gate for the direct Bedrock address | Diagnose by join address. Connect-managed joins use Connect compatibility data; direct joins use local Gate behavior. | Ask which address the player used before changing online-mode or linking settings. | Supported when DNS clearly separates Connect-routed names from direct Gate names. | | Gate Lite behind Connect | Configure Gate Lite as a Java connector behind Connect. | Connect edge | Treat backend Floodgate API reports as Connect-managed compatibility reports. | Gate Lite is not the direct Bedrock authority; keep auth decisions in the backend/proxy path. | Supported for Connect-routed endpoint domains. | | Gate Lite as a direct Bedrock listener | Use standard Gate instead. | Not supported in Gate Lite | Not supported. | Not supported. | Not supported. | ## Connect-Routed Bedrock Use this path when players join through Connect addresses such as `.play.minekube.net`, `minekube.net`, or a custom domain attached to your endpoint. For Bedrock clients, add the same Connect hostname as the server address and use the normal Bedrock port `19132`. For example: * **Server Address:** `.play.minekube.net` * **Port:** `19132` If you attached a custom domain to the endpoint, Bedrock players can use that custom domain with port `19132` too. This is a player-facing Connect edge port. It does not mean you need to open UDP `19132` on your home network, VPS, backend server, or connector host. You do not need to: * install Geyser on your backend * install Floodgate on your backend * open a local UDP Bedrock port * set `bedrock: true` in your backend Gate just for Connect players This applies to the Connect Java plugin and to Gate used as a Connect connector. Do not enable backend Gate `bedrock: true` for Connect-managed Bedrock. That setting is for self-hosted Gate direct Bedrock listeners and can create a second Bedrock path that support then has to diagnose separately. ## Direct Self-Hosted Gate Bedrock Use this path when Bedrock players connect directly to a Gate address you operate yourself, outside the Connect network. In that case, standard Gate can manage Bedrock locally: ```yaml bedrock: true ``` With that setting, Gate starts and manages the Bedrock translation runtime for direct Bedrock clients. This local setting does not change how Connect-routed Bedrock players are handled. ## Domains Connect domains are shared by Java and Bedrock players. If a custom domain already routes Java players to your endpoint, Bedrock players use the same domain after it is attached to the endpoint in the dashboard. Java clients normally use the Java port `25565`; Bedrock clients normally use the Bedrock port `19132`. Use a separate direct Bedrock address only when you intentionally run local Bedrock support on your own standard Gate instance. ## Account Linking and Online Mode Connect-routed Bedrock players arrive through the managed Bedrock path and are represented through the compatibility layer before they reach your connector. The default endpoint policy accepts a Microsoft/Xbox-authenticated Bedrock identity without requiring a linked Java Edition account. This is separate from generic offline-mode Java access. * With an authoritative account link, the endpoint receives the linked Java identity. * Without a link, the endpoint receives a stable profile derived from the verified Bedrock XUID. * Without valid Microsoft/Xbox authentication, the managed Bedrock session is rejected. See the complete [player identity matrix](/guide/joining#who-can-join) for the corresponding Java and offline-Java paths. The exact rejection reason identifies the component that needs attention: * `policy_linked_java_only` means the endpoint has an explicit linked-Java-only policy override. Connector settings such as `bedrock-identity.enforcement` cannot change this edge policy. Include the endpoint name when asking Minekube support to review an unexpected override. * `scope_unavailable` means Connect cannot resolve a usable endpoint/organization identity scope. Reinstalling Geyser or changing backend online mode will not repair endpoint ownership. * `capability_unavailable` means the selected connector did not prove the required Bedrock identity capability. Update to a compatible connector build. Identity keys, URLs, and capability settings are automatic for the managed service; changing backend authentication does not repair a missing connector capability. If you are troubleshooting online-mode behavior, first identify whether the player joined through a Connect address or a direct self-hosted Gate Bedrock address. The required configuration is different for those two paths. Keep online-mode decisions tied to the whole Java forwarding topology. A Connect-managed Bedrock report is not, by itself, a reason to disable online-mode or allow offline-mode players on the backend. Connect-managed Bedrock identity uses official Microsoft/Xbox Bedrock authentication at the Connect edge. It is not a Minekube password system, it is not backend Geyser authentication, and it is not the same thing as allowing generic offline-mode Java players. The connector can enforce the Bedrock identity that Connect already verified, while Java online-mode players continue to use the normal Java session path. ## Bedrock Identity Enforcement For Connect-routed Bedrock, the Connect edge verifies the player's Microsoft/Xbox Bedrock identity and signs a short-lived identity envelope before forwarding the session to your connector. Gate verifies this envelope before opening the player tunnel. The Connect Java Plugin also provides a verifier for the managed handover. Gate checks the signature, expiry, endpoint and organization scope, session binding, and replay protection before admitting the Bedrock identity. Minekube publishes the current and previous verification keys for automatic key rotation. These are public verification keys; private signing keys stay at the Connect edge. For the normal managed service, install or update your connector and keep its defaults. You do not need to configure identity URLs, copy keys, or declare capabilities. Current Connect Java releases also supply the legacy identity defaults when that section is absent from an older configuration file. Explicit identity overrides remain operator-controlled. ::: warning Gate version compatibility Gate v0.74.28 and earlier do not include automatic verification of the managed v1 Bedrock handover. Upgrade to [Gate v0.74.29 or later](https://github.com/minekube/gate/releases/tag/v0.74.29) for automatic Connect Bedrock identity support. Keep the normal Connect configuration and enable Bedrock on your Connect endpoint; no identity settings are needed. Configuring v2 identity keys on an older Gate build does not make it compatible with the managed v1 handover. ::: Custom Watch services and explicit signed-principal v2 deployments use their own trust configuration. See the [Connect Java identity reference](https://github.com/minekube/connect-java/blob/main/docs/bedrock-identity.md) for those advanced deployments. They are separate from the normal managed setup. ## What a Bedrock player looks like at your backend A Connect-managed Bedrock player has no Java Edition account, so the endpoint receives a profile that Connect derives from the player's verified Xbox identity. Both parts have a fixed shape for every unlinked Bedrock player, and both are intentional: * **Username:** `_`. The Connect edge applies the configured Bedrock username prefix `.` to the gamertag, and Connect normalizes the result into `[A-Za-z0-9_]`, capped at 16 characters, so that every backend implementation accepts the login name. That is why the prefix reaches your backend as `_`, and why every space or non-ASCII character in the gamertag is encoded to `_` as well. A gamertag like `icedRyan` appears as `_icedRyan`, and `.LLG icedRyan` appears as `_LLG_icedRyan`. The Java account alphabet is the narrower `[A-Za-z0-9_]`, but what constrains a proxy-supplied login name is the backend server's own validation, not one Java-wide rule: Paper's check also accepts `.` and rejects spaces, while vanilla's check is only the `[A-Za-z0-9_]` alphabet, and both cap the name at 16 characters. Connect normalizes into the vanilla alphabet because it cannot know which implementation a backend runs, so the `.` prefix is not a way to hand a dot to a backend that validates names the vanilla way. * **UUID:** a stable RFC 4122 version-5 UUID derived from the verified Bedrock XUID (the established XUID namespace, SHA-1 hashed with the version-5 and variant bits applied). It deliberately does not look like a Mojang UUID, so a version-5 value such as `xxxxxxxx-xxxx-5xxx-yxxx-xxxxxxxxxxxx` is the normal form and not a defect. The same XUID always produces the same UUID, so bans, permissions, economy entries, and other UUID-keyed data stay attached to the same player on every reconnect and on every endpoint. Two properties of that UUID matter when you are debugging: * It is an identifier, not a secret and not a signature. Seeing it in logs is expected. * Do not rewrite it. Connect checks the profile UUID of the Bedrock session against the XUID-derived value before it hands the signed Bedrock identity to your connector, so a component that substitutes a different UUID makes Connect reject the session instead of fixing anything. No action is required for either value. If a backend plugin rejects the player because the username or UUID is not a Mojang one, that plugin is the thing to adjust. Rewriting the UUID or switching the backend to offline mode does not make a Connect-managed Bedrock join produce a Mojang identity. ### Floodgate's `00000000-0000-0000-XUID` key is a different identifier Geyser and Floodgate identify a Bedrock connection with a second value: the XUID placed in the low 64 bits of an otherwise zero UUID, conventionally written `00000000-0000-0000-XUID`. That value belongs to a local Geyser + Floodgate runtime. A Connect-managed join does not deliver it to your backend. This is why UUID-keyed data does not follow a player from a plain Geyser + Floodgate setup into Connect on the first join. Both identifiers are stable and both come from the same verified XUID, but they are different values, and no Connect setting renames one into the other. ## Backend Floodgate API Compatibility Some backend plugins query Floodgate-style player metadata to decide whether a player is from Bedrock, linked to Java, or allowed past a login step. Connect-managed Bedrock forwards compatibility data for supported paths, but servers can still fail when a plugin assumes it is talking to a local Floodgate/Geyser installation. When Floodgate-dependent behavior fails, ask for: * the exact join address the Bedrock player used * connector type and version * backend server type and version * Floodgate, Geyser, auth, or login plugin names and versions * the kick text and logs from Connect, the connector, proxy, and backend around the same timestamp * whether the same player succeeds through a direct self-hosted Gate Bedrock address, if one exists * whether `bedrock-identity.enforcement` is `disabled`, `warn`, or `require` * Bedrock identity warnings such as missing envelope, invalid signature, expired identity, replayed nonce, policy mismatch, endpoint mismatch, or organization mismatch Do not recommend installing backend Geyser/Floodgate or enabling Gate `bedrock: true` unless the user wants to operate a separate self-hosted Gate direct Bedrock path. Do not ask users to paste signed Bedrock identity envelopes, private keys, account tokens, or full player profile dumps into public support channels. The useful support data is the join address, connector version, endpoint ownership, relevant timestamps, sanitized logs, and the exact rejection reason. ## Discord support response draft > Connect-managed Bedrock is separate from self-hosted Gate Bedrock. If your player joins through > `.play.minekube.net`, `minekube.net`, or a custom domain attached to the endpoint, Bedrock clients should use > that hostname with port `19132`. Do not install backend Geyser/Floodgate, open local UDP `19132`, or enable backend Gate > `bedrock: true` just for that player. Connect handles Bedrock translation at the edge. If a Floodgate-dependent plugin > rejects the player, send the join hostname, connector type/version, backend type/version, Floodgate/Geyser/auth plugin > versions, the exact kick text, and logs from the Connect connector/proxy/backend at the same timestamp. Only use > `bedrock: true` when Bedrock clients connect directly to your own standard Gate instance outside Connect. Unlinked > Bedrock accounts are accepted by the default Connect endpoint policy; if the kick reason is > `policy_linked_java_only`, include the endpoint name so Minekube support can review its explicit policy override. --- --- url: https://connect.minekube.com/guide/localhost.md --- # Public Localhost Servers *Host Minecraft servers anywhere, even on your local PC, and make them publicly joinable.* ## Use Cases Running a localhost Minecraft server is awesome because it's free and quickly set up. * **Local Development** - Run your Minecraft server locally on your PC and test with friends. * **Local Multiplayer** - Play with friends beyond your local network without port forwarding. * **Local Hosting** - Host a Minecraft server on your local PC and make it publicly joinable. * **Local Testing** - Test your Minecraft server with players from all over the world. ## Why Connect for Public Localhost Servers? * You want to host a free Minecraft server without paying a provider. * You don't want to mess with your router settings and configure port forwarding. * Or, might not even have the admin password to your router. * You want to let players join from anywhere through the Internet. ## How does it work? The problem is only players in your local network can join. This is where Connect comes in and makes your localhost servers publicly joinable through the Internet. Yes! As soon as your server is started the Connect Plugin links with the Connect Network and players can start joining your Minecraft server even if it's running locally on your PC without configuring any port forwarding. Check out [About Tunnels](/guide/tunnels) for a technical explanation. ## Getting Started Check out the [Quick Start guide](/guide/quick-start) to learn how to get started with Connect. --- --- url: https://connect.minekube.com/guide/domains.md --- # Use a custom domain Always Free When you create a Connect Endpoint, it is automatically given a `play.minekube.net` sub-domain, based on the endpoint’s name. This is great for testing and private servers, but when you want to go to full production you’ll want your endpoint to appear on your own domain. That’s where the Connect custom domains comes in. Let’s set up the custom domain, first step: directing traffic to your endpoint. ## Set a CNAME record Option 1 The simplest option for directing traffic to your endpoint is to create a CNAME record for your custom domain that points at your `.play.minekube.net` host. For example, if you have a custom domain called `example.com` and an endpoint called `mcserver`, then you can create a CNAME record for `example.com`‘s DNS that would look like: ![cname.png](cname.png) If you want to make a subdomain like `mc`, set the `Name` to: `mc` You’ll need to configure this with your DNS provider. The example screenshot uses Cloudflare. Now, accessing `example.com` will tell the DNS system to look up `mcserver.play.minekube.net` and return its results. Java and Bedrock players can use the same verified custom domain. Connect-routed Bedrock translation happens at the Connect edge, so the domain still points at the same endpoint and does not need a separate Bedrock-only record. ## Or, set an SRV record Option 2 If you want to use an SRV record instead of a CNAME, you can do that too. Use an SRV record if you can’t use a CNAME record at the root of your domain anymore, because you have other records there (a website, for example). An SRV record for `example.com` would look like: ![srv.png](srv.png) If you want to make a subdomain like `mc`, append it like so in the `Name` field: `_minecraft._tcp.mc` ## Add your domain Do not forget! You'll need to go to the [Connect Dashboard](https://app.minekube.com) and add your domain to your endpoint. 1. Go to the endpoint you want to add a domain to 2. Click on `Custom Domains` 3. Click on `Add Domain` 4. Enter your domain ### Domain verification Your domain will be verified automatically when it detects the CNAME or SRV record set up previously. When you are done, you will be able to join your connected endpoint with your domain, within a few seconds. --- --- url: https://connect.minekube.com/guide/topologies.md --- # Forwarding and Topologies Connect can sit in front of many Minecraft server layouts. The important first step is to identify which address the player uses and which component is responsible for authentication, forwarding, and Bedrock translation. ## Choose the Right Path | Player address | Connector | Backend sees | Bedrock support | Use this when | | --- | --- | --- | --- | --- | | `.play.minekube.net`, `minekube.net`, or a Connect custom domain | Connect plugin on Paper, Spigot, Velocity, or BungeeCord | The server or proxy running the plugin | Managed by the Connect edge | You want the simplest managed Connect setup | | `.play.minekube.net`, `minekube.net`, or a Connect custom domain | Standard Gate with `connect` enabled | Your Gate instance, then its configured Java backends | Managed by the Connect edge for Connect-routed players | You already operate Gate and want Connect ingress | | A hostname or IP that points directly at your Gate instance | Standard Gate | Your Gate instance, then its configured Java backends | Gate handles it only when `bedrock: true` is enabled | You self-host Gate and want direct Bedrock clients outside Connect | | A TCPShield Java address plus a Connect Bedrock address | TCPShield for Java, Connect for Bedrock | Your backend may see two separate ingress paths | Connect handles Bedrock only on the Connect address | You intentionally keep Java and Bedrock ingress separate | | A public backend IP or port | None | Backend directly | Not managed by Connect | Development only, or a deliberate direct public setup | If the player joined through a Connect address, do not diagnose it as direct Gate Bedrock or direct backend traffic. ## Paper or Spigot With the Connect Plugin This is the smallest setup. Install the Connect plugin and let players join the endpoint name, `play.minekube.net` subdomain, or custom domain attached in the dashboard. Use this topology when: * the backend is a single Paper or Spigot server * you want Connect to manage public ingress * Bedrock players should join through the same Connect address as Java players Keep Paper `online-mode=true` unless you intentionally run an offline-mode server. If you allow offline-mode players, use the Connect plugin's `allow-offline-mode-players` setting instead of opening a second direct backend path. ## Velocity or BungeeCord With the Connect Plugin Install the Connect plugin on the proxy when the proxy is the public entry point for the network. The proxy then keeps its normal forwarding relationship with backend servers. Check these pieces first when players join but have the wrong UUID, skin, permissions, or login state: * the Connect plugin is installed on the proxy, not only on one backend server * backend servers are configured for the proxy forwarding mode you already use * Velocity, BungeeCord, Paper, and login plugins agree on online-mode behavior * players are not bypassing the proxy through a direct backend address Connect does not replace Velocity or BungeeCord forwarding between your proxy and backend servers. It gives the proxy a managed public ingress path. ## Standard Gate With Connect Enabled Use this topology when Gate is your Java proxy and you want Connect to expose it through the Connect network. Connect players reach the Connect edge first, then your Gate connector, then Gate routes to its configured backend servers. For Connect-routed Bedrock players, translation is already handled before traffic reaches your Gate connector. You do not need `bedrock: true` just because players use a Connect address. Enable `bedrock: true` only when Bedrock clients also connect directly to the Gate address you host yourself. ## TCPShield and Connect Together Some networks keep TCPShield for Java traffic while adding Connect for managed Bedrock or additional endpoint routing. That can work, but treat it as two ingress paths: * Java players using the TCPShield address follow the TCPShield and proxy forwarding path. * Java or Bedrock players using a Connect address follow the Connect path. * Account, UUID, skin, and IP-forwarding behavior can differ between those paths if the backend/proxy is not configured consistently. When debugging, always ask which address the player used. A kick that happens through `minekube.net` may not reproduce through a TCPShield hostname, and the reverse is also true. ## Direct Backend Connections Direct backend connections are useful for local debugging but should not be mixed casually with Connect or proxy ingress. If players can bypass the proxy and join a backend directly, the backend may see different online-mode, forwarding, UUID, skin, permission, or IP information. For production, prefer one public path per player group and make the backend reject unintended direct traffic. ## Quick Debug Checklist 1. Ask for the exact address the player joined. 2. Identify the connector: Paper/Spigot plugin, Velocity plugin, BungeeCord plugin, or Gate connector. 3. Identify whether the player is Java or Bedrock. 4. Identify whether Bedrock is Connect-routed or direct Gate Bedrock. 5. Check whether the backend is reachable directly and whether players might bypass the intended proxy. 6. For UUID, skin, permission, or login issues, check forwarding and login-plugin configuration before changing Connect. --- --- url: https://connect.minekube.com/guide/compatibility.md description: >- Supported Connect platforms and known proxy, login-plugin, modded-server, and Bedrock compatibility constraints. --- # Compatibility Matrix Connect works best when the Minecraft ingress path is simple and each layer has one responsibility. This matrix captures the combinations that most often need extra care. ## Platforms | Platform | Connect support | Notes | | --- | --- | --- | | Paper and Spigot | Supported with the Connect plugin | Recommended for single-server setups. Keep direct backend access closed unless intentionally public. | | Velocity | Supported with the Connect plugin | Use stable Velocity builds when possible. Snapshot builds may change internals that proxy plugins rely on. | | BungeeCord | Supported with the Connect plugin | Make sure backend forwarding and online-mode behavior match your BungeeCord setup. | | Standard Gate | Supported as a Connect connector | Connect-routed Bedrock is handled at the Connect edge. Direct Gate Bedrock needs standard Gate with `bedrock: true`. | | Gate Lite | Can be used as a Java reverse-proxy connector behind Connect | Lite forwards ping and player authentication to the selected backend route. `Connect -> Gate Lite -> online-mode backend` is not supported today through AuthSession/passthrough. Use standard Gate or the Connect Java Plugin for online-mode Connect ingress. Gate Lite is not the direct Bedrock listener. | | Sponge or Minestom | Not a primary Connect plugin target | Put a supported proxy or server in front, or test carefully before using in production. | ## Proxy and Login Plugins | Component | Risk | Recommended support response | | --- | --- | --- | | Velocity snapshots | Medium | Ask for the exact Velocity build and Connect plugin version. Reproduce on a stable Velocity build if packet or login behavior changed. | | FastLogin, AuthMe, NLogin, and similar login plugins | Medium to high | Ask whether the server is online-mode, offline-mode, or mixed. Confirm whether the player joined through Connect, TCPShield, direct proxy, or direct backend. Do not treat a Connect-managed Bedrock report as a reason to enable direct Gate Bedrock. See [Login and Auth Plugins](/guide/login-plugins) for the rule that decides whether a login plugin conflicts with Connect. | | Packet-level premium autologin (an auth plugin that takes the login packet over and runs its own `EncryptionRequest` and Mojang sessionserver check - for example LoginTo 4.0.x with its premium mode enabled) | High | Connect finishes the client's login at the edge, so a plugin's own second login handshake has no live client side to complete it: the player never finishes joining, usually with no kick message and nothing in the server log. This is not the pre-login online-mode conflict that `login-reassert` covers, so do not answer it with a Connect version upgrade - the floor restores Connect's own login decision, it cannot answer a handshake another plugin is waiting on. Ask for the plugin name and config, and check the endpoint's mode: turning the plugin's premium/online-mode mode off is the fix that works, while the `connect-player` exemption only exists for Connect-authenticated sessions and therefore cannot fire on an offline-mode or `allow-offline-mode-players` endpoint. See the [integration contract](/guide/login-plugin-integration). | | LibreLogin with premium autologin enabled | Version-dependent | Use Connect v0.13.1 or newer and keep premium autologin enabled. See [Login and Auth Plugins](/guide/login-plugins#librelogin-with-premium-autologin) for the default skin handling and optional profile settings. | | PacketEvents-based Velocity plugins (including Sonar and some nLogin builds) | Fixed in Connect Java 0.15.5 | Before 0.15.5 a tunneled player could reach post-login and then disconnect because PacketEvents expected Velocity's ordinary socket-channel state while Connect supplied a local tunnel channel; removing only the auth plugin was not a durable fix. Connect Java 0.15.5 and newer resolve Velocity's current frontend initializer for every tunneled connection, so late PacketEvents/nLogin wrappers are preserved ([connect-java#142](https://github.com/minekube/connect-java/pull/142), merge `b539e53`, which closed [connect-java#141](https://github.com/minekube/connect-java/issues/141) and the related post-login stall on a direct Paper connector in [connect-java#140](https://github.com/minekube/connect-java/issues/140)). Ask for the Connect plugin version first: an install older than 0.15.5 needs an update to the current release, not a workaround. If a join still fails on 0.15.5 or newer, compare a direct Velocity join, collect the PacketEvents/plugin versions and exception, and open a new issue instead of following the closed ones. | | Gate Lite with an online-mode backend | High | AuthSession/passthrough for Lite backend routes is not available today. Do not suggest `-Dmojang.sessionserver=` or a Gate Lite config change as a working fix. Recommend standard Gate with Connect enabled or the Connect Java Plugin on the online-mode proxy/server. | | MultiProxySync and profile/skin sync plugins | Medium | Check whether UUID/profile data is expected from the proxy, backend, or plugin. Compare behavior between the direct proxy path and the Connect path. | | TCPShield in front of Java while Connect handles Bedrock | Medium | Treat as two ingress paths. Ask which hostname the player used and whether forwarding is configured consistently on both paths. | | Backend direct public access | High | Players can bypass forwarding and authentication assumptions. Recommend closing direct backend access or documenting it as a separate path. | ## Modded and Hybrid Servers | Server type | Risk | Notes | | --- | --- | --- | | Vanilla-compatible Paper or Spigot | Low | Best supported path. | | Forge or NeoForge behind a supported proxy | Medium | Test login and plugin-message behavior. Some modded handshakes assume a direct client-to-server path. | | Arclight/Ketting/Forge hybrids, Mohist, Magma, and similar servers | High | Hybrid server internals vary. Ask for exact server type/version and logs before recommending a Connect or proxy setting. | | Fabric servers with FabricProxy-Lite | Medium | Verify the proxy forwarding mod expected by the backend is installed, enabled, and configured with the same forwarding secret as the proxy. | | Fabric servers with CrossStitch | Medium | CrossStitch is required when the Fabric backend needs Velocity modern forwarding support that FabricProxy-Lite alone does not provide. It is recommended when users report login/profile mismatch with Velocity-style forwarding. Verify by checking the backend log for the forwarding mod loading and by confirming direct Velocity-to-backend login works before adding Connect. | | Polymer and server-side mod stacks | Medium | Usually compatible when the server remains vanilla-protocol compatible. Ask whether the issue also occurs without Connect and collect the mod list when resource-pack, profile, or login behavior differs. | | NeoForge 1.21.x / Proxy-Compatible-Forge through Connect | Product investigation | Gate v0.69.1 fixed the open-bundle transition defect that was proven, and the Connect edge consumes that fix with regression coverage. A complete end-to-end NeoForge path has not yet been proven, and later failures may have a different cause. Preserve the join address, Connect plugin version, proxy type/version, NeoForge version, Proxy-Compatible-Forge version, exact kick text, and status/login/configuration-phase logs, then follow [connect#111](https://github.com/minekube/connect/issues/111). | | Modpacks requiring custom client handshakes | Medium to high | Confirm whether the proxy and backend both support the required handshake. | Use a product bug when a NeoForge or Forge-compatible path works through the same proxy without Connect but still fails only through the current Connect edge. The report should focus on whether Connect preserves the status, login, plugin-message, and configuration-phase metadata the backend forwarding mod expects. ## Voice Chat Connect does not currently tunnel the separate UDP transport used by proximity-voice plugins such as Simple Voice Chat. Minecraft can still join through the Connect hostname, but voice packets cannot use that hostname because the Connect edge has no UDP voice listener or route to the backend yet. This limitation is tracked in [connect#159](https://github.com/minekube/connect/issues/159). Server owners can use one of these paths today: * expose the voice plugin's UDP port (Simple Voice Chat defaults to `24454`) on the backend and configure its `voice_host` to that public address; Minecraft traffic can continue through Connect * use a voice system that does not require a direct game UDP path, such as a browser-based voice plugin Installing Simple Voice Chat beside the Connect plugin does not create a tunnel automatically. The SVC client mod is still required, and opening local UDP `19132` does not help: that port is for Bedrock Minecraft traffic, not voice. ## Bedrock and Account Linking Connect-routed Bedrock players use the same Connect endpoint names and custom domains as Java players. The Connect edge handles Bedrock translation before traffic reaches your connector. If a Bedrock player can ping but cannot join: * confirm the player joined a Connect address, not a direct Gate address * read the exact rejection reason; `policy_linked_java_only` is an explicit Connect edge override, while the default endpoint policy accepts Microsoft/Xbox-authenticated Bedrock identities without a linked Java account * check whether the kick is from the Connect edge, the connector, the proxy, or the backend * avoid recommending backend Geyser, Floodgate, UDP port opening, or `bedrock: true` unless the user wants direct Bedrock clients to hit their own standard Gate instance For backend Floodgate API issues, use the [Bedrock support matrix](/guide/bedrock#support-behavior-matrix) and collect plugin versions before recommending topology changes. ## What to Ask For For compatibility reports, ask for the smallest useful set of facts: * player address used to join * Java or Bedrock client * connector type and version * backend/proxy type and version * whether there is TCPShield, Velocity, BungeeCord, Gate, or direct backend access in the path * exact kick text and logs around the timestamp * whether the issue reproduces through another address That information usually tells support whether the issue belongs to Connect ingress, proxy forwarding, backend auth, modded handshake compatibility, or local server configuration. --- --- url: https://connect.minekube.com/guide/login-plugins.md --- # Login and Auth Plugins *This page explains how Connect changes the login flow on your proxy, which login plugins conflict with it, and how to tell in advance whether a given plugin will work.* ## How Connect Changes Login For players using Connect's normal authenticated flow, Connect authenticates them at the [Connect edge](/guide/#the-connect-network) before they ever reach your proxy or server. By the time the connection arrives at your [connector](/guide/connectors/), the Mojang session has already been verified and consumed. This page's UUID and skin guidance applies to those players; unauthenticated players allowed through with `allow-offline-mode-players` do not have a Mojang identity for Connect to supply. For an authenticated Connect player, the Connect plugin therefore does two things during login: * at pre-login, it marks the connection **offline mode**, so your proxy does not send an encryption request * it supplies the player's real Mojang UUID and skin properties itself, out of band This is not the same as running an [offline-mode](/guide/offline-mode) server. The player is authenticated - just somewhere else. There is no second Mojang session left for your proxy to verify, so **a Connect-tunneled connection will hang if an online-mode decision reaches the proxy**. The player gets no kick message and never finishes joining. Connect v0.13.1 and newer protect the documented LibreLogin path by default; arbitrary-plugin guarantees depend on proxy ordering support. ## LibreLogin with Premium Autologin LibreLogin's premium autologin handler can overwrite Connect's offline-mode decision and force the connection online. On Connect versions before v0.13.1, the proxy then sends an encryption request into a tunnel whose real client is attached to the Connect edge, and the login never completes. **LibreLogin works out of the box with Connect v0.13.1 or newer.** Connect now re-asserts its own offline-mode decision after other login plugins have run, so premium autologin stays enabled and the login completes. On Velocity, Connect also restores the player's skin properties by default while leaving LibreLogin's database UUID unchanged. On BungeeCord, the login and premium autologin fix still applies. During pre-login, BungeeCord exposes no profile-properties API on the pending connection, so `restore-full-profile` can re-assert the Mojang UUID and username but cannot restore skin properties through this setting. ### Re-assert Configuration The shipped defaults are: ```yaml login-reassert: enabled: true restore-full-profile: false ``` `login-reassert.enabled` is the optional off-switch. Set it to `false` only if you deliberately want another plugin to change Connect's login decision after Connect. This restores the previous last-writer-wins behavior; a plugin that forces online mode can make Connect players hang during login again. By default, Connect preserves the UUID chosen by the login plugin. This keeps the plugin's database lookups consistent, but code that calls Connect's `isConnectPlayer(uuid)` or `getPlayer(uuid)` API may not recognise the player under that different UUID. To restore Connect's full profile, including the Mojang UUID and username, set `login-reassert.restore-full-profile` to `true`. **Before enabling it with LibreLogin, set `new-uuid-creator: MOJANG` in LibreLogin's config.** With LibreLogin's default `CRACKED` UUID creator, full-profile restoration makes its database lookups miss and its join handlers fail. Do not expect this floor on a plain Paper/Spigot server: `login-reassert` is implemented on Velocity and BungeeCord only, and there is no equivalent config there. On Spigot, Connect owns the login for authenticated sessions and the `connect-player` marker is the integration path, so a Spigot login plugin is only safe if it either ignores tunneled players or checks the marker itself. ## The General Rule for Any Login Plugin The conflict is not specific to one plugin. Check any login or auth plugin against this rule: Connect v0.13.1+ guarantees the LibreLogin path described above. For arbitrary login plugins, strict after-all protection on Velocity requires the numeric-priority API; on legacy Velocity, Connect uses `PostOrder.LAST`, so another `LAST` handler can still run after it depending on plugin load order. | Plugin behavior | Result with Connect | | --- | --- | | Only acts on offline-mode connections, never forces online mode, and leaves the login packet to Connect | Compatible by design | | Can force online mode at pre-login | Connect v0.13.1+ re-asserts its offline-mode decision by default; on legacy Velocity, arbitrary plugins may still depend on plugin load order; older versions, or a disabled re-assert, can hang during login | | Rewrites the game profile after Connect has set it | Connect v0.13.1+ restores skin properties on Velocity by default; the plugin's UUID remains unless full-profile restoration is enabled | | Hooks the login **packet** and runs its own authentication handshake - a premium or online-mode autologin that cancels the login start, sends its own `EncryptionRequest` and checks the Mojang sessionserver | Not compatible, and the re-assert above cannot help. Connect finishes the client's login at the Connect edge, so a second login handshake has no live client side to complete it: the join stalls before it reaches your server, and the player is eventually dropped by your server's own login timeout (`Took too long to log in`) - a line that names no cause, mentions neither Connect nor the plugin, and is easily mistaken for a client or network problem. Connect can only restore its own login decision, not answer a handshake another plugin is waiting on. Disable the plugin's premium/online-mode mode for traffic arriving through Connect, or use a login path that does not start a second handshake. | The first row is about the login **decision**, not about the login **packet**. A plugin only conflicts if it changes what Connect decided or takes the packet over itself; a plugin that hooks the login packet is the last row even when it never "forces online mode" as a proxy setting, which is why the first row alone is not enough to clear an auth plugin. That timeout belongs to your server, and Connect has no login deadline of its own. It therefore only exists while the handshake reaches the server: a plugin that swallows the handshake as well as the login packet leaves a connection that nothing times out. On connect-spigot **0.15.16 and newer** the connector logs one named line for this stall about ten seconds after the handshake (`Connect tunneled login stalled: no LOGIN_START reached the connector within 10000 ms`, with the player, session and endpoint), so the stall can be attributed instead of guessed at - the line makes the stall visible, it does not end it and it does not complete the login. One more plugin shape is not about the login decision at all: a plugin that injects into the proxy's Netty pipeline after login, such as PacketEvents-based plugins (Sonar, some nLogin builds). Connect Java **0.15.5** and newer resolve Velocity's current frontend initializer for every tunneled connection, so those late wrappers are preserved; before 0.15.5 a tunneled player could reach post-login and then disconnect. Ask for the Connect plugin version before diagnosing this one: on an older install the action is an update to the current release, not a plugin removal. If a plugin exposes a Floodgate-style "skip externally authenticated players" exemption, its author can cooperate with Connect by including Connect's `connect-player` connection marker in that exemption, alongside the Floodgate one. That requires no dependency on Connect classes. That exemption only fires where Connect authenticated the session. For a **passthrough** session - an offline-mode endpoint, or one with `allow-offline-mode-players` enabled - Connect deliberately leaves `connect-player` unset, so an exemption keyed on the marker never applies and the plugin still runs its own login flow. On those endpoints the marker is not an available integration point: either the endpoint has to be sending Connect-authenticated players (see [Offline Mode](/guide/offline-mode)), or the plugin's conflicting mode has to be turned off. A support answer cannot recommend the marker route for a passthrough endpoint. Plugin authors get the exact attribute name, its Netty key, the single set-site, and a copy-paste exemption recipe on [Login Plugin Integration](/guide/login-plugin-integration). The passthrough rule above is part of that published contract, not an implementation detail. See the [Compatibility Matrix](/guide/compatibility#proxy-and-login-plugins) for the wider set of proxy and login plugin combinations that need extra care. --- --- url: https://connect.minekube.com/guide/login-plugin-integration.md description: >- The connect-player attribute contract for login, auth, and premium-detection plugins that run beside Minekube Connect. --- # Login Plugin Integration *This page is the contract for authors of login, auth, or premium-detection plugins - LibreLogin, AuthMe, nLogin, and anything similar - that run on a proxy or server which also runs Minekube Connect. It is written for plugin authors; the operator-facing behaviour (which plugin shapes conflict, and the `login-reassert` floor) is on [Login and Auth Plugins](/guide/login-plugins).* Connect authenticates players at its edge and hands your proxy an already-verified, offline-mode connection. Connect publishes a stable marker on that connection - the `connect-player` Netty channel attribute - so your plugin can detect a Connect-tunneled player and skip its own login flow. This is the same pattern many plugins already implement for Floodgate's `floodgate-player` attribute. ## Why the marker exists Connect terminates the real client connection at the Minekube edge, performs the Mojang online-mode handshake there, and then relays the player's traffic into a local channel inside your proxy. On that inner connection, Connect marks the player **offline mode** and supplies the real Mojang UUID, username, and skin properties itself. There is no second Mojang session for the proxy to verify. So any plugin that later forces **online mode** on a Connect-tunneled connection makes the proxy send an `EncryptionRequest` that can never be answered - the client's login was already finished at the Connect edge, so the player's login hangs and never completes. The same applies to rewriting the game profile after Connect has set it: the player ends up with the wrong UUID and no skin. That is also why a plugin which starts its **own** login handshake from the login packet cannot work on a tunneled connection: there is no live client side left to complete it. See the packet-level row in [the general rule for any login plugin](/guide/login-plugins#the-general-rule-for-any-login-plugin). The `connect-player` attribute lets you detect that situation before you act. ## The contract ### `connect-player` - channel attribute | | | |---|---| | Attribute name | `connect-player` (exact, permanent) | | Netty key | `io.netty.util.AttributeKey.valueOf("connect-player")` | | Constant | `com.minekube.connect.api.ConnectAttributes.CONNECT_PLAYER` | | Value type | `com.minekube.connect.api.player.ConnectPlayer` (never `null` when the attribute is set) | | Set on | The proxy-facing channel, at channel creation, before any platform login event fires | | Platforms | Velocity, BungeeCord, Spigot - one set-site covers all three | | Set when | The session is authenticated by Connect, i.e. `Auth#isPassthrough()` is `false` | | Absent when | The connection is not Connect-tunneled, **or** it is a passthrough session | Passthrough sessions are deliberately left unmarked: Connect did not authenticate them, so they should still go through your plugin's normal login flow. An offline-mode endpoint, and any endpoint with `allow-offline-mode-players` enabled, serves passthrough sessions - on those endpoints the marker is **not** available as an integration point, which is the case that most often surprises plugin authors. See [Offline Mode](/guide/offline-mode). Because the marker is set when the channel is created, it is already present in Velocity's `PreLoginEvent` and `GameProfileRequestEvent`, in BungeeCord's `PreLoginEvent`, and in Spigot's login handling - including handlers registered at the very earliest priority. ### `ConnectApi` - UUID lookups for online players Once a player has finished logging in, `com.minekube.connect.api.ConnectApi` answers the same question by UUID: ```java ConnectApi api = ConnectApi.getInstance(); boolean tunneled = api.isConnectPlayer(uuid); // is this online player tunneled by Connect? ConnectPlayer player = api.getPlayer(uuid); // null if not ``` These are the right tool for post-login checks (session tracking, limbo routing, command gating). They are **not** usable during login, because the player is not registered yet - that is what the channel attribute is for. ## How to integrate If your plugin already exempts Floodgate players, the Connect exemption is the identical shape. Add it at every point where you would otherwise override the connection's authentication decision or identity. **Presence check, with no dependency on Connect** - Netty interns attribute keys by name, so this compiles and works whether or not Connect is installed: ```java private static final AttributeKey CONNECT_PLAYER = AttributeKey.valueOf("connect-player"); private static boolean isConnectPlayer(Channel channel) { return channel.hasAttr(CONNECT_PLAYER) && channel.attr(CONNECT_PLAYER).get() != null; } ``` **Velocity - pre-login.** Reach the channel the same way you already do for Floodgate (`LoginInboundConnection#delegate` → `InitialInboundConnection` → `MinecraftConnection` → `Channel`), then bail out: ```java @Subscribe(order = PostOrder.LAST) public void onPreLogin(PreLoginEvent event) { Channel channel = channelOf(event.getConnection()); if (channel != null && isConnectPlayer(channel)) { return; // externally authenticated by Connect - never force online mode } ... } ``` **Velocity - game profile.** Do not rebuild the profile from the original one; Connect has already put the player's real UUID and skin properties in it. **BungeeCord - pre-login.** Same check before any `setOnlineMode(true)`. **Post-login / session tracking.** Use `ConnectApi.isConnectPlayer(player.getUniqueId())` to skip your own authorization tracking, limbo routing, and command blocking, the same way you skip them for Floodgate players. **Optional: read the player.** If you add Connect's `api` artifact as a dependency you can use `ConnectAttributes.CONNECT_PLAYER` directly and read the `ConnectPlayer` value for the player's UUID, username, game profile, and `Auth`. That is why the attribute value is a `ConnectPlayer` rather than a bare UUID - presence alone costs you nothing, and the full identity is there when you want it. ### Login packet handlers The marker covers plugins that decide **what to do with** the connection. It does not help a plugin that instead intercepts the login **packet** and runs its own handshake (a premium/online-mode autologin that cancels `LoginStart`, sends its own `EncryptionRequest` and checks the Mojang sessionserver): Connect's client login is already finished at the edge, so that handshake has no peer to answer it. Such a plugin needs its premium/online-mode mode disabled for Connect traffic, or a login path that does not start a second handshake. See [the general rule for any login plugin](/guide/login-plugins#the-general-rule-for-any-login-plugin). On Paper and Spigot the ordering makes that case worse than "unsupported": the connector completes its own login only when its data handler receives the login start packet, and a packet-level listener runs **upstream** of that handler (PacketEvents installs its decoder ahead of the vanilla decoder, which is ahead of the connector's data handler). A plugin that consumes the packet therefore leaves the login pending with nothing to complete it, and a re-assert cannot help because there is no login decision left to restore - the only thing that ends the stall is the server's own login timeout. On connect-spigot **0.15.16 and newer** the connector logs one named line for this stall about ten seconds after the handshake (`Connect tunneled login stalled: no LOGIN_START reached the connector within 10000 ms`, with the player, session and endpoint), so the stall can be attributed instead of guessed at - the line makes the stall visible, it does not end it and it does not complete the login. See [Login and Auth Plugins](/guide/login-plugins#the-general-rule-for-any-login-plugin) for the operator-facing shape of that case. ## Connect defends its own decision (operators) Not every login plugin exempts Connect, so Connect does not rely on one. On proxies it registers a second pre-login handler that restores its own decision if something changed it, which is what keeps a "force online mode for everyone" plugin from hanging Connect players. That handler is a floor, not a veto, and it only ever acts on connections Connect itself authenticated. The config keys, the ordering guarantees, and what the floor cannot do are documented once, for operators, on [Login and Auth Plugins](/guide/login-plugins#re-assert-configuration). That detail is deliberately not repeated here. Note the scope: `login-reassert` is implemented on Velocity and BungeeCord only. On a plain Paper/Spigot server there is no re-assert floor at all, so the `connect-player` marker above is the integration path and a Spigot login plugin is only safe if it ignores tunneled players or checks the marker itself. ## Stability commitment **`connect-player` is a permanent public contract.** Minekube commits to this explicitly: once external plugins depend on the name `connect-player`, it will **never be removed or renamed**. The attribute name, the fact that it is set before any login event, and the rule that it is absent for passthrough sessions are all part of Connect's published API surface - treat them exactly like a published method signature. Changes may only be additive. This is a deliberate commitment, not an accident of the implementation. A future contributor must not treat `connect-player` as an internal detail that is free to be refactored, renamed, or moved to a later point in the connection lifecycle. Doing so silently breaks every third-party login plugin that integrates with Connect, with no compile error anywhere to warn about it. The commitment is enforced in Connect's own test suite, which pins both the exact name and the set-site, so a rename or a moved marker fails its build. ## Checking a login plugin for compatibility * **Not compatible** if it starts its own login handshake from the login packet (its premium/online-mode autologin), or if it can force online mode at pre-login (`forceOnlineMode()` / `setOnlineMode(true)`), or if it rewrites the game profile after Connect has set it. * **Compatible by design** if it only ever acts on offline-mode connections, never forces online mode, and does not intercept the login packet itself. * **If it has a Floodgate exemption**, ask its author to extend that exemption to Connect's `connect-player` attribute - the code is the same three lines. That only applies where Connect authenticated the session; for passthrough sessions the marker is absent by design. ## Related source Connect's plugin code is public in [minekube/connect-java](https://github.com/minekube/connect-java): * `api/src/main/java/com/minekube/connect/api/ConnectAttributes.java` - the attribute key and its Javadoc contract * `api/src/main/java/com/minekube/connect/api/ConnectApi.java` - `isConnectPlayer(UUID)` / `getPlayer(UUID)` * `api/src/main/java/com/minekube/connect/api/player/Auth.java` - `isPassthrough()` * `core/src/main/java/com/minekube/connect/network/netty/LocalServerChannelWrapper.java` - the single set-site * `docs/login-plugin-integration.md` - the connector-repository copy of this page; keep the two in step *This page is mirrored by `docs/login-plugin-integration.md` in [minekube/connect-java](https://github.com/minekube/connect-java). Change one, change the other.* --- --- url: https://connect.minekube.com/guide/offline-mode.md description: >- Allow offline or cracked Java players through Connect without weakening authenticated Bedrock identity. --- # Offline Mode *This page explains how to allow players to join your server in Offline Mode.* ## What is Offline Mode? Offline mode is a feature of Minecraft Vanilla that allows players to join a server without needing an Internet connection to authenticate their Minecraft account. This is useful for LAN parties or for players who don't own a Minecraft account. There are also many public offline-mode servers that allow players to join without a paid Minecraft account. Offline mode servers and unauthenticated players are often referred to as *cracked* servers and players. ::: warning Java only Connect offline mode applies to Java Edition. It does not create an unauthenticated Bedrock path. Connect-managed Bedrock always requires a valid Microsoft/Xbox session. ::: This is different from Connect-managed Bedrock identity. Bedrock players who join through Connect can be authenticated with official Microsoft/Xbox Bedrock auth and still travel through a Java connector. That trusted Bedrock/XUID path does not require allowing arbitrary offline-mode Java players. ## Joining the [Connect Browser Hub](/guide/advertising#browser-hub) Offline Java players use either canonical cracked entry point: * `cracked.minekube.net` * `cracked.minekube.com` Use `cracked.*`, not `offline.*`. From the Browser Hub, select an endpoint or run `/browser join `. The target endpoint must explicitly allow offline Java players. ## Allowing Offline Java on an Endpoint It is possible to join the [Connect Network](/guide/#the-connect-network) without a valid Minecraft account. By default, Connect ensures that only Mojang authenticated players can join your online mode server. To allow unauthenticated Java players, enable the option on the connector that owns the endpoint: ::: code-group ```yaml [plugins/connect/config.yml] allow-offline-mode-players: true ``` ```yaml [Gate config.yml] connect: enabled: true allowOfflineModePlayers: true ``` ::: The default is `false`. You do not need to make the backend publicly reachable or create a second direct connection path. Keep the rest of the topology's normal forwarding and online-mode settings unless you intentionally operate a fully offline network. ::: danger Offline identities are not verified An offline Java name is self-asserted and can be impersonated. Do not grant administrative permissions by name alone. Use an authentication plugin if your offline community needs persistent accounts. ::: Offline-mode player connections are not encrypted between the player and the [Connect Network](/guide/#the-connect-network) edge. Player connections are always encrypted between the Connect edge and [Connect Endpoints](/guide/#connect-endpoints) - thanks to [Connect Tunnels](/guide/tunnels). Connect also marks its own authenticated player connections offline mode at pre-login, because those players were already authenticated at the Connect edge. That is an internal detail of the login flow and is unrelated to this option. It does matter for login plugins - see [Login and Auth Plugins](/guide/login-plugins). Do not enable either offline-mode option just because a Bedrock player is joining through Connect. Use the [Bedrock support guide](/guide/bedrock) to decide whether the player is on the Connect-managed Bedrock path, a direct self-hosted Gate Bedrock path, or a real offline-mode Java path. --- --- url: https://connect.minekube.com/guide/tunnels.md --- # About Connect Tunnels Networking knowledge recommended *Don't believe in magic? This page explains how [Connect Tunnels](/guide/#connect-tunnels) enable player connections beyond private networks.* \[\[toc]] ## Introduction Publicly routable IP addresses are required to allow inbound connections from the Internet (outside your home network). Your ISP (Internet Service Provider) assigns you a public IP address, but sometimes it's dynamic and changes over time. Further, your router has a NAT (Network Address Translation) that allows multiple devices to share the same public IP address in your home network. This is why you can have multiple devices connected to the Internet at the same time, their private IP addresses are translated to your public IP address when communicating with the Internet. **However, your home firewall blocks inbound connections by default, including Minecraft connections on port `25565`.** ## Connect to the Rescue Connect bypasses this whole problem by establishing outbound only tunnel connections from your server to publicly routable edge proxies in the [Connect Network](/guide/#the-connect-network). This way, you don't have to configure port forwarding on your router. Connect edge proxies accept inbound connections from players and routes them through encrypted tunnels to your server. The [Connectors](/guide/connectors/) establish a tunnel connection to the edge proxy for every player that joins your server. Attentive readers are now wondering how the plugin knows when a player wants to join and from which edge proxy. This is where the [Connect Session Service](/guide/#connect-sessions) comes in. The plugin watches for player session proposals from this service and establishes a tunnel connection to the correct edge proxy. ## The Join Flow This is how the join flow looks for every player: 1. Connect plugin watches for player session proposals 2. A player on an edge proxy wants to join your server and sends a session proposal 3. Your server accepts the proposal and establishes a tunnel to the edge proxy to take over the player session This flow is quite fast and happens within a few milliseconds. The player doesn't notice any difference and can play on the performant tunnel to your server as usual. ## Connectors Check out the [Connectors Overview](/guide/connectors/) to learn more about Connectors. *** **If you find these concepts intimidating, don't worry! The [Quick Start](/guide/quick-start) only requires basic knowledge, and you should be able to follow along without being an expert in any of these.** --- --- url: https://connect.minekube.com/guide/protections.md --- # Server Protections *Server protections are a set of features that protect your server from malicious players and attacks.* The best way to protect your server is to hide the public IP behind the [Connect Network](/guide/#the-connect-network) and enable online-mode. ## DDoS Protection When hiding your server behind Connect, the network tries to protect your server from DDoS attacks by using a distributed network of proxies to route player traffic through. This means that if one of the proxies in the network is under attack, other proxies will take over real player traffic and protect your server from being overloaded. ## Bot Protection This feature is a Draft and not yet available Connect uses a set of heuristics to detect bots and malicious players. If a player is detected as a bot, they will be disconnected from the network. Methods used to detect bots: * Player movement * Human verification captcha * Heuristic to check for sending too many packets per second One great method to make it harder for spambots is to enable online-mode for your server to only allow players to join your server if they have a valid Minecraft account. ::: tip Protecting your server from bots is a never ending battle. If you have a good idea on how to improve the bot protection, please let us know on our [Discord](https://minekube.com/discord). ::: --- --- url: https://connect.minekube.com/guide/advertising.md --- # Advertising Channels for Your Server Always Free *Discovering and advertising your server is an important part of growing your community. The [Connect Network](/guide/#the-connect-network) provides ways to advertise your servers to players.* ## Browser Hub Always Free The well-known **Connect Browser Hub** is part of the [Connect Browser](/guide/#the-connect-browser) and is one of the first places that players see when joining the [Connect Network](/guide/#the-connect-network) without an [Endpoint Domain](/guide/domains). It is a central place of the [Connect Platform](/guide/#the-connect-platform) that allows players to discover and join [Connect Endpoints](/guide/#connect-endpoints) from in-game. Players also fallback to the **Browser Hub** when they get disconnected from a server or try to join an endpoint that is currently inactive. ### Opting out of the Browser Hub Plus plan If you are on the **[Plus Plan](/plans)**, you can opt out of the **Browser Hub** in your [Dashboard](/guide/#the-connect-dashboard)'s organization settings. ![Browser Hub](/images/browser-hub.png) ```rhyme High above the clouds, the player seeks, A new server to join, with Connect at its peaks. ``` ## Chat Messages This advertising method is not yet available. You can broadcast custom chat messages to players on the [Connect Network](/guide/#the-connect-network) to let them know about your server. These messages are sent periodically to certain players to not spam them. [//]: # "todo with screenshots" ## Action Bar This advertising method is not yet available. You use the action bar to display a message to players in the [Browser Hub](#browser-hub). ## Boss Bar This advertising method is not yet available. You can use the boss bar to display a message to players in the [Browser Hub](#browser-hub). --- --- url: https://connect.minekube.com/guide/locations.md --- # Where are our Connect Proxies located? We operate multiple Connect proxies around the world to reach users worldwide. ## Our locations * Ashburn, Virginia (US) (iad) * Dallas, Texas (US) (dfw) * Los Angeles, California (US) (lax) * London, United Kingdom (lhr) * Amsterdam, Netherlands (ams) * Frankfurt, Germany (fra) * Stockholm, Sweden (arn) * Tokyo, Japan (nrt) * Singapore, Singapore (sin) * Sao Paulo, Brazil (gru) ## How everyone gets routed to their nearest Connect proxy We take advantage of anycast routing, which means that all Connect proxies share the same IP address. When you connect to the Connect network, your internet provider automatically routes you to the nearest Connect proxy. --- --- url: https://connect.minekube.com/guide/adoption-plan.md --- # The step-by-step plan to increase adoption We plan to grow the `Connect community` in phases and increase adoption of Connect step-by-step starting with targeting the most important features and audiences. The goal is to grow the following counting factors: * Connect Plugin **installations** * Servers **linked** to Connect Network * Users playing on servers **through** Connect Network ## Step #1 - Friends & Local Host Servers Our first target audience are friends that want to play together on their local host servers and servers owners experimenting with Connect. ## Step #2 - Grow creators & players pool Our second target audiences are creators that want to grow their player base and players that want to discover new servers. Here we will focus on the Connect Browser to make it an interactive in-game server list where players can surf, join and review servers with their friends. Gamification, Referral and Friends systems will be keys to success at this phase and beyond. ## Step #3 - Developers Our third target audience are developers to allow them to extend the Connect Platform and build their own plugins and services on top of it using supported Connect capabilities. Connect integrates a developer platform and marketplace for Minecraft plugins and services integrated with Connect. --- --- url: https://connect.minekube.com/guide/use-cases.md --- # Use cases *This use-cases list is a living document and will be updated as Connect progresses.* ## Make your local Minecraft server public Yes! As soon as your server is connected to the Connect Network players can join your Minecraft server even if it's running locally on your PC without configuring any port forwarding. You can read along [here](/guide/#public-localhost-servers). ## Interconnect your Minecraft servers easily The Connect Network serves as a Proxy-as-a-Service and replaces traditional Minecraft proxies like BungeeCord. You no longer need to configure and maintain a secure proxy for your Minecraft servers. The only thing you need is the [Connect Plugin](/guide/quick-start#downloading-the-connect-plugin) installed on your servers. ## Advertise your server to more players Connect is a public place to browse through all *Connected* servers from ingame. That means players either directly join your server by your domain or discover your server in the Connect Browser Hub. ## Move players between your servers without managing an own proxy No more need to deploy your own proxies since Connect Network already works like a global shared proxy where servers and even other sub-proxies can connect to. As the server owner you can control all your connected servers and players. There will be public APIs available for you to manage your connected endpoints (servers or proxies) and players like sending players a message, moving them between your servers and so on. --- --- url: https://connect.minekube.com/guide/roadmap.md --- # Connect Development *This roadmap is a living document and will be updated as Connect progresses.* ## Project Roadmap We are just getting started with the open Connect platform, and we are excited to see what the future holds. There are a lot of ideas being worked on hard to extend Connect and make it even more useful for creators and players. Our major goal is to keep Connect a stable and reliable service that is always on, always developing and the core features free to use for everyone. ## Additional components for Connect Platform These are Drafts and not yet available Beyond what is already available mentioned in the [Introduction](/guide/), we have a lot of ideas to extend Connect. ### Search * Find the top-rated game servers and quickly join them * See the history of servers you were connected on to join back later * Search for any game server registered with Connect Network and filter by rating, category, tags, and more ### Reviews Players can rate and review game servers they played on a certain amount of time and get rewarded for it. This helps other players to find the best game servers when browsing server categories. ### Maps **As a player:** You walk through the world and explore previews of every game server. You like what you see? Jump into its portal, and you get connected to the server in a blink of an eye! **As a server creator:** You design the gate of your game server to make it appealing to players walking by. Only limited to the Minecraft blocks available and your imagination you have an area where you can transfer the spirit of your games to advertise your server to new players. ### Games Developers can create their own games and integrate them with APIs in the Connect Network. Players are able to browse, play and rate these game servers. Developers host their games but will be able to let Connect do the deployment and scaling for them to focus on game development only. ### Cloud The Minekube Cloud will be a hosting platform that allows players and creators to create and manage servers on-demand and pay only for the time they use it. Players are able to control their servers and resources in-game from the Connect Hub and Dashboard. ## Reminders * We would like to support [Skript](https://forums.skunity.com/resources/skript.323/) with an addon to easily integrate Connect into your Skript scripts and manage your servers and players without needing to maintain a separate proxy. *** **There are plenty of more use cases, stay tuned and join the [Discord](https://minekube.com/discord) to talk about your ideas!** --- --- url: https://connect.minekube.com/guide/why.md --- # Why *We recommend reading the [Introduction](index) if you haven't already.* Let's start with where we come from, the problem definition, different parties involved and the solution space. ## Table of Contents \[\[toc]] ## Connect is for everyone! It doesn't matter if you are a small server owner or a large network operator or even a developer who wants to integrate Connect into their projects or a player who only wants to play on servers. *Connect is for you!* **Vision:** We connect player and creator communities world-wide. **Mission:** Our mission is to organize and connect Minecraft communities and make them universally accessible for all participants. **There are two core audiences that we want to connect and support...** ### Creators **Connect** is for Creators, they are the heart of the Minecraft community. They are the ones who make the game fun for players. They can be builders creating worlds, designers creating art, developers creating plugins, server admins hosting servers, content creators creating videos, managers creating communities, leaders creating teams and organizations, people like you reading this documentation or a creator can be all-in-one. As a creator, you want to: * Get more players to discover and play your game servers * Build a community around your game servers * Possibly make money with it ::: details Sometimes creators have to manage... infrastructure, software, plugins, larger community, finances, security, performance, updates, backups, downtime, scaling, monitoring, documentation, support, billing, marketing, advertising, analytics, legal, privacy, compliance, regulations, taxes, reputation, ... ::: ### Players *Connect* is for Players, they are the soul of the Minecraft community. They are the ones who play the game, explore the worlds, join servers, play with friends, and make creators feel fulfilled. As a Player, you want to * Discover new Minecraft servers * Play with your friends on your favorite servers * Make friends with other players * Get rewarded for doing certain tasks ## Problems of Creators #### First Steps are the hardest No matter how good your game server is players tend to not play on empty Minecraft servers: "If there are no players, the server is irrelevant" they think. Even worse if your game concept relies on a certain amount of players to be fun and enjoyable. You could advertise on social media, forums, websites, etc. and hope that players will find it. You can also pay for advertising, but that's expensive, and you don't know if it's worth it. #### Lack of Server Discovery Servers don't get votes without players, servers don't get players without votes. Voting server-list websites are not enough to launch your amazing projects. The first players are the most difficult to convince coming back to your server. You need to have a stable daily recurring player base in order to compete for more players and votes. ## Problems of Players There is no gamification of the server discovery process. They have to search through server-list websites and other sources and copy-paste server addresses. Players don't get rewarded for playing and reviewing new servers. That's why players tend to play on the same servers over and over again and miss out on new and exciting servers. ## Solutions - brought to you by Connect ### Organic Traffic One of the most powerful features of the Connect platform is the ability to serve organic traffic to your Minecraft servers. This means that players can discover your server from the in-game server browser and join without additional effort. This is a huge advantage over traditional voting websites where players have to copy and paste server addressed into their Minecraft client. ### Both parties involved Thanks to side effects the Connect Network grows exponentially as the following two factors increase: * **Creators** are incentivized to link their server to Connect because they can passively advertise their server to get more player traffic. * **Players** are attracted to the Connect Network because it's the place where they discover increasingly more new servers and content more easily with their friends. * The loop continues... *This is the same effect as we see with the TikTok platform.* ### Equal Opportunity The traditional Minecraft server listings are outdated and have a number of [drawbacks](#lack-of-server-discovery). Connect is a fair and equal opportunity platform that favours new and smaller creators too by giving them chances to get discovered by players. ## Why Minecraft? *Read along to learn more about the Minecraft multiplayer space or continue to the [Downloads page](/guide/downloads).* *** Today more and more games in the industry are being designed such that players can express their creativity and become content creators of the game platform itself leading the community to have access to an endless resource pool of new game content helping to reduce the effort needed of the platform maker trying to keep the player interest and engagement high. One of the largest such game platforms is Minecraft where many communities of players and creators can build and program highly customizable game experiences where only the imagination is your limit. It is no secret that Minecraft is one of the most popular games out there with millions of players every day and steadily rising. With Minecraft's $2.5 billion dollar acquisition by Microsoft in 2014 the game numbers and communities around it are blowing up even more due to younger generations loving the game. Some people of the community are no longer only players, but love creating game servers for players to join every day. Those people needed a higher skill set to configure, launch and maintain such a game server until more and more hosting companies reduced the entry barrier, the price and improved the customer experience for becoming a server owner. The number of managed Minecraft server providers grew and near to anyone can now create a server within minutes with little to no money needed. This results into a fleet of new game servers created every week. Owning a good game server is only step one, you still need to have a traffic source for new players finding out about your server in order for you as the admin to establish a recurring daily player base and grow, which is very hard. Introducing [Connect](/guide/)! --- --- url: https://connect.minekube.com/changelog.md description: >- User-visible changes across the Minekube platform. Complete coverage for the Connect plugin, GeyserLite and Craftless since June 4, 2026; selective for Gate and the hosted Connect service. --- # Changelog This page covers the whole Minekube platform: the hosted Connect service, and everything we publish for you to run yourself — Gate, the Connect plugin, GeyserLite, and Craftless, our Minecraft client automation framework for agents, tools and CI tests. Not every entry will be about something you run. The first badge on each entry names the product, so you can scan for your own. Coverage is not the same for every product. For the Connect plugin, GeyserLite and Craftless it is complete from June 4, 2026: every release since then that changes something you would act on is here. For Gate and the hosted Connect service it is selective — entries are the changes we judged worth naming, and a change being absent is not evidence it did not happen. Entries link to the public release that contains the change. Parts of the platform, including the hosted Connect service, are developed in internal repositories; those entries carry a date and a description and are marked *internal repository, no public link*. Subscribe to this page with RSS. Longer write-ups go on the [blog](/blog/). ## September 28, 2026 * Connect plugin Upgrade **A tunneled Spigot login that stalls before Connect now names where it stopped.** A packet-level login plugin can consume `LOGIN_START` before `connect_data_handler`, so Connect's offline-login cycle never runs and the client waits without a login response; before 0.15.16 the connector recorded no cause, leaving only the backend's later, cause-blind login timeout. [0.15.16](https://github.com/minekube/connect-java/releases/tag/0.15.16) installs a watchdog before the consuming handler: ten seconds after the handshake it writes exactly one warning with the player, session, endpoint and packet count, names the probable packet-pipeline cause, and explains why a passthrough `connect-player` exemption is not a fix. This is attribution only — it does not kick the player, fabricate a packet, complete the login or change a healthy session. ## September 27, 2026 * Connect plugin Upgrade **Chat from a tunneled player no longer kills the session on current Paper/Spigot backends.** Connect's Spigot chat filter rebuilds each serverbound chat packet to strip its unsigned-chat component, and it resolved the replacement constructor by hard-coded parameter types, while backends from 1.21.5 on — the Minecraft 26.3 line included — carry `Optional`. The lookup threw inside the injected pipeline for every plain chat message, and because the filter only ever sees post-login traffic no login failed: the connection closed right after spawn and the failure surfaced as a generic internal-server exception with no plugin-log line, so a session on 0.15.14 or earlier that dies this way reads as an unexplained teardown. 0.15.15 resolves the constructor from the runtime value the packet exposes, so one path serves the raw and the `Optional` shape, and a shape nothing matches now names the missing accessor and the types observed instead of a bare reflection error. It is one deterministic defect on that path, not an explanation for every post-spawn closure reported on current backends. 0.15.14 changes only the release pipeline (one apostrophe in a merged commit subject no longer stalls the release-please auto-merge), so it adds no plugin behaviour of its own; install [0.15.15](https://github.com/minekube/connect-java/releases/tag/0.15.15), which contains the fix. * Gate Upgrade **A backend packet Gate cannot decode now names the packet that closed the connection.** When a backend sent a packet Gate recognised but could not decode, Gate silently closed the backend socket at default verbosity, the backend logged nothing and the player saw only `Internal server connection error`; on a Connect tunnel there was nowhere else to attribute the close. [v0.74.28](https://github.com/minekube/gate/releases/tag/v0.74.28) writes one error on that backend-side close with the peer, packet type, packet ID and protocol. It is observability only: unknown or malformed client-side traffic stays quiet so an untrusted client cannot turn the diagnostic into a log-flood primitive. * GeyserLite Upgrade **GeyserLite accepts the current Bedrock clients again, and a native GeyserLite loads its own config.** v0.5.28 carries the upstream Geyser revision that registers Bedrock 26.50/26.51 — every GeyserLite up to v0.5.27 stops at Bedrock 26.45, which made GeyserLite, the Connect edge and any Gate `bedrock: true` listener built on it reject every current Bedrock client — but v0.5.28 published no downloadable build, so do not pin it. v0.5.29 registers the config classes Geyser's annotation processor generates, which the native-image build was dropping: without them every Geyser config load failed, presenting as a restart loop in standalone/subprocess mode and as a silent exit when embedded. v0.5.30 raises the purego dependency and v0.5.31 changes only the release pipeline. Install [v0.5.31](https://github.com/minekube/geyserlite/releases/tag/v0.5.31), which contains them all with builds attached. * Gate Upgrade **Stopping or reloading Gate no longer leaves a Connect runtime behind.** v0.74.19 stops and joins the Connect runtime Gate started, both on shutdown and before a config reload replaces it; previously the superseded runtime was swapped out without being stopped, so two connectors could watch the same endpoint and write the same token file, and Gate reported itself stopped while that runtime was still running. v0.74.20 refuses to start a runtime once Gate has been asked to stop, and v0.74.21 runs Gate's event manager on a race-free wrapper — the manager Gate used could silently drop a config update when a delivery overlapped a sibling subscriber's unsubscribe, with no log line at all. Install [v0.74.21](https://github.com/minekube/gate/releases/tag/v0.74.21). * Gate Upgrade **A Windows editor or deploy tool can save Gate's config while Gate is reading it.** Gate opened its config with a handle that shares read and write but not delete, so an editor's or deploy tool's atomic `ReplaceFileW` save of `gate.yml` was refused with `ERROR_SHARING_VIOLATION` for as long as one of Gate's own reads was in flight — on Windows, 1208 of 3000 replacements failed on that read path and none on the delete-sharing handle Gate already used for fingerprints. v0.74.26 reads the config content with the delete-sharing handle, and v0.74.27 covers the discovered `config.yml` path, which viper read on its own. Install [v0.74.27](https://github.com/minekube/gate/releases/tag/v0.74.27), which contains both. * Gate Upgrade **Gate names the runtime that died, the backend that never answered, and the version it actually resolved.** v0.74.12 logs the ViaLite runtime Gate resolved at startup — version, how it was resolved (download, cache, pin, explicit path) and where it runs from — so the live translation build is readable instead of inferred from the runtime's own output. v0.74.18 reports a managed ViaLite runtime that exits after startup: one error naming the component, the resolved version and the backends that runtime owned, and joins then fail saying protocol translation is down instead of the runtime module's bare `server not started`, which reads like a configuration mistake. v0.74.23 bounds and names the bridge dial of a dynamic, tunnel-backed backend the translation bridge cannot reach — that dial is detached from the join's deadline on purpose, so a stalled backend blocked the join forever and ended as a generic closed-connection message with nothing naming the backend. Install [v0.74.23](https://github.com/minekube/gate/releases/tag/v0.74.23). * Gate Upgrade **A hung Gate now tells you how to get a stack dump.** `kill -QUIT` is listed in Gate's termination signals, so `os/signal` consumes it: Gate shuts down gracefully and prints zero goroutine lines — following the usual advice ends the run and returns nothing. [v0.74.25](https://github.com/minekube/gate/releases/tag/v0.74.25) prints the working instruction (`kill -ABRT `, which also ends the run, so capture the console first) on the graceful-shutdown line, and a new troubleshooting page gives the signal table, what the dump looks like, and why neither `net/http/pprof` nor a debugger is an alternative on a release build. ## September 26, 2026 * Gate Upgrade **A Bedrock port conflict no longer costs ten minutes and your Java players.** With managed Bedrock enabled on a host where another process already holds the Bedrock UDP port, the managed runtime could never bind: Gate waited the full ten-minute startup timeout, the public Bedrock listener never answered, and Gate then shut the proxy down and disconnected every Java player with it — a Bedrock-only misconfiguration taking down Java. [v0.74.16](https://github.com/minekube/gate/releases/tag/v0.74.16) reports the held port within seconds and fails fast, so it is a startup error instead of a silently degraded proxy. ## September 21, 2026 * Gate Upgrade **Gate reads ports as the unsigned 16-bit values they are.** The handshake port is unsigned on the wire and Gate decoded it as signed, so a client declaring a port of 32768 or more arrived as a negative number — and that value is not merely logged, it is formatted into the virtual host the connection routes on, so `65535` became the host `host:-1`. v0.74.7 decodes it unsigned, v0.74.9 rejects an out-of-range port with an error instead of silently wrapping it into a different port that was never in the address (`host:70000` became `4464`, and `host:65536` was accepted as the no-port sentinel), and v0.74.10 writes BungeeCord's ServerIP port as the unsigned value it is. Install [v0.74.10](https://github.com/minekube/gate/releases/tag/v0.74.10), which contains all three. * Gate Upgrade **Gate's login RSA key size is configurable.** `auth.privateKeyBits` in `config.yml` now sets the key Gate generates for the Java login handshake. Before v0.74.8 the option existed, was documented and was never read, so every gate generated a fresh 1024-bit key at startup with no way to raise it from configuration — and the login packet decoders capped the key fields at exactly one 1024-bit block, so a larger key could not have completed a login at all. The default stays 1024 bits; install [v0.74.8](https://github.com/minekube/gate/releases/tag/v0.74.8) to set your own. ## September 19, 2026 * Gate Upgrade **Gate's vulnerable dependency set is refreshed.** [v0.74.1](https://github.com/minekube/gate/releases/tag/v0.74.1) bumps every manifest and lockfile that pinned a version with an open Dependabot advisory — 51 alerts, 13 of them high, none against Gate's own code. The part that ships inside the proxy binary is `go.mod`: `grpc` 1.82.1 to 1.84.0, `x/net` 0.53.0 to 0.59.0 (`CVE-2026-25680`), `x/image` 0.18.0 to 0.46.0, and the OTLP exporters 1.38.0 to 1.46.0. The docs site and API-example lockfiles are refreshed in the same release. ## September 18, 2026 * Gate Upgrade **Gate knows Minecraft 26.3.** [v0.74.0](https://github.com/minekube/gate/releases/tag/v0.74.0) adds 26.3 (protocol 777) to Gate's version table and fails closed on a protocol it does not know. Before it, an unknown protocol fell through to the minimum-version packet registry: a 26.3 login was encoded with pre-1.8 rules, the client failed to decode `minecraft:hello`, and the version check accepted every numeric protocol because it only rejected the unknown sentinel. Anyone running their own Gate in front of current Java clients needs this release. ## September 14, 2026 * Connect plugin Upgrade **Endpoint auth failures on an organization-owned endpoint now name the real problem instead of telling you to switch organizations.** Connect 0.15.12 reports the actual condition — the connector token does not match the token stored for that endpoint name — and the fix (put the new token byte-for-byte into the connector token file, `token.json` or `CONNECT_TOKEN`, not `config.yml`, then restart), instead of blaming the Minekube organization; the endpoint/token mismatch error gained the same guidance. 0.15.13 changes only the release pipeline (it retries a Modrinth read-back), so it adds no plugin behaviour of its own; install [0.15.13](https://github.com/minekube/connect-java/releases/tag/0.15.13), which contains the 0.15.12 fix. ## September 13, 2026 * Gate Upgrade **Reserved names stay blocked for offline players arriving through Connect, even when the proxy runs `onlineMode: true`.** Gate v0.71.16 blocks unsafe offline usernames, v0.73.0 scopes the offline username blacklist to Connect so direct-listener setups keep their own policy, and v0.73.13 fixes the case reported from a public endpoint, where an offline identity completed login under a reserved premium name with no kick — the check now reads whether the player is authenticated, not only the proxy's online-mode setting. Install [v0.73.13](https://github.com/minekube/gate/releases/tag/v0.73.13). * Gate Upgrade **Players joining through a premium Connect tunnel keep their authenticated identity, and their login no longer hangs.** [v0.73.12](https://github.com/minekube/gate/releases/tag/v0.73.12) stops Gate's accepted-connection wrappers from hiding the identity Connect had already authenticated, which made Gate treat the player as unauthenticated and send a Java EncryptionRequest into the tunnel. ## September 10, 2026 * GeyserLite Upgrade **GeyserLite keeps up with current Bedrock clients.** v0.5.22, v0.5.26 and v0.5.27 each carry a new upstream Geyser revision (Gate [v0.73.10](https://github.com/minekube/gate/releases/tag/v0.73.10) bundles v0.5.27); install [v0.5.27](https://github.com/minekube/geyserlite/releases/tag/v0.5.27), which contains them all with builds attached. v0.5.23 and v0.5.24 repaired the release pipeline that had published some releases without downloadable assets, and v0.5.25 shipped without builds — do not pin it. ## September 4, 2026 * Gate Upgrade **Gate stops running with a dead Bedrock listener.** [v0.72.6](https://github.com/minekube/gate/releases/tag/v0.72.6) surfaces unexpected managed GeyserLite exits and bridge-listener failures from the Bedrock runtime, so Gate and Moxy exit and their supervisor can restart them, instead of keeping healthy Java and HTTP health endpoints while the public Bedrock listener is gone; config reloads fail closed rather than leaving Bedrock absent. ## September 3, 2026 * Connect plugin Upgrade **Configs without a Bedrock-identity section get safe defaults, and an existing `config.yml` loads again on Velocity.** 0.15.10 fills the missing Bedrock-identity section with safe Minekube metadata defaults and warns the operator while leaving explicit sections — including quoted YAML keys — untouched; 0.15.11 fixes a crash 0.15.10 introduced on Velocity, where having any `config.yml` failed the load with a misleading "delete the config file" message. Install [0.15.11](https://github.com/minekube/connect-java/releases/tag/0.15.11), which contains both; do not pin 0.15.10 on Velocity. ## August 24, 2026 * Connect plugin Upgrade **Bedrock identity handling is safer on multi-injector servers and survives plugin reloads.** Connect 0.15.4 scopes Bedrock principal admission to Bedrock connections, 0.15.6 recovers the admission coordinator after a plugin reload instead of dropping Bedrock joins, 0.15.8 shares one coordinator across all injectors, and 0.15.9 applies an interim default that generates a version-0 Bedrock principal with a warning until the next identity producer ships. Install [0.15.9](https://github.com/minekube/connect-java/releases/tag/0.15.9). * GeyserLite Upgrade **GeyserLite tracks current Bedrock clients again through a long chain of upstream compatibility updates.** Releases v0.5.3 through v0.5.21 (August 9–24) pull in repeated Geyser protocol updates; install [v0.5.21](https://github.com/minekube/geyserlite/releases/tag/v0.5.21), which contains them all with builds attached. Several intermediate releases were published without downloadable builds and should not be pinned. * GeyserLite Upgrade **Player skins decode without AWT, which unblocks the native-image builds.** v0.5.10 decodes skins without AWT, and v0.5.21 removes AWT from the skin provider's class initialization so native releases can ship again; install [v0.5.21](https://github.com/minekube/geyserlite/releases/tag/v0.5.21). ## August 22, 2026 * Craftless Upgrade **Craftless CLI and daemon fixes in [v0.3.7](https://github.com/minekube/craftless/releases/tag/v0.3.7):** the CLI preserves schema-defined string request fields, the daemon runs the newest packaged client lane inside Docker, and latest-Fabric canary failures now report the actionable cause instead of a bare failure. ## August 21, 2026 * Connect plugin Upgrade **Session proposals report the real rejection reason, and endpoints without an org are admitted under Bedrock identity enforcement.** Connect 0.15.7 logs the exception message when a session proposal is rejected and admits org-less endpoints; 0.15.5 preserves tunnel delivery and late wrappers. Install [0.15.9](https://github.com/minekube/connect-java/releases/tag/0.15.9), which contains both. ## August 17, 2026 * Gate Upgrade **Gate applies the linked Floodgate Java identity on its direct listener.** [v0.71.3](https://github.com/minekube/gate/releases/tag/v0.71.3) fixes Bedrock players with a linked Java account joining through Gate's direct listener, and v0.71.2 also updates Gate's bundled GeyserLite to v0.5.11; install v0.71.3, which contains both. ## August 8, 2026 * Connect plugin Upgrade **Managed Bedrock identity is now zero-config and understands Connect's signed principal v2.** Releases 0.14.0 and 0.15.0 added generated verifier defaults and the newer identity protocol; 0.15.1 then isolated stale Watch proposals but was superseded after its release assets changed during a retry. Install [0.15.3](https://github.com/minekube/connect-java/releases/tag/0.15.3), which contains all three changes with stable published artifacts. * Connect plugin Upgrade **Login plugins can cooperate with Connect without hanging authenticated players or replacing their skin data.** Connect 0.13.0 published a stable `connect-player` channel marker and 0.13.1 re-asserted Connect's login decision after premium-autologin plugins; install [0.15.3](https://github.com/minekube/connect-java/releases/tag/0.15.3), which contains both changes. The [login-plugin guide](/guide/login-plugins) documents the remaining ordering limits. * Connect plugin Upgrade **Spigot now reports useful diagnostics when a server update changes the internal mappings Connect needs.** Added in 0.12.7 and included in [0.15.3](https://github.com/minekube/connect-java/releases/tag/0.15.3). ## August 7, 2026 * Gate Upgrade **Current Bedrock clients can join Gate again, and Connect-routed Bedrock identity uses the frozen signed-principal protocol without logging raw identities.** Upgrade to [Gate v0.71.1](https://github.com/minekube/gate/releases/tag/v0.71.1), which contains the identity work from v0.71.0 and the current-client compatibility fix. * GeyserLite Upgrade **GeyserLite exposes verified Bedrock ingress to embedded and subprocess consumers and includes the latest upstream Bedrock compatibility fixes.** The authenticated ingress API shipped in v0.5.0 and the upstream compatibility updates followed in v0.5.1 and v0.5.2; install [v0.5.2](https://github.com/minekube/geyserlite/releases/tag/v0.5.2). ## August 4, 2026 * Connect Live **Every Connect endpoint now accepts Microsoft/Xbox-authenticated Bedrock players without requiring a linked Java account by default.** An authoritative link still preserves the linked Java identity; an unlinked player receives a stable native Bedrock/XUID-derived identity. Offline/cracked Bedrock remains unsupported, and cracked Java remains a separate endpoint opt-in. Deployed across the hosted Connect service on August 4. (Internal repository, no public link.) ## July 26, 2026 * Connect Live **Minecraft 26.2 players can join the Minekube hub again.** They could not join between June 16 and July 26: the hub backend was still running a 26.1 protocol build while the edge accepted 26.2 connections. Server-list pings kept looking healthy throughout, because the Connect edge answers pings itself. Fixed and deployed on July 26. (Internal repository, no public link.) * Gate Upgrade **Gate v0.68.31 contains a security fix for PROXY-protocol handling.** If you expose Gate directly, upgrade to [v0.68.31](https://github.com/minekube/gate/releases/tag/v0.68.31). * Gate Upgrade **Three separate bugs that broke modded servers are fixed in [Gate v0.68.30](https://github.com/minekube/gate/releases/tag/v0.68.30):** large mod registry payloads over 1 MiB no longer kill the connection, Forge clients no longer lose their hostname when routed through a second proxy, and Gate Lite now warns you when it is ignoring `forwarding`, `onlineMode` or `servers` settings instead of silently accepting them. * Gate Upgrade **[Gate v0.68.30](https://github.com/minekube/gate/releases/tag/v0.68.30) updates its bundled GeyserLite to v0.4.9.** Gate shipped GeyserLite v0.3.17 from June 30 to July 26 while GeyserLite itself reached v0.4.9, so self-hosted Gate carried a stale Bedrock runtime for that period. * Gate Did not work **Managed GeyserLite for self-hosted Gate Lite did not start, and as at July 26 the underlying startup failure was still open.** It could not complete its Minecraft data download, so no Bedrock listener came up. It was changed on July 26 to fail immediately with an error telling you to point it at a prebuilt GeyserLite binary, instead of hanging your proxy startup for ten minutes with no explanation. (Internal repository, no public link.) * Connect Live **Bedrock players with a Microsoft/Xbox account but no linked Java account can now be admitted to a Connect endpoint.** As shipped on July 26, it was off by default and enabled per endpoint by Minekube on request; refused joins reported a reason instead of timing out with a bare network error. The policy later became the default for every endpoint on August 4. (Internal repository, no public link.) * Connect Live **Connect endpoint status pings could stop resolving on a proxy machine after a network interruption** and stay broken until that machine restarted. Fixed and deployed on July 26. (Internal repository, no public link.) * Connect Live **A Connect endpoint could keep reporting healthy while no player joins reached it.** The dashboard, heartbeat and tunnel all showed the endpoint as active, but every join failed with an internal connection error, once that machine's internal message transport had reached a permanently closed state. A machine in that state now releases its endpoint session, so your connector moves to a healthy one. Fixed and deployed on July 26. (Internal repository, no public link.) * Connect plugin Upgrade **The Connect plugin supports ViaVersion 5.x legacy initializer unwrapping on Spigot** in [0.12.4](https://github.com/minekube/connect-java/releases/tag/0.12.4). ## July 25, 2026 * Gate Upgrade **[Gate v0.68.29](https://github.com/minekube/gate/releases/tag/v0.68.29) updates its bundled gRPC library to a release carrying an upstream security fix.** If you self-host Gate, upgrade. This is a separate change from the PROXY-protocol security fix in v0.68.31; Gate v0.68.31 and later contain both. ## July 24, 2026 * Connect plugin Upgrade **The Connect plugin failed to load.** It failed to load on Paper (0.12.0), failed to start its endpoint on Spigot/Purpur (0.12.1), and failed to load at all on Velocity 4.0.0 (0.12.2). All three were regressions introduced in 0.12.0 and are fixed in [0.12.3](https://github.com/minekube/connect-java/releases/tag/0.12.3); update to [0.12.4](https://github.com/minekube/connect-java/releases/tag/0.12.4). * Gate Upgrade **Chat and commands were being rejected on Minecraft 1.20.5+ clients connecting through Gate**, with `Last seen update ignored previously acknowledged message at index N`. Direct connections were unaffected. Fixed in [v0.68.28](https://github.com/minekube/gate/releases/tag/v0.68.28). ## July 19, 2026 * Gate Upgrade **Gate Lite status handling ([v0.68.27](https://github.com/minekube/gate/releases/tag/v0.68.27)):** cached status responses keep their full expiry window, stale Via bridge requests are skipped on retry, and status-response failures are now logged instead of failing silently. ## July 15, 2026 * Connect plugin Upgrade **The Connect plugin can verify the signed Bedrock identity that Connect attaches to a Bedrock session.** Verification is off by default with `warn` and `require` modes, sessions with a missing or invalid identity are rejected once you turn it on, verifier keys can be pinned directly or fetched from a metadata URL, and trusted Bedrock sessions are recognised. Built across [0.8.0](https://github.com/minekube/connect-java/releases/tag/0.8.0), [0.9.0](https://github.com/minekube/connect-java/releases/tag/0.9.0), [0.10.0](https://github.com/minekube/connect-java/releases/tag/0.10.0) and [0.12.0](https://github.com/minekube/connect-java/releases/tag/0.12.0). You need a current public key from Minekube before enabling it. ## July 13, 2026 * GeyserLite Upgrade **GeyserLite can trace Bedrock packets for debugging, off by default,** in [v0.4.0](https://github.com/minekube/geyserlite/releases/tag/v0.4.0). ## July 12, 2026 * Connect plugin Upgrade **The Connect plugin exposes a health endpoint for its Connect watcher,** so monitoring can check it directly, in [0.11.0](https://github.com/minekube/connect-java/releases/tag/0.11.0). ## July 7, 2026 * Connect Live **Connect reliability work through June and early July:** browser-hub fallback after endpoint kicks, endpoint sessions kept during server switches, authorized transfers while the current server is unavailable, cached endpoint status pings, and custom-domain routes loaded before serving. (Internal repository, no public link.) * Craftless Upgrade **Stopping an official Fabric client now actually terminates it.** It previously reported success while leaving the Minecraft process running. The CLI installer also now includes the latest official lane. Both were tagged v0.3.5, which was published with no downloadable build; install [v0.3.6](https://github.com/minekube/craftless/releases/tag/v0.3.6) instead, which contains both fixes and has builds attached. ## July 4, 2026 * Connect plugin Upgrade **The Connect plugin's token error message now points at the token file you need to fix** in [0.7.11](https://github.com/minekube/connect-java/releases/tag/0.7.11). ## July 2, 2026 * Gate Upgrade **Config plugin messages are queued during backend login instead of dropped** ([v0.68.22](https://github.com/minekube/gate/releases/tag/v0.68.22)). * Connect plugin Upgrade **The Connect plugin explains why Connect rejected its credentials** instead of reporting a bare authentication failure, in [0.7.10](https://github.com/minekube/connect-java/releases/tag/0.7.10). * Craftless Upgrade **Three Craftless CLI and daemon fixes, tagged v0.3.1 — a release that has no downloadable build and cannot be repaired, so install [v0.3.6](https://github.com/minekube/craftless/releases/tag/v0.3.6), which contains them:** the CLI defaults the daemon workspace instead of requiring one, ambiguous API help lists every matching method, and the daemon reports connection attempts it never observed. ## July 1, 2026 * Connect Live **Opening a Connect endpoint tunnel could fail before the request ever reached Connect.** When the machine that received the request was not the machine holding your endpoint's session, the request was rejected upstream instead of being handed over, so tunnels and the joins that depend on them failed while the endpoint itself looked healthy. Those requests are now passed directly to the machine holding the session. Fixed and deployed on July 1. (Internal repository, no public link.) * Craftless Upgrade **Craftless reports which Fabric runtimes it supports and refuses targets it cannot run.** Fabric runtime and loader support targets are exposed in the loader matrix, unsupported or undiscovered targets are rejected with a structured error, and a headless launch that cannot be satisfied now stops immediately instead of starting. All were tagged v0.3.0, a release that has no downloadable build and cannot be repaired; install [v0.3.6](https://github.com/minekube/craftless/releases/tag/v0.3.6), which contains them. ## June 30, 2026 * Connect plugin Upgrade **The Connect plugin's websocket tunnel connections now reach the machine that holds your endpoint session.** When the tunnel address named a specific machine, the plugin did not pass that along, so the connection could land elsewhere and fail. Fixed in [0.7.9](https://github.com/minekube/connect-java/releases/tag/0.7.9). ## June 29, 2026 * Connect plugin Upgrade **The Connect plugin's peer-to-peer networking no longer shares Netty internals with your server,** removing a class of interference between the two, and Velocity chat sessions now survive the reconfiguration step during a Connect tunnel join. Both in [0.7.8](https://github.com/minekube/connect-java/releases/tag/0.7.8). * Craftless Upgrade **Craftless gets a documentation site, version discovery and a screenshot API.** v0.2.0 publishes the docs site, reports which runtime versions it can run and defaults to the latest, adds an API for generated screenshot artifacts, and routes every CLI invocation through that API instead of a second code path; that release has no downloadable build and cannot be repaired, so install [v0.3.6](https://github.com/minekube/craftless/releases/tag/v0.3.6), which contains all of it. Earlier the same day, [v0.1.2](https://github.com/minekube/craftless/releases/tag/v0.1.2) added `latest-release` and `latest-snapshot` as Minecraft version aliases, a `--loader-version` option when creating a client, and `--help` for each command group. ## June 28, 2026 * Craftless Upgrade **Craftless finds and picks a Java runtime for you.** `craftless runtimes java list` reports the runtimes it discovered on your `PATH`, `craftless runtimes java resolve --mc ` tells you which one it would use for a given Minecraft version, and the choice is recorded in the workspace cache so launches stay repeatable. In [v0.1.1](https://github.com/minekube/craftless/releases/tag/v0.1.1). ## June 26, 2026 * Gate Upgrade **Gate adopts modern Common text components**, modernising text rendering across Gate ([v0.68.2](https://github.com/minekube/gate/releases/tag/v0.68.2)). * Craftless Upgrade **Craftless is public.** [v0.1.0](https://github.com/minekube/craftless/releases/tag/v0.1.0) is the first public release of our Minecraft client automation framework. It launches or attaches to real Minecraft Java clients — headless for unattended runs, or with the game window visible so you can watch — and exposes each running client as a generated local OpenAPI document, so agents, tools and CI drive the real client without a hand-maintained catalogue of gameplay commands. Ships as an install script for Linux and macOS, a runtime container image, and a GitHub Actions setup action. ## June 23, 2026 * Gate Upgrade **Gate can route dynamic servers through a managed Via runtime** ([v0.68.0](https://github.com/minekube/gate/releases/tag/v0.68.0)), using the ViaLite auto-latest subprocess runtime ([v0.67.0](https://github.com/minekube/gate/releases/tag/v0.67.0)). From [v0.68.14](https://github.com/minekube/gate/releases/tag/v0.68.14) Gate also skips ViaLite when the backend protocol already matches. [ViaLite v0.3.0](https://github.com/minekube/vialite/releases/tag/v0.3.0) supports embedded dynamic backends. ## June 22, 2026 * Gate Upgrade **Keepalive handling is stabilised across server switches and transitions** — players were being timed out during transfers. Fixed across releases up to [v0.66.36](https://github.com/minekube/gate/releases/tag/v0.66.36). * GeyserLite Upgrade **GeyserLite could crash during Bedrock network cleanup.** The released native builds were missing a runtime option their networking layer needs, so cleanup could kill the process with an unsupported-feature error. Fixed in [v0.3.14](https://github.com/minekube/geyserlite/releases/tag/v0.3.14). ## June 21, 2026 * Connect plugin Upgrade **The Connect plugin no longer disconnects chat on newer Paper builds** (`NoSuchMethodException: LastSeenMessages.`), fixed in [0.7.7](https://github.com/minekube/connect-java/releases/tag/0.7.7). * GeyserLite Upgrade **GeyserLite's native builds failed from June 18 to June 21, and again in July.** Releases published without downloadable builds should not be pinned; whether a given release has them is shown on its [release page](https://github.com/minekube/geyserlite/releases), which is where to check before you pin a version. Separately, signing changed at [v0.3.10](https://github.com/minekube/geyserlite/releases/tag/v0.3.10): one `.sigstore.json` bundle per artifact replaced the separate `.sig` files. ## June 17, 2026 * Gate Upgrade **Gate installs on musl-based Linux (Alpine)** ([v0.66.27](https://github.com/minekube/gate/releases/tag/v0.66.27)). ## June 13, 2026 * Connect plugin Upgrade **The Connect plugin works on newer Velocity and Netty builds again.** Connect's tunnel channels and Velocity's backend channels were running on incompatible event-loop models; [0.7.6](https://github.com/minekube/connect-java/releases/tag/0.7.6) bridges them. ## June 8, 2026 * Gate Upgrade **Gate's arm64 image could not start managed Bedrock support.** It downloaded GeyserLite and then exited immediately, because the image was missing a library the downloaded executable needs; read-only containers reported a misleading "binary not found" instead, because there was nowhere to write the download. [v0.66.7](https://github.com/minekube/gate/releases/tag/v0.66.7) adds the missing library and a writable cache location for downloaded components. * GeyserLite Upgrade **The published arm64 container image could not run GeyserLite, and failed downloads were reported as a missing binary.** The arm64 image lacked the C runtime the executable needs, and the locator discarded the real reason a download failed — an unsupported platform, a read-only cache, a network error — reporting only that no binary was found. Both fixed in [v0.2.7](https://github.com/minekube/geyserlite/releases/tag/v0.2.7). * GeyserLite Upgrade **GeyserLite runs on Windows.** [v0.3.0](https://github.com/minekube/geyserlite/releases/tag/v0.3.0) publishes a Windows amd64 executable that the Go and Rust integrations can download automatically. Windows uses the separate-process mode; the embedded-library mode is Linux-only in this release. ## June 5, 2026 * GeyserLite Upgrade **GeyserLite's default network memory limit was too small for Bedrock chunk bursts.** The default cap on its off-heap networking buffers rises from 16 MB to 64 MB in [v0.2.5](https://github.com/minekube/geyserlite/releases/tag/v0.2.5), and the tuning guide's suggested limits for busy servers rise with it. If you set that limit yourself, review it. ## June 4, 2026 * Gate Upgrade **Gate's Docker images use glibc base images so the binary actually executes** ([v0.66.5](https://github.com/minekube/gate/releases/tag/v0.66.5)). --- --- url: https://connect.minekube.com/plans.md description: Minekube Connect plans and pricing philosophy. ---