Minecraft SMP launch checklist: everything before day one

Almost everything that decides whether an SMP is still running in six months is decided before the first player joins. Not the hardware - the seed you cannot change, the border you did not set, the op you handed out, the backup you never tested. A server you can fix in an afternoon on day zero takes a community vote and a week of arguments on day thirty. This is the order to do it in, with the actual settings, and it assumes Paper because that is what nearly every SMP runs.

Decide the rules before you generate the world#

Every one of these is trivial to change in a config file and almost impossible to change socially once people have built around it. Settle them in writing first, with whoever is actually going to play:

• PvP on or off, and whether that differs at spawn.
• Claims, a trust system, or nothing but a rule against stealing.
• Difficulty, and whether keepInventory is on. The second one changes the whole risk model of the game.
• Whether farms are allowed, and which ones. "No mob grinders" is a legitimate rule; discovering that opinion after somebody spent a week on one is not.
• What happens to the end and the nether: shared, reset periodically, or a separate resource world.
• Whether the world ever wipes, and if so on what trigger.
• Who can use teleport commands, and whether they cost anything.

Write the answers into a pinned message and into the server itself. The point is not bureaucracy; it is that a server with an ambiguous rule gets one argument per week and a server with a written one gets none.

Then be honest about size, because it drives everything downstream. Ten friends is a different server from forty applicants, and the difference is not only memory - it is moderation, claims, spawn design and whether an economy is worth having. How many players fit on a server has the sizing side, and the rule of thumb for Minecraft specifically is in how much RAM a Minecraft server needs.

Software, version and the world you will keep#

Run Paper. It is compatible with Spigot and Bukkit plugins, it fixes things vanilla does not, and every optimisation guide you will read assumes it. Pin a version and stay there for the season: launching on a release that shipped last week means your plugin list is the test suite. Paper, Fabric or vanilla covers the choice properly, and the Java version has to match the Minecraft version - that pairing is in JVM flags and Java versions.

Then make the world once, properly, because the seed is permanent the moment somebody builds a house.

1. Choose the seed deliberately or take a random one, but load it in single player on the same version first and walk around spawn. A spawn on a mushroom island or in the middle of an ocean is a bad start you cannot undo.
2. Set level-seed in server.properties before the first start. After the world exists the setting does nothing.
3. Set a border in every dimension. /worldborder set 10000 sets the diameter, not the radius, centred on /worldborder center 0 0. The nether is eight times smaller in scale, so it gets its own: /execute in minecraft:the_nether run worldborder set 1250.
4. Pre-generate inside the border, with nobody online.

Chunky is the standard tool for the last step:

$ chunky world world$ chunky center 0 0$ chunky shape square$ chunky radius 5000$ chunky start

/chunky progress, /chunky pause, /chunky continue and /chunky cancel control it from there. Terrain generation is the most expensive thing a running server does, and doing it in advance turns a permanent source of lag spikes into a one-off disk cost. It is the highest-value hour you will spend before launch.

That disk cost is real, so plan for it. A region file covers 512 by 512 blocks, and a fully generated area works out roughly like this:

Those ranges are wide because they genuinely vary with terrain, version and world height. Add the nether and the end on top, then add whatever a web map renders if you install one. Check the figure against your plan's disk before you start, not after: the smallest Minecraft tier here has 15 GB, which a 20,000-block border will eat on its own. World border and pregeneration goes through the trade-offs, and Minecraft web maps covers what a rendered map adds to the total.

server.properties for launch day#

Most of this file can stay at its default. These are the ones worth a decision:

Two of those do most of the work. view-distance is how many chunks the server sends to each client; simulation-distance is how many actually tick. Dropping simulation distance costs players almost nothing visually and saves the most CPU of any single setting, because it shrinks the number of entities, hoppers and redstone circuits the server has to run. Dropping view distance from 10 to 8 removes about a third of the chunks each player holds.

Note that max-world-size is a radius, while /worldborder set takes a diameter. Setting the property to 5000 for a 10,000-wide border is correct and looks wrong.

