Rust replaces the Java server, not just one subsystem
Pumpkin implements a Minecraft server as a Rust application. Its scope includes network protocol, encryption, packet compression, worlds, chunk loading and saving, lighting, entities, inventories, chat, commands, permissions, proxies, and a plugin foundation. Configuration uses TOML. The project supports Java connections and is working toward Bedrock support through the same server. This is a full server rewrite, so every familiar Minecraft rule or edge case must be implemented rather than inherited from Mojang's server.
That distinction shapes the decision. Multi-threaded Rust can offer a different performance and safety base, but compatibility is a long list of behaviors rather than one protocol handshake. The README marks Redstone, combat, chunk generation, plugins, Bedrock, mobs, bosses, villagers, advancements, and several entity categories as tracked or in progress. A server can let players join, save a world, and pass 710 tests while still behaving differently during a farm, minigame, plugin event, or unusual inventory action.
The clean build passes 710 tests and takes 25 minutes
Our fresh Debian sandbox installed commit f8932f4 in 30 seconds and resolved 658 Rust packages. Compilation then succeeded in 802 seconds, roughly 13 minutes. The test step succeeded in another 726 seconds, a little over 12 minutes, with cargo test reporting 710 passed and 0 failed. Together, build and test occupied more than 25 minutes on the 3-CPU machine, so source-based CI and frequent clean rebuilds need a real time budget.
The checkout was also large: 23,569 files, about 606,941 lines of source, and 174.6 MB before compilation. We found 5 CI workflow files, a Dockerfile, and a Compose file. There was no top-level tests directory, but Rust tests can live beside implementation code, and the successful Cargo result is the evidence that matters. Our container had 12 GB of RAM and no secrets. It verified code, not multiplayer tick rate, network behavior, or a migrated world.
What happened when we ran it
Our run completed every supplied lab step. Installation succeeded in 30 seconds with 658 packages, the build succeeded in 802 seconds, and the test command succeeded in 726 seconds. All 710 reported tests passed. There were no failed cases to explain and no skipped test count in the supplied result. This is the strongest measured result in this review set, especially for a repository with more than 600,000 lines of source.
The numbers have limits. We did not start a server, connect a Java or Bedrock client, generate chunks, load plugins, or simulate players. The 3-CPU, 12 GB container also says nothing about claimed performance under a live tick workload. A prospective operator should keep the successful 710-test result as confidence in the checked commit, then run a separate compatibility trial using the exact client versions, world seed, player count, proxy, and plugins planned for deployment.
Vanilla parity still has visible gaps
Current reports name ordinary gameplay differences. Issue 3071 says minecarts do not climb sloped rails. Issue 3068 says boats cannot be broken by hand. Issue 3069 says Drowned carrying tridents attack only at melee range. Issue 3067 says suspicious sand and gravel do not fall. Issue 2501 shows generated structures with misplaced blocks and blocked corridors. These reports concern specific commits and may be fixed quickly, but they are concrete examples of why a pre-1.0 rewrite needs scenario testing.
Recent pull requests show the same work from the repair side. One adjusts packet formats across older Java versions to prevent client crashes. Another adds safer spawn placement, while a larger piston change tries to preserve vanilla tick order around concurrent entity and block-entity work. This is active, detailed engineering. It also shows the difficulty: some vanilla mechanics depend on ordering assumptions from a mostly single-threaded original server, and concurrency can change them unless the implementation creates deliberate sequential regions.
Plugins use a new API with an unfinished stable boundary
Pumpkin does not promise the Bukkit, Spigot, Paper, or Fabric plugin catalog. Its plugin API and WIT package are separately licensed under MIT or Apache-2.0, even though the server is GPL-3.0. That licensing split gives plugin authors a permissive option for their code. Technical compatibility is a different question. The open 1.0 roadmap leaves the native plugin API's stable ABI boundary unchecked, meaning core types may still change before minor-release compatibility can be promised.
A proposed native dynamic-library loader says it is exploratory and not ready for review. Operators should therefore judge Pumpkin on the plugins that actually build and run against their pinned commit, not on the general existence of a plugin heading. If an established server depends on moderation, permissions, economy, mapping, backup, or anti-cheat plugins, inventory those names first. Replacing the server and every operational extension in one move is unnecessary risk.
Bedrock support is present and still work in progress
The README lists both Java and Bedrock under protocol goals but labels Bedrock work in progress. Issue 3064 reports that one Bedrock client on Android takes damage when approaching blocks. A pull request adding Android build coverage notes that its emulator test found a problem while the workflow still marked success. Neither item defines the whole Bedrock experience, yet both argue for treating cross-edition support as a development track rather than a finished reason to migrate.
GitHub recorded 10,948 stars, 298 combined open issues and pull requests, and a push on August 26, 2026. GitHub returned no latest release. The README calls development heavy, and issue 449 tracks the remaining 1.0 work, including a stable plugin boundary and a private community test. Pumpkin is healthy enough to watch and contribute to. Our 710 passing tests justify that attention, while its own roadmap keeps production advice conservative.