Geyser and Floodgate: Bedrock players on a Java server

Java and Bedrock are two different programs speaking two different network protocols, and nothing in either of them lets a phone join a Paper server. Geyser is a translator that sits in front of your Java server and speaks Bedrock to one side and Java to the other. Floodgate is the companion that lets those Bedrock players in without owning a Java account. Together they work well enough that most players never notice - but there are three things you have to get right first: a second port allocation, and it must be UDP; the auth-type that ties Geyser to Floodgate; and a clear idea of which features quietly do not cross over. This post covers all three, on a Paper server, which is what RE:NODE's Minecraft line runs.

What Geyser and Floodgate each do#

They are separate plugins, they solve separate problems, and you can run Geyser without Floodgate.

Geyser translates protocol. A Bedrock client speaks RakNet over UDP with its own packet format; a Java server speaks its own format over TCP. Geyser accepts the Bedrock connection, converts every packet in both directions, and presents the player to the Java server as an ordinary client. It is a GeyserMC project, free and open source, with builds for Paper and Spigot, Velocity, BungeeCord, Fabric, NeoForge, Sponge and a standalone jar.

Floodgate handles identity. Without it, a Bedrock player still needs a paid Java account to authenticate with Mojang, which defeats the point. Floodgate makes the Java server accept the Bedrock player's Xbox authentication instead, so someone with only a Bedrock copy of the game can join a server that is still in online mode for everyone else. This is the part that matters: it means you do not have to set online-mode=false, which would let anyone connect as anyone.

Run the plugin build of Geyser on the Java server itself where you can. The alternative, standalone Geyser pointed at a remote Java server, needs either a Java account per player or Floodgate configured on both sides with a shared key, and it adds a network hop for no benefit when both halves live on the same machine. On a proxy network, Geyser and Floodgate go on the proxy, and Floodgate also goes on each backend - the wiring is in building a Minecraft network with Velocity.

The extra UDP port#

This is the step people miss, and the symptom is a server that runs perfectly for Java players while every Bedrock player sees "Unable to connect to world".

Two different protocols on two different numbers means two allocations. Even if you chose the same number for both, TCP 25565 and UDP 25565 are separate things to a firewall, and a rule that opens one does not open the other. The general version of this is in game server ports explained.

19132 is the default because it is what a Bedrock client fills in for you. If you get that number, players type an address and nothing else. If you get some other number, every player has to put it in the Port field by hand, and a surprising share of them will not.

RE:NODE's Minecraft plans come with one allocation, which is the Java port. Add a second on the Network tab, note the number it gives you, and put that number into Geyser's bedrock.port. The address is the same host as your Java port; only the number and the protocol change.

There is one more limitation worth being honest about before you promise anything. Windows, Android and iOS Bedrock clients can add a server by address and port. Console clients - Xbox, PlayStation, Switch - cannot add external servers through the interface at all. Players get around it with third-party DNS tools that replace the featured server list, which work until they do not, and which you neither run nor control. Plan for console players to need help, and do not advertise console support as though it were a feature of your server.

Installing on Paper#

1. Download the Spigot build of Geyser and the Spigot build of Floodgate from geysermc.org. The Spigot builds are the right ones for Paper.
2. Upload both jars to plugins/ through the file manager or over SFTP. There is no plugin installer on RE:NODE - you drop the jar in yourself, which also means nothing is blocked.
3. Start the server once. Geyser writes plugins/Geyser-Spigot/config.yml, Floodgate writes plugins/floodgate/config.yml and generates plugins/floodgate/key.pem.
4. Stop the server, edit Geyser's config as below, and start it again.
5. Watch the console for the line saying Geyser has started and which address and port it is listening on. If it says the port is in use, the allocation is wrong.

Do not use /reload to pick up these plugins. Geyser binds a socket at startup; reloading it mid-life is how you end up with a port that is held by nothing and cannot be rebound until a restart.

The config keys that matter#

