Minecraft Java and Bedrock crossplay with Geyser and Floodgate

Add Bedrock access to a working Java world by installing Geyser at the entry point and choosing authentication deliberately. Keep the Java server's existing login protection while testing the new path with one Bedrock player.

The example here uses one administrator-controlled Paper server, Geyser-Spigot and Floodgate-Spigot. It assumes Java players can already join and you have a stopped-server backup. It does not cover converting a client-required modpack into a console-compatible game.

Check versions before downloading plugins#

As checked on 20 October 2026, the Geyser compatibility page lists Bedrock 26.30–26.52 and a Java 26.3 client protocol. Record the actual Paper, Geyser, Floodgate and client versions you will use. Check that page again after a Bedrock update.

Geyser needs Java 21 or newer; your Paper release may require a newer runtime. Use the requirement for the complete combination, not Geyser's minimum alone. Consult Paper's installation documentation before changing the service's Java executable.

A Java backend that does not accept Geyser's emulated protocol needs an appropriate version bridge such as ViaVersion. That does not make every plugin or mod compatible with Bedrock. A mod requiring Java client installation remains a separate obstacle.

Put the bridge at the correct entry point#

For the single Paper server in this example, use the Paper/Spigot plugin downloads. Stop Paper cleanly, preserve the current plugins and configurations, then place the matching Geyser and Floodgate JARs in its plugins directory. Start once to generate their files and inspect startup errors before editing. Use the project's official download page.

If players already enter through Velocity, use the proxy build at that entry point instead. Do not install several independent public Geyser listeners accidentally. Standalone is another process with its own configuration and Java destination; placing its JAR in Paper's plugin folder is not that setup.

A proxy network needs authenticated forwarding and restricted backend access. Follow Velocity's security guidance before changing backend authentication. Its private-backend configuration is not a reason to expose an ordinary single Paper server in offline mode.

Preserve authentication and protect the key#

Floodgate allows authenticated Bedrock identities to enter without a separate Java account. For this Paper-plugin arrangement, follow the Floodgate setup instructions and set the generated Geyser configuration's java.auth-type to floodgate. Keep Paper's online-mode=true; changing it is not the fix for a mismatched bridge configuration.

Do not paste key.pem into a support ticket or a public configuration repository. Standalone needs the matching Floodgate key copied as documented; plugins on the same server do not need an arbitrary copied key from an old tutorial. Stop here if you cannot administer the destination: installing Geyser elsewhere does not give you permission to install Floodgate on someone else's server.

Before inviting everyone, verify the first Bedrock player's actual identity in the logs and apply allowlist and permissions to that identity. A familiar display name alone is insufficient evidence that an existing Java player's data will be reused.

Configure current Bedrock transport deliberately#

Edit the existing sections in plugins/Geyser-Spigot/config.yml; the following fragment is not a complete replacement file:

bedrock:
  port: 19132
  transport: nethernet
java:
  auth-type: floodgate

For this current NetherNet setup, port 19132 needs both TCP signaling and UDP gameplay. An older tutorial opening UDP alone is incomplete. NetherNet is fully supported by Bedrock 26.50 and newer; some older supported clients still fetch the MOTD and player count through RakNet. For that server-list compatibility, use transport: both; its separate webrtc-port must also be allocated and reachable over UDP. Check the current setup guide against the generated configuration before opening ports.

Keep the Geyser port separate from Paper's Java TCP port and other services. For containers, check port publishing as well as the host firewall, router and provider firewall. A reservation in a control panel does not prove that the process bound the required socket. Forwarding a port cannot repair upstream CGNAT.

For built-in signaling, configure HTTPS using a domain and certificate following Geyser's HTTPS instructions. A web reverse proxy can protect signaling while gameplay still needs its UDP path. Avoid treating a successful HTTPS response as a completed game connection.

Verify a player session before console discovery#

After a normal restart, enter these commands in the server console without a slash:

geyser version
geyser list

The command reference defines these diagnostics. Version output and a loaded plugin establish useful facts, but neither proves an external player can enter.

First use Windows Bedrock or a mobile client with the Bedrock address and port. Test from another network for internet access. Load the expected world, check normal permissions, change a harmless item position, disconnect and reconnect. During a maintenance window, stop and restart the server cleanly and confirm the player's state persists.

Then address consoles separately: their ability to select an arbitrary endpoint is a different problem. Follow the console connection guide rather than assuming installing Geyser adds an address field on Xbox, PlayStation or Switch.

Use the symptom to choose the next check#

Keep the previous JARs, configuration and a compatible world backup together. After updates, repeat the Bedrock join and identity checks. If rollback is necessary, restore a compatible set rather than mixing old plugins with an already-upgraded world. Preserve the failed startup log so the next change addresses a specific cause.