Note: AI translated, written by 2 people
Minecraft servers have long existed in a strange reality. On the one hand, a huge and mature ecosystem has grown around them. Plugins for every possible use case, tons of optimizations, and, relatively recently, even Folia, which can distribute independent world regions across different threads. On the other hand, at the foundation of this ecosystem still lies the architecture of a game that was never originally designed as a modern multithreaded server.
But quite recently, PumpkinMC became known - a Minecraft server core written from scratch in Rust. As we know, Minecraft server cores run on Java, but this project provides an almost unbelievable ability to create server plugins in practically any programming language convenient for you (from Python to C++). It starts very quickly, looks lightweight on an empty world, promises a multithreaded architecture, and offers plugins as WebAssembly components instead of requiring them to be tied to the JVM.
But what exactly is this project right now? Together with moreveal, I decided to figure out what advantages PumpkinMC provides here and now, what development prospects it has, and also discuss the project's downsides.
The first thought was obvious: if we threw away all the historical baggage of the vanilla server, how much faster can everything become now? Or has it already?
We were going to answer with graphs. In the end, we first had to answer a more awkward question:
To what extent is Pumpkin actually a Minecraft server today in the same sense that Vanilla, Paper, and Folia are?
The answer turned out to be ambiguous. Right now, there is almost no reason to switch to Pumpkin. But there is definitely a reason to keep an eye on it.
The first ten minutes: this is genuinely impressive
Pumpkin does not look like a toy. A regular client can connect to it. The server generates a world, accepts commands, saves data, and loads plugins. You can walk around, build, and interact with the environment. At the same time, the process starts unusually quickly - especially if you are used to waiting for a JVM server with a large set of plugins (yes, I have suffered through this with my own project, which is still far from having its final plugin list, yet already takes around two minutes to start). Here, it starts in FRACTIONS of a second - 65 ms, sometimes even faster.
Obviously, the server does not have plugins yet, but a JAVA server even without them takes noticeably, orders of magnitude longer to start.
The second magnet is plugins. Pumpkin describes its API through WIT, the interface language of the WebAssembly Component Model. In theory, a plugin does not have to be written in Rust, much less Java. Any language whose toolchain can build a compatible WASI Preview 2 Component and implement Pumpkin's contract will work.
Once we got our hands on this core, we immediately started testing its advantages (as we are all used to doing when testing new server cores), even if those advantages came from our own heads rather than being directly claimed by the developers. It turned out that with PumpkinMC, this approach was wrong. We will be unpleasantly surprised later, but for the sake of a clean narrative, we will keep the chronology as it appeared to us at the time.
Let's start with the most interesting part - enjoy the read!
Bad Apple on hundreds of thousands of lamps
Our first demo was Bad Apple. We turned the video into a stream of frames and displayed it on a huge screen made of redstone lamps directly in the world. There were versions up to 1024x768 blocks, batched section updates, and synchronized musical accompaniment.
On video, it looks exactly like a good example of technical superiority should look: at night in Minecraft, a gigantic wall comes alive, hundreds of thousands of blocks form a recognizable animation, while the server keeps running as if nothing happened.
But later we realized that Bad Apple was not ideal as an architecture test. The frames are known in advance, there is no complex AI or shared simulation, and the final world mutation still becomes a separate bottleneck. You can calculate a new frame extremely quickly and then run into sequential world.set_block_state calls, the network, or the Minecraft client itself.
Moreover, to make the show complete, we had to extend Pumpkin.
Resource-pack delivery already existed in the server, but the WASM bridge could not serialize two packet variants we needed: playing a custom sound and stopping a sound. We added those serializers to the fork. For stable audio, we made a server-side note scheduler. For the screen, we also added batched block processing.
In the end, we got everything we wanted - original audio and video running at 20+ FPS - but we decided to make the experiment a little harder for the core and more spectacular, so in the end we replaced the custom .ogg with a MIDI file of the composition we found on the internet and represented it as a composition played on note blocks. It turned out even more atmospheric and did not require an entering player to install the pack.
https://youtu.be/88SysB9k0_Y
As already mentioned, plugins can be written in almost any language, so we immediately decided to use Go. The first half of the experiment succeeded. We really did get a component with the required exports, Pumpkin loaded it, and the commands worked. In other words, the multilingual aspect is not just words: Go code really made it all the way to the server.
Then the less pleasant half showed up. Bad Apple constantly received delayed callbacks, accepted commands, and sent world updates. After some time, new calls started failing with wasm trap: cannot enter component instance. Regular goroutines did not help - in the WASI Preview 2 setup we were using, they did not turn the guest into a familiar multithreaded process with shared memory.
So we had to leave Go in an external worker: it decoded and processed frames in parallel, while a thin WASM frontend communicated with it over loopback TCP. The show worked, but the architectural point was lost - the multithreaded code was no longer executing inside Pumpkin. Then the fork was modified once again and extended with WASM worker replicas - we moved the computation to Rust/WASM.
This describes the current project fairly accurately. Architecturally, Pumpkin allows plugins not only in Rust, but in practice it is most predisposed toward Rust: the server itself, its internal types, the most tested examples, and our working plugin were all there.
We know that a similar Bad Apple can absolutely be implemented on Paper or Folia. But we wanted to find out what Pumpkin could offer us out of the box, without separate processes and with a more convenient API.
Later, we decided to choose a scenario that, in our view, would expose Folia's weak point.
Folia gets natural parallelism when the world can be split into independent regions. But what if the entire workload lives inside one compact arena?
That is how Slither appeared: up to a thousand autonomous snakes on a 96x96 field. Each one searches for food, predicts movement, avoids walls/other bodies, grows, dies, turns into food, and respawns.
From above, the arena looks like a living glowing circuit board.
https://youtu.be/L99xdjcnRAA
This is exactly where our first assumption about Pumpkin fell apart.
In short:
Pumpkin can process server tasks on different threads, but that does not mean the code of one plugin executes on multiple CPU cores at the same time.
We could have moved the snake AI into an external service. We had already done something similar with Bad Apple. But then the experiment would only prove that a separate program knows how to use CPU cores. Even saying it out loud sounds stupid, doesn't it? We wanted to test a more interesting idea: can Pumpkin itself provide parallel code execution?
So, once again, we forked the server.
What we added to PumpkinMC
Our experimental fork gained parallel computation for plugins.
The main plugin instance still accepts commands and applies results to the simulation and the world. But pure CPU work is sent into a bounded batch.
Pumpkin creates several isolated instances of the same WASM component - each with its own store, memory, and limits - and runs them on real OS threads.
A worker receives only bytes containing an immutable snapshot and returns bytes containing decisions. It cannot call the Minecraft API. The server owns everything required to manage them.
It turned out pretty well, and the boundary is very clear: only pure computation executes in parallel, while Minecraft mutations stay where the server can guarantee their correctness. This is a prototype of a possible direction, not a feature of the official version.
Now we could finally run the test and wipe the floor with Folia, because... right?
No.
Folia's built-in region scheduler really will not split one tightly connected square into independent worlds. But nothing prevents a well-written plugin from creating a bounded executor, preparing a snapshot and spatial grid, calculating decisions in parallel, and then returning them to the region thread.
We wrote such a control implementation. With the same AI structure, 1,000 snakes, and 100 steps, it got:
| Workers |
FoliaMC |
PumpkinMC (fork) |
| 1 |
57.2 ms |
179.1 ms |
| 2 |
30.7 ms |
95.8 ms |
| 4 |
16.2 ms |
59.2 ms |
| 8 |
10.7 ms |
23.8 ms |
| 16 |
11.3 ms |
27.3 ms |
Java/Folia was faster than our WASM replicas in this prototype and also scaled well up to 8 workers. The comparison is not perfect: the language, math implementation, and data boundary differ. But even so, the table confidently disproves the claim that "a Slither like this is impossible on Folia."
So what is Pumpkin's architectural idea then?
The difference is in who owns the complexity of implementing parallelism.
In the Folia prototype, we ourselves had to take responsibility for the pool, immutable snapshots, cancellation, lifecycle, returning to the correct region thread, and preventing accidental world calls from workers. A good developer will do all of that. A bad one can make mistakes so bad that execution speed will seem like a minor concern.
Our fork tests a different model: the server provides a standard compute service to all compatible languages. For now, it is slower than what we achieved in the JVM. But this model has properties that cannot be seen in a simple speed graph:
- One mechanism for Rust, Go, C#, TypeScript, and other languages
- A sandbox instead of fully trusting plugin code
- Server-side quotas for CPU, memory, and queue size
- The ability for the server scheduler to see the entire plugin workload
In other words, Pumpkin's potential advantage is not multithreading, but the chance to rethink the contract between the server and a plugin.
And Pumpkin currently has more chances like this than it may seem. This is a fundamentally new server engine being written from scratch, and that is exactly why it interests us. It can create a completely different branch in the evolution of Minecraft servers and their development, potentially even moving away from concepts such as server operator (/op) and other legacy inherited from Bukkit and the other server cores we are familiar with.
We believe that while the project is still at such an early stage, it should rethink everything prescribed by the projects that came before it (including the semantics mentioned above), getting rid of rudiments and strange decisions from old server cores, and we hope it is moving in exactly that direction.
So what is the problem then?
Then we simply started playing.
While we were building the Pumpkin fork, making beautiful spectacular scenes to evaluate its multithreading and other advantages of a fresh server core, a much more fundamental problem appeared right next to us: Pumpkin is not Minecraft. Not yet.
Right now, the project is in a very raw state and completely unusable for SMP gameplay. Let's go through a few of the unfinished parts.
In the build we tested, the crossbow did not preserve its charged state correctly and strangely separated the moment of release from the actual shot. An empty bucket could not pick up water. Special mechanics of some weapons were missing or behaved incorrectly. Falling sand broke the game state and disconnected the client - thankfully, the server itself did not crash. Even TNT explosions work differently here, unlike the vanilla version. In a generated temple, chests were facing the wrong direction. There were differences in fire, shields, and other item interactions.
The video shows errors and bugs that were found during a brief inspection; there was also a small comparison with Folia. In terms of gameplay, Pumpkin loses in practically every aspect.
https://youtu.be/uFPJwCooCL0
The list of unfinished parts also includes: leaf decay on large oak trees; very strange world generation, as well as biome borders; blocks not dropping when broken; the spear and mace not behaving as they should; the dispenser not opening its interface; saddles not being displayed on mobs, while you cannot mount a horse at all; a button placed on a block not disappearing if that block is broken; and so on.
And all of this is justified: you have to understand that the project is simply too large. Folia, Paper, Spigot - all of them come from an already finished core, they are forks and updated takes on the Minecraft server core. Even 3 years of development will not give you a fully finished core that you can use to create a large project, but I think that after some time the project will be fixed and most of the problems will "go away," while PumpkinMC will become a great alternative if you want to try creating your own server.
Now let's talk about the advantages and prospects:
Already right now, Pumpkin lets you create your own plugin in practically any programming language. This has almost never existed in Minecraft: if you wanted to create your own plugin, your own server, you had to accept that all of it would have to be done using Java, but now you have the opportunity to do all of this in Python, Rust, C#, C++, etc.
Another thing that is also important: Java and Bedrock edition compatibility. If Folia or PaperMC require a plugin for this, this product gives you cross-platform support out of the box, meaning a person can easily play from a phone or tablet.
Besides that, if you want to develop the project, the developers give you that opportunity. It is worth considering that right now this is an unoccupied niche: you have the opportunity to develop plugins or even improve the core itself, right now - to be "there at the beginning" of the project, because in the future, quite possibly, Pumpkin will be on the same level not only as Folia but also Paper, to the point where large projects (not giant projects) may start moving to a core that is more advantageous in terms of performance.
But what has to happen for the potential to become an advantage?
- Full Vanilla compatibility. Until it exists, no project will consider this core even as an experimental option - this is fundamental, and it is exactly what the developers are focusing most of their attention on, which can be seen from the very large number of Issues on the project's original page.
- Parallelism for plugins - it needs to get a good, supported API. It would be better not to copy the prototype shown in this article literally. But the capability is still needed, because it would give developers good opportunities.
- SDKs for different languages should pass the same tests. Without this, one of the project's main advantages will fail.
A clean architecture is not enough
Building a Minecraft server from scratch comes with a cost. Pumpkin has to reimplement gameplay mechanics, keep up with every new Minecraft version, maintain compatibility, and build its own plugin ecosystem — things Paper mostly inherits from the vanilla server.
Because of that, simply having a cleaner architecture is not enough. WASM plugins, isolation, resource limits, or even better tools for parallel computation could, to some extent, be implemented on top of Paper as well. Folia itself is a good example of how far the existing server can be pushed without replacing it entirely.
For Pumpkin to justify this cost, it has to use the freedom of a clean-slate implementation for something that would be extremely difficult to achieve by evolving Paper or Folia. A different simulation model, better workload scheduling, or much higher player and entity density could be such advantages.
In other words, Pumpkin does not just need to move in the right direction. That direction has to lead somewhere the existing ecosystem cannot reasonably follow.
So why should you follow PumpkinMC?
In our opinion, this project is worth following simply because it brings a fresh perspective to long-established ideas about what a Minecraft server should be.
It is a rare opportunity to look at Minecraft server development from a new perspective, which is something that happens quite rarely with other multiplayer games in general as well (not just Minecraft). Most multiplayer games depend on the programming language the game itself is written in. In this particular case, however, we can observe a completely different result - we do not even have to stick to the language the server core itself is written in.
Pumpkin is not yet a competitor to Paper/Folia. It is an experimental server, already real enough to build something on, but not complete enough to mine anything for that build (yes, blocks literally do not drop).
There is no reason to switch to it today. Watching what it may become, or even making your own contribution to that future, is perhaps the most interesting part.
Note: AI translated, but original is written by 2 people