Geyser's config is long and most of it can stay as it is. These are the ones with consequences.

bedrock:  address: 0.0.0.0  port: 19132  clone-remote-port: false  motd1: "A Minecraft Server"  motd2: "Java and Bedrock welcome"  server-name: "Geyser"remote:  address: auto  port: 25565  auth-type: floodgatepassthrough-motd: truepassthrough-player-counts: trueshow-cooldown: titleshow-coordinates: truemax-players: 100

remote.auth-type is the one that breaks installs. Leave it as online with Floodgate installed and Bedrock players are asked to authenticate with a Java account they do not have. Set it to floodgate and Geyser trusts Floodgate's verified Xbox identity instead. When Geyser and Floodgate are plugins on the same server, Geyser finds the key file on its own; for standalone Geyser or Geyser on a proxy, copy plugins/floodgate/key.pem from the Java server into Geyser's folder, and treat that file like a password, because anyone holding it can forge a login.

Floodgate's own config is short. username-prefix defaults to ., replace-spaces defaults to true, and player-link controls account linking. Turn on the option that lets players link their own accounts on your server if you want a Bedrock player and a Java player to share one profile; the old global linking service that did this centrally is no longer available, so links are per-server data now.

Names, UUIDs, whitelists and permissions#

Floodgate gives each Bedrock player a username and a UUID derived from their Xbox identity, and both are visibly different from a Java player's.

• The name gets a prefix. Steve on Bedrock arrives as .Steve. The prefix exists so a Bedrock player cannot take a Java player's name, and it is worth keeping for exactly that reason. Bedrock gamertags may contain spaces, which replace-spaces turns into underscores.
• The UUID starts with zeros. Floodgate UUIDs have a distinctive leading run of zeros, so you can tell one apart at a glance in a log line or a database row. Because it is derived rather than random, it is stable across rejoins, and permissions and plugin data stick to the player properly.

The practical consequence is the whitelist. whitelist add .Steve from the console asks Mojang's API to resolve that name, Mojang has never heard of it, and the command fails. Two ways round it: let the player attempt to connect once, take the UUID Floodgate logs, and add the entry to whitelist.json by hand with the server stopped; or use a permission-based whitelist plugin that works from the player object rather than a name lookup.

[  { "uuid": "00000000-0000-0000-0009-01f1b2c3d4e5", "name": ".Steve" }]

Permissions themselves behave normally. A Floodgate player is a player, so a LuckPerms group applies the same way it does to anyone else - the LuckPerms guide applies unchanged. What you may want is a group specifically for Bedrock players, so you can grant anti-cheat exemptions or a different set of commands to the people whose movement packets look odd.

What does not translate#

Geyser is a very good translation layer over two games that genuinely differ. These are the gaps that produce support tickets.

• Resource packs. A Java pack set with resource-pack= in server.properties does nothing at all for a Bedrock client, because Bedrock uses a different pack format. Geyser can send Bedrock .mcpack or zipped packs from its packs/ folder instead, which means maintaining two packs if you want parity. Details of the Java side are in MOTD, server icon and resource packs.
• Custom items and models. Anything built on CustomModelData needs a matching Bedrock pack and item mappings before a Bedrock player sees more than a stick. Plan for this before you build a server around custom items.
• Combat. Bedrock has no attack cooldown; Java does. Geyser emulates the cooldown and draws an indicator, but the feel is different and the timing is not identical. On a PvP server this is the difference between a fair fight and a complaint thread.
• Inventory interactions. Chest menus and most plugin GUIs work. Anvils, enchanting tables, beacons and anything relying on a precise click type are the usual sources of small, weird bugs.
• Movement, and therefore anti-cheat. Bedrock's movement is not Java's, and anti-cheat plugins flag it. Every mainstream anti-cheat has a bypass permission; give it to your Bedrock group, or accept the false kicks. Grief protection and anti-cheat covers choosing one.
• Client mods. Bedrock players cannot install Fabric mods, shaders or a minimap. If your server assumes a modded client, it is a Java-only server whatever Geyser says.

