Pumpkin runs Minecraft on 100MB but pistons don't work

Pumpkin is a Minecraft server in Rust that boots in about five milliseconds and idles near 100MB of memory, against roughly 1.8GB for the official Java server. The speed claim holds up, but the gameplay does not yet. The project’s own tracker lists pistons as broken, and there is still no 1.0 release.

What a Minecraft server in Rust actually buys you

The headline numbers come straight from the Pumpkin landing page : about 5ms to start, about 100MB of RAM, about 0.1% CPU while idle. The same page puts Paper at roughly 10 seconds and 1.4GB, and the official server at roughly 15 seconds and 1.8GB. The memory gap is close to 18x on an empty world.

There is no JVM to warm up and no garbage collector to feed, and chunk work spreads across threads instead of piling onto one tick thread. Pumpkin also ships as a native binary, so you install no runtime at all.

Still, the project prints its own caveat on the benchmarks page , where it calls the comparison unfair. Pumpkin has far fewer features than the servers it is measured against, and those servers have had years of tuning aimed at full gameplay.

The runs used a Ryzen 7600X, Minecraft 1.21.1, view distance 10, and no pre-loaded world. Players stood still after spawning. An empty server with ten idle players is the easy case, and nobody has published a Pumpkin figure for a hundred players in a redstone farm.

What works today and what is still broken

Plenty already works. World loading and saving, lighting, chunk generation, inventories, hunger, experience, mob spawning, and combat basics are all in. On the ops side you get RCON, query, permissions, translations, scoreboards, world borders, and proxy support for BungeeCord and Velocity. Both Java and Bedrock handshakes work.

Redstone is the weak spot. The project keeps a public redstone tracking issue with checkboxes, and the mechanisms section is where it goes red. Pistons, sticky pistons, and block swapping are marked “Currently broken” by the maintainers themselves.

Dispensers, crafters, powered minecarts, lecterns, and sculk sensors are unchecked too. Wire propagation, repeaters, comparators, observers, hoppers, droppers, rails, and TNT are all ticked and done.

No pistons means no flying machines, no hidden doors, and no auto-farms. That is most of what a survival server’s late game gets built out of.

The plugin system is further along than the game logic. Its tracking issue is closed, with library loading, hot-reload, dependency resolution, version checks, event hooks, and a task scheduler all complete. Bedrock support is real but still marked work in progress, so treat cross-play as an experiment.

How far Pumpkin is from a 1.0 release

The 1.0.0 roadmap issue is still open and carries no date, and the ladder runs Alpha 1, Alpha 2, three betas, then 1.0. Alpha 1 hasn’t even been cut yet.

The unticked pre-release items are specific. They include a stable plugin ABI, a memory leak audit, a steady 20 ticks per second under load, and cross-platform boot checks. A stress test with 1000 simulated players is on the list too, though the roadmap never says whether those are bots or real clients.

One more entry reads as a warning to anyone thinking about production: removing unwrap and expect from critical paths. In Rust those two calls crash the program on bad input. So that checkbox means “stop falling over when a packet looks wrong.”

A* pathfinding for mobs, core survival goals, structure generation parity, and packet fuzzing against malformed data are ticked already. The guaranteed platforms at release are Windows 10 and up, Linux, FreeBSD, macOS, and Android on API 21, across x86-64 and Arm64.

None of this reads like a stalled project. The repo has closed 616 issues and commits land daily. The licence is GPL-3.0, worth knowing if you plan to ship a modified server inside a paid hosting product.

Running Pumpkin on your own box

Pumpkin has no stable download. The quick start docs offer three routes: pre-release binaries, a source build, or a container image.

The container is the shortest path, though Docker support is flagged experimental:

docker run --rm -p 25565:25565 -v ./data:/pumpkin -it ghcr.io/pumpkin-mc/pumpkin:master

Building from source is a git clone followed by cargo run --release. Expect a wait, because the release profile is heavily tuned. On a machine you own, you can squeeze out a bit more:

RUSTFLAGS='-C target-cpu=native' cargo run --release

Connecting from the same machine needs localhost:25565 typed into the multiplayer screen, because the address the server prints at startup isn’t the one the client wants. Drop a vanilla world into the directory, name the folder world, and Pumpkin loads it.

Keep a backup of that world. The project promises nothing about round-trip safety on an existing map, and I wouldn’t point it at a save I cared about.

A public test server runs at pumpkin.kralverde.dev on the latest master commit, hosted on a 2-core, 4GB Debian box.

Who should switch and who should wait

That last row is the one I would act on first. Six languages, each with its own documented quick start, is a wider door than any Java server offers.

The roadmap targets 2026 for 1.0, but Alpha 1 hasn’t shipped, so plan around nightly builds. Pumpkin has made the most convincing performance argument of any alternative server so far. It is still not a server you can promise your players.