# PowerNukkitX is a Java server for Minecraft Bedrock Edition

> PowerNukkitX is an open source Minecraft Bedrock Edition server written in Java, with custom items, blocks and entities, vanilla-like mob AI, world generation and full command support. It suits server operators who want to run Bedrock clients and write plugins in Java, on the JVM rather than in a native binary.

**PowerNukkitX/PowerNukkitX** — Open-source, feature-rich Minecraft: Bedrock Edition server written in Java. Supports custom items, blocks, entities, full vanilla commands, advanced mob AI, and world generation. Not affiliated with Mojang AB.

- Repository: https://github.com/PowerNukkitX/PowerNukkitX
- Website: https://powernukkitx.org
- Stars: 682 · Forks: 210
- Language: Java
- License: LGPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/powernukkitx-powernukkitx

## A Bedrock server written for the JVM

PowerNukkitX is described as an open source, feature rich Minecraft Bedrock Edition server written in Java, and the emphasis on Java is the whole point of the project in a crowded field. Most Bedrock servers are written in C++, which makes them fast but means that plugin development requires learning a C++ API and compiling native modules. A Java server puts the plugin ecosystem in a language with a package manager, a debugger and a documentation culture that server operators already have. The project positions itself as feature-rich, highly customizable third-party server software for Minecraft: Bedrock Edition, and it is explicit that it is not affiliated with Mojang AB, which is a legal necessity rather than a boast, since Bedrock is proprietary and the protocol is reverse engineered. The repository topics list the lineage, with nukkit, pnx, mcbe, mcpe and mc-server among them, since this descends from the original Nukkit project. The audience is server operators who want to customise gameplay and write plugins, and the badge showing protocol 2193 and Minecraft v26.50 tells you which client version the current build targets.

## The feature list is about what you can change

Read the advertised feature list and a clear design intent emerges. There is custom item, block and entity support, vanilla-like mob AI, vanilla world generation, full vanilla command support, and full item, block and container support. The three custom types come first, and that ordering is not incidental. A Bedrock server that can only replay what the client expects is a thin proxy. One that can define its own blocks, items and entities is a platform, and that is what a server operator running a minigame network, a custom survival variant or a roleplay server needs. The world generation and mob AI support matters for the same reason: if the server generates worlds itself and drives entity behaviour, then the rules of the world are server side and can be changed by a plugin. The vanilla command support is the compatibility anchor. Players expect the command set they know to work, and a third-party server that drops half of them gets abandoned immediately. The honest framing is that vanilla-like is a strong claim rather than a precise one, and the documentation and the changelog directory are where you would look for the current state of any specific feature.

## Plugins are the extension path, and they are community made

The plugin story is documented in two directions, and the project is honest that most of the value arrives from outside it. There is a Plugin Hub for browsing community-made plugins for your server, and there is separate development documentation for people who want to write their own, with the contributing guide and the issues page as the other entry points. A Discord server is offered for talking to other users, developers and server owners. The tooling around the code shows how a project of this size is actually run. The build is Gradle with the Kotlin DSL, using build.gradle.kts, settings.gradle.kts, a gradle.properties file and the gradlew wrapper for both Unix and Windows, so a contributor does not need a matching local Gradle install. Lombok is configured, which removes a large amount of boilerplate from the entity and data classes that a game server inevitably accumulates. Coverage is tracked through codecov.yml and a Codecov badge, and a Codacy badge reports a quality grade. A crowdin.yml file indicates that translations are handled through Crowdin rather than hand-edited locale files. The jitpack.yml file means artefacts are also published to JitPack, which is what lets a plugin depend on a specific commit of the server. The .run/ directory holds IntelliJ run configurations, and an AGENTS.md file is present at the root for tooling that reads it.

## Three release channels, and the default branch is not the stable one

The release situation is worth understanding before you deploy, because there is more than one channel and the branch layout is not what a newcomer expects. The recent releases include 3.0.5 as a versioned release on 2026-09-15, a snapshot build from 2026-08-25, and a nightly dev build from 2026-05-28. The default branch of the repository is beta, not master, which tells you the development line and the stable line are not the same branch. For a server operator this means the sensible operational split is to run a versioned release in production, because it is a fixed point you can roll back to, and to use snapshot or nightly only on a test server where you want the newest protocol support. The consequence for operators is that protocol support arrives in the snapshot channel first. When Mojang ships a client update, the version of the server that understands it will often be a snapshot first, and the tags trail behind. The docker/ directory at the repository root is the packaging route for containerised deployments, and the deployment documentation site is the place to find the exact invocation rather than guessing at it. The project is not archived and the last push was on 2026-10-20, so the code is being worked on continuously, which is the double edged part when the default branch is called beta.