None of this is a reason not to run Geyser. It is a reason to test the specific things your server depends on with an actual Bedrock client before you announce crossplay.

What it costs, and keeping up with versions#

Geyser is doing real work per packet, in the same JVM as your server. Two Bedrock players are more expensive than two Java players: more CPU for translation, and more heap for the per-session state Geyser holds.

• Memory. Budget extra on top of what the server itself needs. A 2 GB plan running Paper with a handful of plugins is already tight, and adding Geyser to it is the kind of decision that shows up later as an out-of-memory restart. 4 GB is a more comfortable floor for a mixed server of any size; how much RAM a Minecraft server needs has the wider table.
• CPU. Translation is per-packet and mostly off the main thread, but it is not free, and the container's CPU share is a hard limit rather than a suggestion.
• Versions. Geyser targets the newest Bedrock release and usually supports only that one, sometimes the previous one as well. Bedrock clients update themselves. That combination means that on Bedrock release day your Bedrock players can be locked out until you replace the Geyser jar, and there is nothing you can do to stop their clients updating. Geyser also targets the current Java version; to run an older Java server behind it, add ViaVersion to the Java side.

The update itself is a one-minute job: stop the server, replace Geyser-Spigot.jar, start it. /geyser version reports whether a newer build exists. Updating Geyser without also updating Floodgate occasionally causes a key or protocol mismatch, so replace both when you replace either.

Troubleshooting#

"Unable to connect to world" on every Bedrock client. The port. Check three things in order: the allocation exists and is UDP, bedrock.port matches it exactly, and Geyser actually bound it - the console prints the address and port at startup. A Bedrock client also caches a saved server entry; delete the entry and add it again after changing the port.

Bedrock players are asked to log in with a Java account. remote.auth-type is still online. Set it to floodgate and restart.

"Failed to verify Floodgate data" or an invalid key error. Geyser and Floodgate are reading different key.pem files. On a single server, delete Geyser's copy and let it find Floodgate's. On a proxy, copy the proxy's key to every backend.

Bedrock players are kicked for an outdated client or server. A protocol mismatch after a Bedrock update. Update Geyser.

The Bedrock list shows the wrong MOTD or a fake player count. passthrough-motd and passthrough-player-counts are still false, so it is showing motd1 and motd2 from Geyser's own config.

Everything works but Bedrock players are randomly kicked. Anti-cheat, nine times out of ten. Turn the anti-cheat off for one session to confirm before you spend an evening on anything else.

You need help. /geyser dump produces an uploadable description of your configuration and versions, and recent builds have /geyser connectiontest, which checks from the outside whether your Bedrock port is reachable. Both are worth running before you open a support thread.

FAQ#

Do Bedrock players need to buy Minecraft Java?

No. That is exactly what Floodgate is for. Without Floodgate, Geyser alone still requires every Bedrock player to own and authenticate with a Java account, which is almost never what anyone wants.

Can I run Geyser instead of hosting a separate Bedrock server?

Yes, and for most communities it is the better answer: one world, one plugin set, one backup, everyone in the same place. A native Bedrock server is the right call only when your players are Bedrock-only and you want Bedrock add-ons - the trade-offs are in Bedrock or Java: which server you are running.

Does Geyser work with plugins?

Mostly, because plugins talk to the Java server and never see Geyser. Anything that sends raw Java packets, custom models or precise inventory clicks is where it gets interesting. Test the ones your server is built on.

Do I need online-mode=false?

No, and you should not. Floodgate exists so the server stays in online mode while accepting verified Xbox identities as well. Turning off online mode lets anybody connect under any username, which is a different problem entirely.

Can Xbox, PlayStation and Switch players join?

Technically the protocol is identical, so Geyser serves them fine. The obstacle is the client interface, which offers no way to type in a server address. Players use third-party workarounds to get around that, and those are outside your control and can break at any time.