Endstone: a Bedrock server with a Paper-style plugin API

The gap Endstone is built to fill sits between the addon API and the custom server

Endstone is described as a high-performance Minecraft Bedrock server software with full vanilla features and a Paper-like plugin API, and the README explains the problem in three sentences that are worth reading closely.

Bedrock's official addon and script APIs let you add content but can hardly modify core gameplay. Custom servers such as PocketMine and Nukkit offer that control but sacrifice vanilla features. Endstone claims to give you both, with cancellable events, packet control and deep gameplay access alongside full vanilla compatibility.

That is a genuine engineering position rather than a marketing line. The reason a custom Bedrock server usually loses vanilla behaviour is that it reimplements the game logic, so every vanilla mechanic is a reimplementation and every bug is yours. Endstone takes the opposite approach: it starts from the Bedrock Dedicated Server, which already has the vanilla behaviour, and adds a plugin layer on top.

The reference point the project uses is Paper, and the analogy is apt. Paper works the same way for Java Edition: it keeps the vanilla server and exposes a Bukkit-style plugin API on top, with the performance characteristics of the underlying server largely preserved. The project description says Endstone is the fastest way to run a vanilla Bedrock server, with over 2x the TPS of BDS under heavy load, and the README points to a BENCHMARK.md file for the measurements. Treat that as a claim to read rather than a result to quote, since the conditions behind it are not described in the README.

The audience is a server operator or plugin developer who has looked at Bedrock's official APIs, found them wanting, and looked at PocketMine, found them losing something, and wants the first without the second.

Two plugin languages, one API, and a version string you have to keep in step

The plugin API is the product, and it is the part that decides whether Endstone is useful to you.

Plugins can be written in Python or C++, and the project offers templates for both in separate repositories, a Python plugin template and a C++ plugin template. The choice is framed as a trade: Python for rapid development, C++ when you need maximum performance.

The API itself is deliberately familiar to Bukkit developers, and the README says that if you have developed plugins for Java Edition servers you will feel right at home with the API design. The plugin model is a class with an enable hook, an event registration call, and decorated handler methods.

from endstone.plugin import Plugin
from endstone.event import event_handler, PlayerJoinEvent


class MyPlugin(Plugin):
    api_version = "0.10"

    def on_enable(self):
        self.logger.info("MyPlugin enabled!")
        self.register_events(self)

    @event_handler
    def on_player_join(self, event: PlayerJoinEvent):
        event.player.send_message(f"Welcome, {event.player.name}!")

Note the api_version field in the class body. That is a version of the plugin API, declared by the plugin, and the project makes a point of it elsewhere in the README: the API is described as a comprehensive set of 60+ events covering players, blocks and actors, plus commands, forms, scoreboards, inventories and a full permission system. An api_version field in a world where the API is still moving quickly is a compatibility contract, and it is the thing to watch when the server updates.

The handler signature is also telling. The event object carries the player, and the plugin sends a message through it, so events are objects with methods rather than bare data.

Installing means pip install, and running means one command

The quick start is unusually short for a Minecraft server, and that is largely a consequence of the packaging decision.

pip install endstone
endstone

The package is on PyPI, and the console script is registered in the project metadata as endstone pointing at endstone.cli:main, so the server binary ships inside a Python distribution. The runtime requirements are Python 3.11 or newer on Windows 10 or later, or on Linux with Ubuntu 22.04 or Debian 12 or later, and the classifiers cover Python 3.11 through 3.15.

The Docker route is equally short.

docker pull endstone/endstone
docker run --rm -it -p 19132:19132/udp endstone/endstone

Only the UDP game port is published there, which is the port a Bedrock client connects to. The compose file in the repository is more complete and shows the shape of a real deployment.

    ports:
      - "19132:19132/udp"  # IPv4 game port
      - "19133:19133/udp"  # IPv6 game port

    environment:
      PUID: ${PUID:-1000}
      PGID: ${PGID:-1000}
      TZ: ${TZ:-UTC}

The two UDP ports are labelled IPv4 and IPv6 game ports, and the environment block sets the user and group the server runs as plus the time zone. The .env.example file explains the intent: set PUID and PGID from your host user's id -u and id -g so that files written into the data directory stay owned by you, and set TZ for log timestamps. The compose file mounts ./data:/data to persist the world, plugins and configuration on the host, and it keeps standard input open with a TTY so the server console works under docker attach. It also sets a 15 second stop grace period, with the comment that the Bedrock server needs time to save the world before it is killed.

Building from source is the same three commands plus a pip install.

git clone https://github.com/EndstoneMC/endstone.git
cd endstone
pip install .
endstone

That last path is heavier than it looks, because the project is C++ with a conan-based build.

Conan, LLVM and a manylinux tag explain what pip install is really doing

The build system is the part of Endstone that best explains why a Bedrock server is distributed as a Python package.

The project metadata shows a custom build backend, conan-py-build, alongside setuptools-scm, with the version declared as dynamic. Conan is a C and C++ package manager, and there is a .conan2/ directory at the repository root with a remotes.json and a default profile, plus a conanfile.py. The tool configuration pins the build type to RelWithDebInfo and skips the test run during the conan build, which is what a project shipping a compiled extension needs.

