Key takeaways
- Performance mods first. Everything else is negotiable and this is not.
- Quality of life mods keep people playing longer than content mods do.
- Decide the inventory and travel questions before launch, because changing them later feels like a nerf.
Small friend servers die for predictable reasons: someone cannot join because of a mod version, the world lags on a Saturday night, or the mod list grew until nobody knew what was installed. A deliberate list prevents all three.
Layer one: performance
A renderer replacement, a culling mod and a chunk management mod, plus a profiler on the server side. This layer is invisible when it works and is the difference between a server people join and one they make excuses about.
Agree the versions before anyone builds anything. The most common cause of a dead SMP is a mod list nobody can reproduce two months later.
Layer two: quality of life
Storage previews, inventory sorting, a minimap if the group wants one, and a death recovery solution. These are small additions that reduce friction in the parts of the game people do hundreds of times.
The death recovery question is the first real decision. Graves remove a genuine consequence, and on a friend server that is usually the right call – people have jobs and cannot spend an evening re-gearing. Make the choice explicitly rather than letting it happen.
Layer three: the arguments
Two categories cause most disagreements. Travel mods – waystones, teleport commands – change how far apart people build and therefore what the server looks like. Inventory mods – backpacks in particular – change how much a trip costs.
Both are fine choices. Neither can be reversed comfortably once people have built around them. If half the group wants a sprawling connected world and half wants everyone in one valley, that is a conversation to have before the first night, not after the first month.
Content mods last
Structure and mob mods are the fun part of the list and the least important. They can be added later, they mostly affect new chunks, and a server with none of them survives perfectly well if the first two layers are right.
Our view is that small servers fail from friction rather than boredom. Nobody quits because there were not enough biomes. They quit because joining took twenty minutes, the world lagged, and their gear was lost in the nether on a Tuesday.
Before launch
Set the border, pre-generate, test the full mod list with two people, and write the list down somewhere the group can read it. Performance details are in server performance tuning, and structure density in structure-heavy servers.
Version discipline
Pick a game version, a loader version, and a fixed mod list, then write all three down where everyone can see them. Most small servers die when somebody updates a mod, two players end up on different versions, and joining becomes a support exercise nobody has time for.
A shared launcher profile or a pack file removes the problem entirely. It takes twenty minutes to set up and it is the single highest-value thing an SMP organiser can do.
Backups that actually exist
A backup schedule that nobody has tested is not a backup. Run one restore into a copy of the world before you need it, confirm the world loads with the mod list, and check how long the restore takes. Discovering that a restore takes four hours during an emergency is a bad time to find out.
Keep at least one backup from before any mod list change, permanently. That is the one you will want if a mod turns out to corrupt chunks.
Social rules beat technical ones
Most SMP problems are not technical. Griefing, build proximity, resource hoarding and who gets the spawn area are social questions, and no plugin resolves them as well as a short conversation before launch. Write down three rules, keep them short, and revisit them when something goes wrong rather than pre-empting every case.
A starting list
Performance: a renderer replacement, a culling mod, a chunk management mod, a profiler. Quality of life: storage previews, inventory sorting, a death recovery solution. Optional and discussed first: waystones or another travel option. Content, added later if at all: one structure mod, one mob mod.
That is nine mods, all of which update reliably, none of which invalidate each other. A list like this survives a year. A list of forty does not survive the next game version.
Images: Moog’s Voyager Structures project gallery on Modrinth.