Running a Minecraft SMP well is a chain of decisions, and each link either holds the tick or drops it. People tend to obsess over one layer, usually RAM, and ignore the rest. The result is a server that looks fine on paper and stutters the moment ten friends log in and start loading chunks in different directions. Performance is a stack. Every layer, from the machine underneath to the last plugin you install, is a choice, and each choice has a reason you can actually name. This post walks the whole chain top to bottom and explains the why at each stage. It is a map, not an encyclopaedia, so where a layer deserves its own deep dive, we link to it rather than repeat it here.
The through-line is simple. A tick has 50 milliseconds to do all its work, twenty times a second. Everything below is about protecting that budget, and understanding where each layer spends it.
Where to run it
Before any config, decide what your server lives on, because that decision caps everything else. A real SMP wants a dedicated box, or at least a genuinely reserved slice of one. Sharing in principle is fine. The problem with cheap shared hosting is overselling: a node sold to carry three times the tenants its cores and RAM can actually hold. On a box like that, your tick thread is constantly fighting a stranger's for the same core, and no amount of tuning fixes contention that is baked into the business model. You cannot tune your way out of a box carrying too many tenants.
This matters more for Minecraft than for most workloads, because the tick is unforgiving about timing. A web app can absorb a busy neighbour as a slightly slower page. Your server absorbs it as a visible lag spike at the worst moment. If you are weighing the two models, we lay out the trade properly in dedicated vs shared game hosting, and if you want to check whether a host is overselling before you buy, spotting overselling in game hosting shows you the tells.
The machine underneath
Once the box is genuinely yours, the hardware inside it decides your ceiling. The tick loop runs on a single thread, so the CPU that matters is the one that runs one thread quickly and stalls the least while doing it. Two things set that: per-core clock and IPC, which decide how fast the thread runs when it is running, and cache, which decides how often it stops to wait on memory. A game tick spends much of its time chasing pointers around the heap, and every time the data it wants is not in cache, the core stalls. That stall is the real enemy, and more cache beats more gigahertz for fighting it.
This is why a large-cache AMD X3D part wins for this workload, and it is a dedicated-only story we will scope honestly: the extra L3 only helps cleanly when the chip is yours and not split across whatever else is on the box. The full argument, including why hybrid P-core and E-core chips can drop your tick onto a weak core and leave you chasing a ghost, is in choosing a CPU for Minecraft. Storage matters too, but for a plainer reason: chunk loads and world saves are latency-sensitive, so Gen4 NVMe keeps them from stalling the tick where a cheap SATA SSD would.
Now the honest part about RAM, because it is the spec people fixate on. RAM is a floor, not an accelerator. Your server needs enough that the JVM is not constantly garbage-collecting and never swapping, and past that point more gigabytes do nothing for your tick. A 32GB server does not tick faster than a well-sized 8GB one; it just holds more before it struggles. We work through the actual sizing in how much RAM a Minecraft server needs. If you want the whole hardware and OS stack in one place, and the reasoning for each tuning lever, our stack is the full tour.
Server software
Hardware and a tuned OS give you a fast, quiet box. The server software decides how well it uses that. For a plugin SMP we recommend Paper, and the reasoning is specific rather than tribal. Paper is the sensible default and has been for years: fast, universally compatible, and already moving the work that can safely leave the tick thread, such as chunk loading, generation and lighting, onto worker threads. Purpur builds on Paper and adds a large settings file for gameplay control, plus a few settings that save real tick time, villager lobotomize chief among them. The weighing between the two is in Paper vs Purpur.
Purpur keeps Paper's plugin compatibility, so the switch is a jar swap and your existing plugins carry over. Both sit in a family of forks that trade differently against vanilla behaviour, and if you want to understand where each one fits, vanilla vs Paper vs Purpur maps the whole tree. Keep vanilla mechanics in the back of your mind throughout: a performance fork is only worth running if it does not quietly break the farms and redstone your players built, which is what the next section is really about.
Configuring it
A fresh Paper install is already fast, but the settings that matter most are the ones that trade a bit of vanilla behaviour for tick time, and how far you are willing to push that trade depends entirely on your server. So the right way to think about configuration is by tier, where each tier is defined by one thing: how much vanilla behaviour you are prepared to give up for tick time. We use three.
Full-Vanilla applies only optimisations a player could never detect. Every farm, redstone circuit and mob behaves exactly as vanilla, and if a player finds a difference, it is a bug and not a setting. Kinda-Vanilla adds the widely accepted trade-offs that almost nobody notices, though a few very technical contraptions might drift. Semi-Vanilla is aggressive: real TPS savings, but some AFK-range farms, item sorters and distance-sensitive builds will behave differently, so you only pick it if raw TPS matters more than edge-case builds.
For most SMPs, Kinda-Vanilla is the right default. It buys you a large chunk of the available performance for trade-offs your players are very unlikely to ever notice, and it leaves the door open to move either way once you have profiled real load. The full setting-by-setting tables, view distance, mob caps, entity activation, villagers, redstone and the rest, with the exact value for each tier and what each one changes, live in the SMP tuning guide. Pick one tier for the whole server, apply it, then re-profile and nudge. The tables are the detail, so we will not reproduce them here.
Plugins, and the tick cost of every one
Here is the principle to hold onto: every plugin costs tick time. Each one runs code inside that 50ms budget, listens for events, and adds a little to every tick whether you notice it or not. A lean, well-established set beats a big pile of half-used plugins every time, so run what earns its place and audit the rest off. Grouped by the job they do, this is a solid SMP baseline.
For diagnosis, spark is the profiler you use to find out where the tick actually goes, and it is the first thing to install because it is how you make every other decision with evidence instead of guesswork. For permissions, LuckPerms is the established standard and worth learning properly. For safety, CoreProtect logs block changes and lets you roll back grief in seconds, which you will be grateful for the first time someone torches a base. For land protection, a claim plugin like GriefPrevention lets players fence off what is theirs without staff mediating every dispute.
For quality of life, EssentialsX covers homes, warps, kits and a basic economy, though it is broad, so enable only the modules you use and leave the rest off to keep its tick cost down. For world preparation, Chunky pre-generates the map so chunk generation happens ahead of time instead of lagging live play when a player sprints into fresh terrain. For client compatibility, ViaVersion and ViaBackwards let players on different Minecraft versions join the same server, which saves you forcing everyone onto one exact client. For a live map, BlueMap or Dynmap gives players a web view of the world, which is optional but popular. The two render differently, and it matters for cost. BlueMap draws a full 3D view of the world and writes it out as static files, which looks impressive but is storage-heavy on a large or well-explored map, running to several gigabytes. Dynmap renders flat 2D tiles and stores far less. Either way, run the render on a schedule and keep it off the main tick thread, so building the map never eats into your 50ms. On a public or PvP server, an anti-cheat is worth the tick it costs, though it is overkill for a small whitelisted friends server.
Whatever you install, revisit the list regularly. A plugin you stopped using is still charging you tick time for nothing.
Running and growing it
A live SMP is a loop, not a launch. Once players are on, profile a busy window with spark rather than an idle one, and when you do, drag-select the worst moment. An averaged profile hides spikes, and spikes are what your players feel, so the average will tell you everything is fine while the server hitches every thirty seconds. Read MSPT, find the real cost, change one thing, and profile again. Keep real backups running the whole time, tested occasionally, because the day you need one is not the day to discover it was never working.
A worked example shows why hardware is rarely the answer. A dense villager trading hall is one of the most common causes of SMP lag, and it is not a CPU problem. Each villager repeatedly scans for job-site POIs and competing villagers, and in a packed hall that competitor scanning dominates the tick. Throwing a faster chip at it barely moves the needle, because the cost scales with the crowd. The fix is to lobotomise the villagers so the ones that cannot reach a job site or bed skip the expensive brain logic, and to pen them so they cannot path, which caps the scanning. That is a config-and-build fix, and no amount of clock speed substitutes for it.
Eventually you may outgrow one node. This usually happens for a structural reason rather than a slow one: a single tick thread has a hard ceiling on how many players and how much simulation it can carry. That is when a proxy like Velocity earns its keep, sitting in front of several backend servers and spreading players across them so each backend ticks a manageable share. Growing into a multi-server network is its own project, and if you are building toward a community or content around your server, running a Minecraft server for creators covers the shape of it.
None of this is a secret, and none of it is hard once you can see where the tick goes. The stack just has to be honest at every layer, from a box that is genuinely yours up to a plugin list that earns its place. If you want that foundation without assembling it yourself, our Minecraft hosting runs the large-cache X3D parts on dedicated boxes for exactly the reasons above, and you can browse the rest of what we host from there.