## What a Java Bedrock server does not solve for you

The limitations are structural, and you should weigh them before committing. First, the platform boundary. This is a Bedrock Edition server, so Java Edition clients cannot connect, and anything built around Java Edition mechanics, redstone behaviour or world format assumptions is out of scope. Second, the fidelity question. The project says vanilla-like mob AI and vanilla world generation, and support for the full item, block and container set. A server that reimplements a large proportion of a proprietary game's behaviour will always lag the client release in some corner, and the places it lags are where your players notice. Third, the operational reality of running a JVM process with a plugin ecosystem: you are running the Java Virtual Machine with its memory profile and garbage collector, and a plugin that misbehaves takes the server with it. Fourth, the resource ceiling. The badge set includes a high performance topic and a topic naming the jvm, but the performance question on Bedrock servers is dominated by tick rate and entity count, and a Java implementation will not outrun a well tuned C++ server on those. None of this makes the project a bad choice. It makes it a choice for a specific reason, and if the reason is Java plugin development rather than raw headroom, the trade is usually worth it.

## The LGPL licence and what it means for a server you redistribute

The project is licensed under LGPL-3.0, with the details in the LICENSE file, and for a server this is a reasonable choice but not a trivial one. LGPL is a weak copyleft licence. If you use the server as-is and run it, you owe nothing. If you modify the server itself and distribute your modified version, you have to make your modifications available under the same terms. The practical question for most operators is whether they distribute it at all. Running a server for your own community is use, not distribution, and the licence is not a barrier. Bundling a modified server into an image that you hand to paying customers, or shipping a plugin bundle with a patched server inside it, is distribution, and the terms then apply to the patched parts. The code is also stated to be open source and to welcome contributions, issues and feature requests, with a documented contributing guide, a code of conduct and a security policy in the repository, which is the profile of a project that expects outside participation rather than one that wants to stay sealed. Read the LICENSE file before you publish a modified build, and keep the LGPL terms intact if you do.

## Conclusion

Adopt PowerNukkitX if you want to run a Minecraft Bedrock Edition server from Java, want plugin development in a language most server operators already know, and need the custom item, block and entity support that the project advertises. Do not adopt it if you need the Java Edition client or protocol, since this is a Bedrock server, and do not assume feature parity with the official server, because the project describes its own goal as vanilla-like rather than identical. Before you start, read the documentation for the target protocol version, check the release channel you plan to run since the project ships stable, snapshot and nightly builds, and read the LICENSE file to see what LGPL-3.0 asks of a modified server you redistribute.

## FAQ

### What is PowerNukkitX and what language is it written in?

PowerNukkitX is an open source, feature rich Minecraft Bedrock Edition server written in Java. It is not affiliated with Mojang AB, and it descends from the Nukkit project lineage.

### What can PowerNukkitX do that a plain Bedrock server cannot?

The project advertises custom item, block and entity support, vanilla-like mob AI, vanilla world generation, full vanilla command support, and full item, block and container support. The custom types are the part that turns it into a platform rather than a proxy.

### How do I get plugins for PowerNukkitX?

Community-made plugins are browsed in the Plugin Hub on the project website, and the development documentation covers writing your own. A Discord server is available for talking to users, developers and server owners.

### Which PowerNukkitX release should I run in production?

The project ships a versioned release line, 3.0.5 dated 2026-09-15, plus a snapshot build and a nightly dev build, and the default branch of the repository is beta. A versioned release gives you a fixed point to roll back to, while snapshot and nightly builds arrive first when a new client version lands.

### What licence is PowerNukkitX released under?

The project is licensed under LGPL-3.0, with the details in the LICENSE file. Running the server as-is is not distribution, but a modified server you redistribute carries the LGPL terms for your modifications.

## Sources

- [License: LGPL-3.0](https://github.com/PowerNukkitX/PowerNukkitX/blob/beta/LICENSE)
- [PowerNukkitX/PowerNukkitX on GitHub](https://github.com/PowerNukkitX/PowerNukkitX)
- [Project website](https://powernukkitx.org)
- [README](https://github.com/PowerNukkitX/PowerNukkitX/blob/beta/README.md)
- [Releases](https://github.com/PowerNukkitX/PowerNukkitX/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/powernukkitx-powernukkitx