The Dockerfile shows the toolchain in detail. The build stage is python:${PYTHON_VERSION}-slim-bullseye with the Python version defaulting to 3.13, and the comment explains the base image choice: Bullseye's glibc 2.31 is what tags the wheels manylinux_2_31, so they keep it. The stage installs the LLVM toolchain, with the version defaulting to 20, fetching the install script from apt.llvm.org, and then sets clang, clang++, llvm-cov and ld as alternatives pointing at the versioned binaries, with ld pointed at the lld linker. The audit wheel platform tag is set to manylinux_2_31_x86_64.

So the Bedrock server binary is compiled from C++ with clang, packaged as a Python wheel, and installed by pip. That is why the pip install is one command and why the distribution is a normal Python package on PyPI rather than a tarball you have to compile yourself.

The source tree confirms the shape: src/ and include/ for the C++ core, an endstone/ directory for the Python package, recipes/ for the conan recipes, tests/, scripts/ and docs/ with mkdocs.yml, plus a docker/ directory and docker-compose.yml. There is a .clang-format and a .clang-tidy, so the C++ side is formatted and linted like any other project, and a codecov.yml alongside tests/ means coverage is tracked.

A drop-in replacement that still tracks every Minecraft release

Two of the listed features determine whether Endstone is a fit for a live server.

The first is drop-in replacement. The README says it works with your existing Bedrock worlds and configurations, and that you just install and run. For an operator with an existing world, that removes the usual migration problem, where adopting a custom server means losing or converting player data.

The second is the compatibility promise, and it cuts both ways. The feature list says Endstone is designed to stay compatible with the latest Minecraft Bedrock releases so you are never left behind. The badge in the README tracks a specific version, v26.52 for Bedrock, and the topic tags include both mcpe and minecraft.

The strength of the design goal is that a Bedrock server that falls behind a release soon stops being a server that players can connect to, so staying current is not a nice-to-have. The cost of the same property is that the server tracks an upstream that changes on a schedule the project does not control. The release history shows how that cadence looks in practice: v0.11.14 on 2026-10-12, v0.11.13 on 2026-10-06, v0.11.12 on 2026-09-20, so patch releases land roughly weekly, and the last push to the repository was on 2026-10-18.

The plugin API version is the thing an operator has to watch, because a plugin declaring an api_version has to be checked against the server it runs on. That is the cost of the Paper-like model: you inherit a compatibility surface, and you inherit the obligation to track it.

Two supporting repositories round out the picture. The CHANGELOG.md and ROADMAP.md at the root are where the release history and the planned work live, and the documentation is on endstone.dev with guides, an API reference and tutorials, plus a Discord for support. The project is sponsored by Bisect Hosting, which offers managed Minecraft server hosting, and package hosting comes from Cloudsmith.

Where Endstone is the wrong tool

The first wrong-tool case is a developer who only writes Java. The Paper comparison is about API shape, not about language, and the implementation languages are Python and C++. A Java Edition plugin does not port over, and a team without Python or C++ in its toolkit is paying to learn one for the sake of a server plugin.

The second case is a server that must not change underneath its players. The weekly patch cadence is fine when the server is a hobby, but an operator who cannot take an unplanned restart cannot run a server that updates to match a new Minecraft release. The drop-in replacement property helps with worlds and configuration, and does nothing for availability.

The third case is a project that wants the official Bedrock APIs plus a small amount of extra control. The addon and script APIs are free, supported and documented, and if the only thing you need is to add content or a small behaviour tweak, Endstone is a much larger dependency than the problem needs, running a reimplemented server rather than the official one.

The fourth case is a platform Endstone does not target. The classifiers name Microsoft Windows and POSIX Linux, and the runtime requirements are Windows 10 or later, Ubuntu 22.04 or later, or Debian 12 or later. The README also mentions running natively on both Windows and Linux without emulation, so macOS is not in the picture.

On licensing, the project is Apache-2.0, with the licence file referenced from the project metadata through license-files rather than a licence string. That is a permissive grant with an explicit patent clause, which matters for a server product that plugin authors may build on commercially.

One thing to check before trusting the headline number: the README claims over 2x the TPS of vanilla BDS with 100 players online and links to BENCHMARK.md for the details. Read that file rather than repeating the figure, since TPS comparisons depend on hardware, world size and view distance.

Editorial conclusion

Endstone suits a server operator who wants to modify Bedrock gameplay the way a Paper plugin modifies Java Edition, and who needs that without giving up vanilla features. It does not suit someone who wants to write plugins in Java, since the API is Python and C++ only, and it does not suit a production server that cannot tolerate tracking a new Minecraft release, since the project states that compatibility with the latest Bedrock releases is a design goal rather than a fixed target. Before adopting, install the endstone package on Python 3.11 or newer, confirm the API version your plugin declares matches the server's, and read BENCHMARK.md rather than relying on the throughput claim in the README.

Frequently asked questions

Official sources

1. EndstoneMC/endstone on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases