What does RAM actually decide?
A Minecraft server keeps the world chunks around each player in memory. As player count grows and players spread apart, the area that must stay loaded grows with it — and plugin or mod data sits on top of that.
When memory runs short the server doesn't crash straight away; it slows down first. That's what you feel as lag: blocks break late, mobs stutter, drops appear behind you. The technical name is a TPS drop, and it's usually mistaken for "my internet is slow" when the real problem is the server struggling to breathe.
So the right question isn't "how many players can connect" but "how many can play comfortably".
What each tier really handles
The player counts below are guidance, not hard caps — more people can connect, but the experience depends on the resources you chose.
- 2 GB — a few friends on a vanilla or lightly modified world. Around 20 players advised. Mods can't be installed.
- 4 GB — a mid-sized community, a reasonable plugin set, wider exploration. Around 40 players advised. Cross-play becomes possible from this tier.
- 8 GB — busy communities, heavy plugin stacks and modpacks. Around 80 players advised. Mod and modpack installs unlock here.
As important as RAM: cores
A common misconception is that everything hinges on RAM. In fact Minecraft's world loop runs largely on a single core: player movement, mob AI, redstone circuits and farm mechanics are all calculated there.
So on a world full of redstone machines, automated farms or busy mob farms, plenty of RAM alone won't save you — core strength decides. Packages scale allocated cores alongside RAM, and both are listed separately on the cards.
We don't sell the same core to a second customer. The cores on the card belong to your server; a busy neighbour won't slow you down.
Disk: your world grows over time
Disk looks irrelevant on day one, but your world grows as it gets explored. Every time players push further out, new regions are generated and written permanently to disk; a long-lived survival world can reach a serious size within months.
Packages scale disk along with RAM. If you approach the limit you can resize the package, or clear out unused old worlds from the panel's file manager.
To avoid overpaying: start small, grow later
The most common mistake in server hosting is starting oversized "just in case". Hourly billing makes that unnecessary: start small, and if the community grows, stop the server and resize. Your world, plugins and settings stay exactly as they are.
The same works in reverse: if the crowd thins out after summer, size down. Since billing follows the hours the server is up, days spent switched off don't produce a bill at all.
If you're unsure, the middle tier is a reasonable default; after the first busy evening you can read the performance in the panel and decide on data rather than guesswork.
Before adding RAM to fix lag, check these
- View distance: a high value scales both memory and core load fast; dropping it a few steps is often the single biggest win.
- Plugin count and quality: one badly written plugin can cost more than ten good ones.
- Mob and item build-up: entities piling up around automated farms choke the world loop.
- World border: unlimited exploration inflates both disk and memory; a sensible border helps.