GeyserMC/Geyser: Letting Bedrock Clients Join Java Edition Servers

The cross-play gap Geyser targets

Minecraft: Bedrock Edition and Minecraft: Java Edition speak different network protocols. A Bedrock client cannot open a connection to a Java Edition server and expect anything to work, because the packets, entity identifiers and world data formats do not line up. Geyser sits in the middle as a proxy and performs that translation. The README describes it as "a proxy, bridging the gap between Minecraft: Bedrock Edition and Minecraft: Java Edition servers" with the stated goal of letting Bedrock users join Java servers "as seamlessly as possible."

The audience is specific: server operators who already run a Java Edition world and want Bedrock players in it, rather than people starting a new server from scratch. Geyser does not create a world of its own. It forwards to an existing Java server, which means the Java side stays authoritative. That is the design decision that matters most, and it also explains why the project's limitation list is long.

How packet translation works between the two editions

The repository is split into modules rather than shipped as one artifact. The top level contains ap/, api/, bootstrap/, common/, core/ and build-logic/, with a Gradle build driven by build.gradle.kts and settings.gradle.kts. The bootstrap module is where platform-specific entry points live, which is why the README's compile instructions point at bootstrap/build for the output.

On the protocol side, Geyser depends on two external libraries: the CloudburstMC Bedrock Protocol Library for the Bedrock side and GeyserMC's own MCProtocolLib for the Java side. Translation happens between those two representations. Text handling goes through the Adventure Text Library, logging through slf4j, and the console through TerminalConsoleAppender. The README lists these under Libraries Used, so the dependency surface is documented rather than hidden.

The README's supported versions table pins Bedrock to a range from 26.30 through 26.51 and Java to 26.2, with a link to a guide for older versions. That table is the practical contract: a Bedrock client outside the listed range is not covered by the current build.

Installing Geyser and making a first connection

The README does not walk through installation. It says to "Take a look here" and links to the setup page at geysermc.org/wiki/geyser/setup/, and downloads live at geysermc.org/download. For most operators the practical route is a server-side plugin or mod, so start from the download page and pick the build matching your server software rather than compiling from source.

If you do want to build it yourself, the README gives these steps. Clone the repository, then initialize the submodules from the repository root:

git submodule update --init --recursive

The README calls this "a crucial step in this process" because the needed submodules are not included in a plain clone. Then build with the Gradle wrapper:

gradlew build

After the build finishes, the README says to locate the output in the bootstrap/build folder. Note that the wrapper is named gradlew on Unix-like systems and gradlew.bat on Windows.

For a first real test, the README names a public test server: connect a Java client to test.geysermc.org on port 25565, and a Bedrock client to the same host on port 19132. If your Bedrock client reaches that server, your client version and network path are working, and any remaining problem is on your own server's configuration rather than your setup.

Where Geyser breaks down

The README is unusually direct about this: "due to the nature of Geyser translating packets over the network of two different games, do not expect everything to work perfectly!" Under What's Left to be Added/Fixed it lists near-perfect movement, qualified as movement good enough that "anticheat on large servers is unlikely to ban you," plus some entity flags. That is an admission that movement translation is not finished.

The practical consequence is anticheat. A competitive or heavily policed Java server that flags unusual movement will treat a translated Bedrock client as suspect, and Geyser's own README frames the goal as making bans unlikely rather than impossible. There is also a separate Current Limitations page, and the README separates things that "can't be fixed" from things still pending, which tells you some gaps are structural rather than backlog items.

Geyser is also the wrong tool if you want a Bedrock-native experience. It does not add Bedrock features to a Java server; it maps one protocol onto another. Server-side plugins that assume Java-only client behaviour, or mods that require a matching client mod, will not translate.

Geyser compared with running two separate servers

The alternative most operators weigh is not another proxy but simply running a Java server and a Bedrock server side by side, each with its own world. That approach has no translation layer, so nothing is approximated: Bedrock players get real Bedrock mechanics and Java players get real Java mechanics. The cost is two worlds, two sets of plugins or add-ons, and no shared progress or chat unless you build that yourself.

Geyser takes the opposite position. One Java world stays authoritative, and Bedrock clients are adapted to it. You keep a single community and a single set of Java plugins, and you accept that some behaviour will be approximated. The README's own framing supports this reading: the project exists so Bedrock users can join Java servers, not so the two editions become equivalent. If shared state matters more than exact parity, Geyser is the shorter path. If exact parity matters more, two servers is the honest option.

Maintenance cost, licence and upgrade pressure

Geyser is MIT licensed, which is permissive and places few obligations on how you redistribute or modify it. The README ships a LICENSE file and an MIT badge. That is the extent of what the repository states; it is not legal advice, and if you redistribute a modified build you should read the licence text itself rather than rely on the badge.

The maintenance burden is real and comes from the version table. Bedrock is listed across a range of releases while Java is pinned to 26.2, and Minecraft updates on both sides on its own schedule. A Bedrock client update that falls outside the supported range is a support event, not something you can defer indefinitely. Compiling from source adds a second dependency: the submodule initialization step must be repeated when submodules move, and the build expects the Gradle wrapper rather than a system Gradle.

The last push to the repository was on 2026-09-20, two days before this writing, so the project is being worked on now. That does not change the arithmetic: you are tracking two upstream games, and Geyser has to keep up with both.

Editorial conclusion

Adopt Geyser if you run a Java Edition server and want Bedrock players on it without maintaining a second world, or if you are building a small cross-play community where occasional visual and behavioural gaps are acceptable. Do not adopt it if your server depends on Java-only mechanics, strict anticheat, or a modded client stack that Bedrock cannot reproduce. Before committing, read the current limitations page, confirm your server software has a matching Geyser bootstrap, and test movement and combat on your own hardware, since the README lists near-perfect movement as still unfinished.

Frequently asked questions

Official sources

1. GeyserMC/Geyser on GitHub
2. Issues
3. License: MIT
4. Project website
5. README