Paper's own tuning lives elsewhere - config/paper-global.yml, config/paper-world-defaults.yml, spigot.yml and bukkit.yml - and it is worth a pass before launch rather than during your first lag crisis. The Paper optimisation guide goes key by key. Resist the temptation to paste somebody's complete "best settings" file: several popular presets quietly break mob farms, redstone timing or villager mechanics, and you will not connect the complaint to the change three weeks later.

Permissions and staff, without handing out op#

Op is not a rank, it is a bypass. An opped player ignores claims, ignores WorldGuard regions, ignores most protection plugins and can run every command in the game. Handing op to a moderator so they can kick people gives them the ability to delete the world by accident.

Install LuckPerms first, build groups, and put people in groups:

$ lp creategroup member$ lp creategroup moderator$ lp group moderator parent add member$ lp group moderator permission set essentials.kick true$ lp group moderator permission set essentials.mute true$ lp user Steve parent add moderator

/lp editor opens a web editor with a one-time link, which is far less error-prone than doing bulk changes by command. Keep the owner as the only op, and get into the habit of de-opping yourself for normal play so that you find out when a protection rule is broken rather than silently passing through it. The LuckPerms guide covers inheritance and contexts, and whitelist and permissions covers the vanilla side.

Panel access is a separate question from in-game power, and it should stay separate. A moderator who needs to restart the server does not need your billing. The panel has roles, teams and subusers with granular permissions - console only, files only, no billing - plus invitations by link, join code or email, time-boxed access, and a per-server activity log so you can see who did what. Subusers and least privilege has the pattern.

Protection, logging and rollback#

Install block logging before launch, not after the first grief. CoreProtect is the standard, it is free, and it answers the only question that matters after an incident: who, what, when, and can it be undone.

$ co inspect$ co lookup u:Steve t:3h r:20$ co rollback u:Steve t:3h r:20$ co purge t:60d

/co inspect toggles a mode where clicking a block prints its history. The rollback syntax is the same as the lookup syntax, which is deliberate: look first, then roll back the exact same selection. Set a purge on a schedule so the log does not grow without limit.

Claims are the other half. GriefPrevention is the free default and gives players a golden shovel to claim land themselves; WorldGuard is region-based and staff-defined, better for spawn and public areas than for everyone's base. Pick one model and explain it in the rules; running both usually confuses people about which one protects them.

Anti-cheat deserves an honest note. On a whitelisted server full of people you know, you do not need one, and free anti-cheats generate false positives that will annoy your players more than cheating will. If the server is public, GrimAC is the well-regarded free option and the good commercial ones are paid. Grief protection and anti-cheat compares them properly.

Whitelist, identity and getting people in#

Turn the whitelist on before the first start, and add everybody before you post the address. Nobody's first experience of your server should be a kick message.

$ whitelist add Steve$ whitelist list$ whitelist reload

enforce-whitelist=true matters more than it looks: without it, removing somebody from the list does not remove them from the server until they disconnect on their own. With it, the list is applied to players already online when it reloads.

Keep online-mode=true. It is what makes a name correspond to a person: UUIDs come from Mojang, bans stick, and plugin data stays attached to the right account. An offline-mode server has none of that, and anyone can connect as anyone.

If Bedrock players are joining through Geyser and Floodgate, their identifiers are issued by Floodgate rather than Mojang and their names carry a prefix, so whitelisting them is not the same command as whitelisting a Java player. Sort that out before launch day with a test account - Geyser and Bedrock crossplay has the setup.

Backups, schedules, and a restore you have actually run#

A backup you have never restored is a guess about a file you have never opened. Before launch, take a backup, restore it onto the empty server, and watch how long it takes. That is the only way to know what the bad day looks like while the bad day is not happening.

Game plans on RE:NODE include backup slots, on demand or on a schedule, restored with a button, downloadable, and lockable so rotation does not remove the one you care about. They are stored off the machine they protect. One thing to know in advance: deleting a server deletes its backups, locked ones included, so anything you truly cannot lose should also be downloaded.

