Deepak's Blog logo

How to Run a Minecraft SMP That Actually Survives 100+ Players

Published on
8 mins read

So you want to run an SMP where a hundred-plus friends (and friends-of-friends, and that one guy who builds cursed redstone) can all hang out in the same world without the whole thing turning into a slideshow.

Totally doable. But here's the thing nobody tells you up front: the hard part isn't your internet, your RAM, or even the player count itself. It's a single thread.

Let me explain, and then let's actually build the thing.

Why vanilla quietly dies around 50–80 players

Minecraft's server runs its entire world — mobs, redstone, crops, block updates, player movement — inside one main game loop that ticks 20 times a second. That loop is essentially single-threaded. Your fancy 16-core CPU? The vanilla server mostly uses one core for the part that matters.

So when 100 players spread out, light up redstone farms, and load chunks all over the map, that one thread gets buried. Ticks start taking longer than 50ms, your TPS (ticks per second) drops below 20, and everyone feels it as rubber-banding and laggy mobs. More RAM doesn't fix this. A bigger core count doesn't fix this. You need a smarter server, smarter settings, and a CPU with a high single-core clock.

Good news: every one of those is solvable.

Step 1: Ditch vanilla, pick the right server software

The single biggest upgrade is swapping the vanilla jar for an optimized one. Your options, roughly in order:

  • Paper — the community standard. A drop-in replacement that's massively more efficient than vanilla, keeps full plugin support, and exposes hundreds of performance settings. For ~100 players in one shared SMP world, Paper (well-tuned, on good hardware) is the sweet spot. Start here.
  • Purpur / Pufferfish — forks of Paper with even more optimization and config knobs. Still plugin-compatible. Worth a look if you've maxed out Paper and want a bit more headroom. (Core comparison)
  • Folia — the spicy one. Paper's sibling that adds regionised multithreading: it splits the world into independent regions and ticks them on different cores at the same time. This is how people run hundreds to thousands of players on one world. In real comparisons Folia held ~19.7 TPS with 300 active players where Paper dropped to ~13.4 with its main thread pinned. (benchmarks)

The Folia catch — read this before you get excited: Folia is not a drop-in replacement. It breaks most plugins — only ones explicitly written for Folia's multithreaded API work (LuckPerms, ViaVersion, BlueMap, GrimAC, and a growing list on Modrinth/Hangar). The PaperMC team's own advice is basically: use Paper unless you're genuinely saturating a single thread (think 200–300+ concurrent and players spread across the map).

My recommendation: Build on Paper first. It'll comfortably carry 100 players with the tuning below. Only graduate to Folia when you've outgrown a single thread and your plugin list is Folia-ready. (the official Folia thread on exactly this)

One myth to kill: "Just put it behind a proxy like Velocity and split the players." Proxies (Velocity is the modern, much-faster successor to BungeeCord) are amazing for networks — a lobby, a survival server, a minigame server, all connected. But they put players on separate worlds. A proxy can't shard one shared SMP world. For a single world with 100+ people, your levers are beefy-Paper or Folia — not a proxy.

Step 2: Hardware — clock speed beats core count

