How we built an auto-scalable Minecraft server for 1000+ players
In this technical retrospective (2021), @hopfog shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE ★ 401 points
TOTAL DISCUSSIONS 142 comments
Interesting timing.
I play with a few friends on a modded 1.7.10 server and we’ve decided to restart with 1.16 due to the lag having become untenable.
We run it on an i7 machine at my house dedicated to it, so it’s not a hardware issue.
Like clockwork the server would freeze for about 5s about every 30s. Using opus our best guess is that it’s unloading chunks and the GC is happening.
We’re going to run 1.16 now which I hope has some performance enhancements and so that we can use more modern Java 16 runtime with its nicer GC systems.
I’m also hoping that Minecraft has at least since moved chunk generation off the main thread since there was no good reason for world exploration slowing down things like it did.
I also built a JavaScript redstone simulator website and I’m curious how you will handle that and other block updates at server boundaries.
Hmm, I still think spatially allocated servers offer the best scalability. You would just have to approach it a little differently.
Server boundaries could move based on where the population is via delaunay triangulation (instead of fixed boundaries), and servers could share high-importance information with their immediate bordering neighbours. (This would be recognized as ghost data on the neighbouring servers.) You could even go further and have neighbours share ghost data with their other neighbours at a lower fidelity/frequency.
A virtual distributed actor system could potentially be used to address any potential downtime or resource waste created by unpopulated zones.
I've been playing around with some of these ideas but haven't been able to turn them into an actual implementation, so kudos to you for actually doing it!
I used to play on a pretty popular MMO-style server called [CivCraft](https://www.reddit.com/r/Civcraft/) that unfortunately became a victim of its own success due to the large player count. It would often have 250+ players who would build these massive redstone machines and the server TPS would grind to a halt making it unplayable.
After a few years it attempted a re-launch using an approach similar to to the first one mentioned in the article. There were multiple worlds and as you approached the border of one world it would teleport you to another adjacent world. It was cool, but was jarring and suffered from its own complexity issues.
Anyway, this project is super cool. I would have loved to see something like it 10 years ago.
A couple of weeks ago I made https://playmcnow.com with the opposite idea - have many super lightweight servers for small groups of players. Instead of saying to friends “register to digital ocean, pay $5 and get a Minecraft box”, I can host thousands of worlds for them.
I made a custom minecraft proxy (similar to bungeecord but A LOT less resource intensive) that starts the real server when someone attempts to connect to it.
200 lines of go for the proxy and about as much for the http front end in django :).
Impressive work! There's a lot of potential here, but probably within a pretty limited market. Outside of 2b2t and maybe Hypixel, is there really anyone who wants 1000 players on the same world? Is the small market the only reason why a solution like this hasn't been created before, or are there bigger complications that aren't listed or haven't come up yet, or maybe the technology wasn't available? Surely someone like Hausemaster who stands to gain substantial amounts of money from this has looked into it before, right?