1. Choose server software before you choose add-ons
The server software decides what kind of extensions the server can run. Vanilla is Mojang's normal server and is the cleanest choice when you want the original game with no plugin or mod framework. Paper/Purpur is the usual choice for plugin-based servers and also exposes more performance controls. Fabric is lightweight and popular for performance mods and many modern modpacks. Forge and NeoForge are separate loader families used by larger mod ecosystems. Quilt is another mod loader with its own compatibility rules.
Do not choose a loader because a single mod name sounds familiar. Open the mod or modpack page and check the exact Minecraft version and loader it supports. A file for NeoForge is not automatically safe on Forge, and a Fabric mod does not belong in a Paper plugins folder.
| Goal | Good starting point |
|---|---|
| Plain survival / SMP | Vanilla or Paper/Purpur |
| Plugins, moderation, minigames | Paper/Purpur |
| Lightweight mods / performance mods | Fabric |
| Large traditional modpack | Forge or NeoForge, exactly as the pack requires |
| Pack explicitly built for Quilt | Quilt |
2. Lock the Minecraft version
A Minecraft server version is not a cosmetic setting. Worlds, loaders, mods, plugins, and Java requirements can all depend on it. If you already know which modpack you want, let the pack's supported version drive the decision. If you are making a fresh vanilla or plugin server, choosing a current stable release usually gives you the broadest support.
Upgrading later is possible, but treat it as a migration: back up the world, check every critical add-on, then test the new version. Downgrading worlds is much riskier because newer chunks and data formats may not exist in older releases.
3. Pick a plan for the workload, not only player count
Player count matters, but it is not the only thing using resources. A quiet 10-player vanilla server can be lighter than a two-player technical world with huge farms and constant chunk loading. Modpacks can add hundreds of classes, textures, recipes, entities, and background systems before anyone joins.
SPUDZWARE account plans can be applied to servers you own, so you do not have to throw away the world just because the workload grows. Start with enough headroom for what you actually plan to run, then watch real usage instead of guessing from a player number alone.
4. Set conservative first-day settings
View distance controls how far terrain is sent around players. Simulation distance controls how far away the game actively ticks entities, redstone, crops, and other mechanics. A large simulation distance is often more expensive than players expect because those chunks keep doing work instead of simply being visible.
Start at the plan defaults. Raise distances only after the server is stable. The same rule applies to entity-heavy farms, chunk loaders, pregeneration tools, and plugins that scan large areas. You can always increase a setting later; recovering from a server that is permanently overloaded is more annoying.
5. Let the first start finish
The first start may create world files, generate spawn, install loader components, and prepare configuration. If the panel says the server is still starting, do not hammer Restart. Repeated power actions can turn a slow first boot into a harder problem because you never let one launch finish far enough to produce a useful error or a complete world.
Join yourself, move away from spawn, restart once normally, and confirm the world comes back. Then test the add-ons and permissions you care about. A five-minute private check catches a surprising number of mistakes.
What to read next
If you plan to use a modpack, continue with the mods, plugins & modpacks guide. If the server already works but memory rises during exploration, read the RAM & performance guide. For moving an existing world, read worlds & backups before uploading.