A schedule is a cron expression plus ordered tasks with delays, which lets you flush the world to disk before the copy is taken:

0 5 * * *      daily at 05:00  task 1  console command   save-all flush  delay   30 seconds  task 2  backup

Add a second schedule for a manual-style backup before anything risky, and take one by hand before every plugin install and every version upgrade. Backups that actually restore and testing a restore before you need it are the longer arguments for both halves of this, and cron expressions explained decodes the five fields if the syntax is new.

The address, the MOTD and the first impression#

Three small things that people judge the server by before they have played a minute.

The icon. A file called server-icon.png in the server root, exactly 64 by 64 pixels. It appears in the server list next to your name. It takes two minutes and almost nobody does it.

The MOTD. Two short lines in server.properties. Put something useful on the second line, such as the current version or whether applications are open.

The address. The panel allocates a port, and it may not be 25565, which means players have to type an address with a port on the end and will get it wrong. An SRV record fixes that: point _minecraft._tcp.yourdomain at the host and port and players type mc.example.com with nothing after it. The full record layout is in SRV records for Minecraft, and subdomains for servers covers pointing the name at the address in the first place.

If you are forcing a resource pack, set both resource-pack and resource-pack-sha1, and host the file somewhere stable - a link that dies takes every new player's join with it. MOTD, icon and resource packs covers the formatting and the hosting.

A baseline, and the first week#

Install spark before launch and record what an idle server looks like: /spark tps on an empty world, then again with two or three people on. Those numbers are your baseline, and without them "the server feels slow" is unanswerable. Diagnosing Minecraft lag with spark covers reading the reports; the point right now is simply to have a before.

Then, for the first week:

• Add plugins one at a time, with a restart and a look at the console between each. Five at once means the one that breaks something is unidentifiable.
• Watch the console graphs for memory, CPU and disk against the plan's limits. A server that reaches its memory limit is stopped and restarted clean rather than left to swap, so it is better to notice the climb than the restart.
• Leave restart schedules alone until you know whether you need one. A nightly restart that fixes nothing is a nightly interruption - see restart schedules that help.
• Take the crash watcher seriously if it speaks up. RE:NODE polls every two minutes for a server that went offline or whose uptime went backwards, and three restarts in an hour raises a warning on the server page and opens a ticket automatically. That is a signal to find the cause, not to silence it.
• Keep a note of what you changed and when. In three weeks it will be the only way to connect a symptom to a cause.

The last item on the checklist is the one people skip: decide, in advance, what you will do when something goes badly wrong. Which backup you restore, who tells the players, and how long you will spend trying to fix it before you roll back. Write it down while you are calm.

FAQ#

How much RAM does a ten-player SMP need?

With a pre-generated world, a short plugin list and view distance around 8, 4 GB is comfortable and 2 GB works for something close to vanilla. Plugins and modpacks are what actually move that number, not the player count - a heavily modded server for the same ten people can want three times as much.

Should the server be whitelisted?

For an SMP, yes. A whitelist removes most moderation problems before they exist and makes grief protection a formality rather than an arms race. You can always open it later; closing it after a bad week is much harder.

Can I change the seed or the world later?

Not without starting over. The seed is baked into the world at creation, and level-seed is ignored afterwards. The border can be changed freely, and new terrain generated outside it will match the existing world, so growing a border is safe. Shrinking one below where people have built is not.

Do I need a domain name?

No, but it is the cheapest improvement you can make. An address people can remember, with no port on the end, gets typed correctly more often, and it means you can move the server later without telling everybody a new number.

What should I do the first time somebody griefs?

Look before you roll back. /co inspect on the damaged blocks tells you who and when, then /co rollback with the same radius and time window undoes exactly that. Then fix the cause, which is nearly always that the area was not claimed or the player was opped.

How many plugins is too many for an SMP?

There is no count, but every plugin runs on the same single main thread, so the list should be deliberate rather than collected. Permissions, protection, logging and a profiler cover most of what a server needs - the plugins worth installing is the short list and the categories to be careful with.