Geyser and Floodgate: letting Bedrock players onto a Java server

Java and Bedrock Edition speak different protocols over different kinds of connection. A Java server listens on TCP, port 25565 by default, while Bedrock clients connect over UDP, to 19132 by default. Geyser listens on that UDP port and translates, so each Bedrock player reaches your server looking like a Java client. Floodgate, installed alongside it, lets them in without owning Java Edition.

Geyser's FAQ says it "emulates a Minecraft: Java Edition client", so the server never needs to know Bedrock exists. That is why a plugin can add crossplay to an ordinary Paper server, and also why it only works one way: Java players cannot use it to reach Bedrock servers. Why the two editions cannot share a server is a separate story.

Where Geyser runs

The download page offers builds for Spigot/Paper, Velocity, BungeeCord, Fabric, NeoForge and ViaProxy, plus a standalone version that sits in front of any Java server. The plugin build needs Spigot or Paper on 1.20.5 or later, running on Java 21 or newer. The Fabric and NeoForge builds only support the latest Minecraft release.

Versions are the part that bites. Geyser emulates exactly one Java version (26.2 in Geyser 2.11.3, current at the end of September 2026) and accepts a range of Bedrock versions (26.30 to 26.51 in that release). Older servers can accept the emulated client through ViaVersion, as the supported-versions page explains, but the page says nothing about servers newer than Geyser, and Java 26.3 came out on 15 September 2026 without Geyser support. Hold Java updates until Geyser supports the release.

Floodgate, and players without Java Edition

Without Floodgate, Geyser asks each Bedrock player to sign in with a Java Edition account, which most of them do not have. Floodgate removes that step. Players still need an Xbox account, which Floodgate uses to authenticate them.

Two things tie the pair together. Geyser's auth-type setting must read floodgate; since Geyser 2.9.0 it lives in the config's java section, which older configs call remote. And Floodgate generates a key.pem that encrypts the Bedrock player data Geyser passes on. Floodgate's setup guide says in capitals not to distribute it, because this key is what lets Bedrock accounts bypass Java authentication. Keep it out of shared folders and public repositories.

Players who own both editions can link them through Global Linking, which Floodgate enables by default. They join link.geysermc.org on both accounts, type /linkaccount on one and enter the code it gives with /linkaccount <code> on the other. Once linked, they play with the Java account's inventory and position from either device.

The port, and what can share it

Open UDP 19132 in the router and in the host's firewall, as the Geyser setup guide says. A TCP rule for the Java port does nothing for Bedrock (port forwarding, step by step).

Hosts that give you a single port can still carry both editions, because Java uses it over TCP and Bedrock over UDP. The plugin's clone-remote-port option copies the Java port to the Bedrock listener at every start. The guide then warns that other services relying on UDP, "such as Voice Chats or Query", cannot share the port with Geyser. Vanilla query listens on UDP 25565 when enable-query is on, so move it with query.port or leave it off.

This is starting to change. Bedrock is moving from RakNet, the UDP-based protocol it has used until now, to a newer connection method called NetherNet, and Geyser 2.11.3 added a transport setting in its bedrock section. The default is still raknet, which the config calls "the now deprecated connection method". With NetherNet and Geyser's built-in signalling, the Bedrock port is also used over TCP, and the config says that mode cannot run on the same port as the Java server. Read Geyser's release notes before each Bedrock update.

What your plugins see

Floodgate gives each Bedrock player a Java-style name and UUID. The name is the gamertag with a prefix, a dot by default (username-prefix: "."), and with spaces turned into underscores (replace-spaces: true). The prefix stops clashes with Java players of the same name, and Floodgate's FAQ advises against removing it unless you are sure no two players will ever share one. The UUID is built from the player's Xbox ID and begins 00000000-0000-0000-, which makes Bedrock players easy to pick out of logs and databases.

Whitelists trip people up most (what a whitelist actually keeps out). Vanilla /whitelist add expects a Java account name, so Floodgate has its own command: fwhitelist add <gamertag>, without the prefix, run on the game server rather than the proxy. It only works once the player has joined any Geyser server. The FAQ's fallbacks are to turn the whitelist off, let the player join, run /whitelist add ".gamertag" and turn it back on, or to paste the Floodgate UUID into whitelist.json and run /whitelist reload.

Permission plugins need one change. Floodgate's troubleshooting page tells LuckPerms users to set allow-invalid-usernames to true, since the dotted names are not valid Java names. Linked players are the exception to all of this: they arrive as their Java account.

Putting it on a network

On a Velocity or BungeeCord network, the proxy is where Bedrock players arrive:

1. Install Geyser on the proxy only. The setup guide says this in bold, and every backend then has to accept the Java version Geyser emulates.
2. Install Floodgate on the proxy and set auth-type to floodgate. The Floodgate guide says that is enough unless you want the Floodgate API on the backends.
3. If plugins on the backends need to know who is on Bedrock, install Floodgate on each backend and turn on ip_forward (BungeeCord) or player information forwarding (Velocity). Then set send-floodgate-data: true in the proxy's Floodgate config.
4. Copy the proxy's key.pem into every backend's Floodgate folder, so they can read what the proxy sends.

Packs, menus and what does not translate

Geyser does not convert Java resource packs. Bedrock players get Bedrock packs, as .zip or .mcpack files dropped into Geyser's packs folder (plugins/Geyser-<platform>/packs/ on a plugin install). The force-resource-packs setting, on by default, makes clients accept them. Custom items and blocks need mappings plus a Bedrock pack, and Geyser points to tools such as Rainbow and Thunder for the conversion. Behaviour packs and add-ons are not supported.

The current limitations page lists what cannot be fixed. The entries that matter to most servers are chest menus that do different things on left and right click (Bedrock cannot tell the clicks apart) and anything that relies on tab completion or typing in the chat box. Clickable links in chat, custom enchantments and builds more than 512 blocks above or below zero in the Overworld also fail.

Anticheat

Bedrock clients move and fight differently, and Geyser's README still lists "Near-perfect movement" as unfinished work. Its community-compiled compatibility page sorts anticheats three ways. Full compatibility means Bedrock players are checked accurately (Boar and Themis). Partial means "Does not Check/Ignores Bedrock Players" (GrimAC is one). Incompatible means false positives, and NoCheatPlus is listed there. A partial entry therefore leaves Bedrock players unchecked. Each entry has a "last checked" date, some from 2024, so test your own anticheat setup with a Bedrock client before opening up.

What Bedrock players will still notice

Even on a well-run server, Bedrock players see a dot in front of their names in chat and on the tab list. They get a pack download before they can play, chest menus that cannot tell a left click from a right, and trouble with any command that leans on tab completion. Test each of those with a phone or console before you advertise crossplay. Then put the Bedrock port in your description next to the Java address, because Bedrock asks for the two separately. Console players need a workaround to reach any third-party server, which crossplay and server lists covers, and the Minecraft servers already listed show how others word it.