Because the main thread is single-core bound, the most important spec is single-thread CPU performance, not the number of cores. (Minecraft Wiki, TechMikeNY's 100-player build)

A rough target for ~100 players:

  • CPU: high clock speed, 4.0GHz+ single-thread. A fast 4-core will beat a slow 16-core for Paper. (Folia is the exception — it loves cores.)
  • RAM: 16–32GB allocated to the server. RAM stops lag spikes and OOM crashes, but it is not the thing that raises your player ceiling — don't over-allocate and assume it'll fix TPS.
  • Storage: NVMe SSD, always. Chunk I/O on a spinning disk will haunt you.

Step 3: Java + JVM flags (the free performance you're leaving on the table)

Run Java 21+ (Adoptium or Amazon Corretto). Then start the server with Aikar's flags — community-tuned G1GC garbage-collection settings that stop the multi-second freezes vanilla GC causes under load. Don't hand-write them; generate them for your RAM amount with flags.sh, or read the PaperMC docs on Aikar's flags and Aikar's original writeup.

A typical launch ends up looking like:

java -Xms16G -Xmx16G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC \
  -XX:G1HeapRegionSize=8M -XX:G1NewSizePercent=30 \
  # ...the rest from flags.sh...
  -jar paper.jar nogui

Set -Xms and -Xmx to the same value (e.g. both 16G) so the heap doesn't constantly resize.

Step 4: The config knobs that actually move the needle

This is where a struggling server becomes a smooth one. The two most important settings live in server.properties:

view-distance=7
simulation-distance=4
  • simulation-distance = how many chunks around each player get fully ticked (mobs, crops, redstone). This is the expensive one. Keep it low (4).
  • view-distance = how far players can see. Cheaper than simulation, so you can keep it a bit higher (7) for nice visuals.

Then, in Paper's world config (paper-world-defaults.yml) and spigot.yml, the high-impact entity/mob settings (values from the excellent YouHaveTrouble optimization guide and Paper-chan's guide):

  • per-player-mob-spawns: true — spawns are budgeted per player, so a crowd doesn't multiply your mob count into oblivion.
  • spawn-limits → monsters ~20, animals ~5.
  • entity-activation-range → monsters 24 (how close before a mob's AI runs).
  • merge-radius → items 3.5, exp 4.0 (fewer dropped-item entities to tick).
  • redstone-implementation: ALTERNATE_CURRENT — a much faster redstone engine, basically free TPS.
  • tick-inactive-villagers: false, armor-stands.tick: false, alt-item-despawn-rate for junk like cobble/dirt.

Don't paste these blindly — skim the guides and understand the trade-offs (e.g. tick-inactive-villagers: false can affect some iron farms). But these defaults are sane for a busy SMP.

Step 5: Pre-generate the world (stop lag before it spawns)

Generating brand-new terrain on the fly, while 100 people sprint into the unknown, is one of the nastiest sources of lag. Fix it ahead of time:

  1. Set a world border: /worldborder set 10000 (pick a sane diameter).
  2. Install Chunky and pre-generate up to that border before opening to players.

Now nobody triggers expensive world-gen mid-session — the chunks already exist on disk.

Step 6: Measure, don't guess — use Spark

When something does lag, don't poke at random settings. Install spark, run a profile while the lag is happening (5–10 minutes), and it'll tell you exactly which plugin, entity type, or chunk is eating your tick. This one tool will save you more time than any guide, including this one.

Step 7: The plugins worth running on a 100-player SMP

Keep the list lean — every plugin is tick budget. The essentials:

  • LuckPerms — permissions/ranks, done right.
  • EssentialsX — homes, warps, kits, the quality-of-life basics.
  • CoreProtect — block logging + grief rollback. On a public-ish SMP this is non-negotiable; one /co rollback will save your world someday.
  • Chunky and spark — from above.
  • ViaVersion — let players on different client versions join.
  • An anti-cheat like GrimAC once you're public.

(If you go Folia later, double-check each of these supports it — most of these do.)

Step 8: Don't get knocked offline — DDoS + backups

Two boring things that matter the moment your server gets popular:

  • DDoS protection: route traffic through a reverse proxy like TCPShield (the long-time standard) or NeoProtect. Players hit the proxy; the proxy filters attacks and forwards clean traffic to your real IP — which stays hidden.
  • Backups: automate them. World corruption and "oops I /filled the spawn" both happen. Daily off-server backups are cheap insurance.

Where to actually host it

  • Managed hosting (easiest): Shockbyte, BisectHosting, Host Havoc — pick a plan with a high-clock CPU and included DDoS protection. Expect roughly $15–40/mo for solid 100-player performance.
  • VPS / dedicated (most control): Hetzner, OVH, or a Hostinger VPS — cheaper per-spec and fully yours, but you manage everything. Watch out for cheap "shared" boxes with weak single-thread performance; benchmark before you commit.

The stack I'd actually run for 100 players

If I were spinning this up today:

  1. Paper on Java 21, launched with flags.sh flags, -Xms/-Xmx at 16G.
  2. A host with a 4.0GHz+ CPU and NVMe SSD.
  3. view-distance=7, simulation-distance=4, per-player-mob-spawns: true, Alternate Current redstone.
  4. World border set + Chunky pre-gen done before launch.
  5. LuckPerms + EssentialsX + CoreProtect + spark + ViaVersion, nothing extra.
  6. TCPShield in front, automated daily backups.
  7. spark always installed, so when lag shows up I find it in minutes.

That setup will hold 100 happy players. When you genuinely outgrow a single thread — players everywhere, redstone everywhere, the main thread pegged — that's when you graduate to Folia and start thinking in regions and cores.

Now go build something worth 100 players showing up for. 🛠️

Further reading: PaperMC docs, Folia docs, YouHaveTrouble's optimization guide, Paper-chan's optimization guide, Aikar's flags.

View on GitHub
Post