01 Choose the modpack version before the hosting plan
For modded Minecraft server hosting, the first requirement is software compatibility. Record the pack name and release, Minecraft version, loader family and loader build. A mod labelled for Fabric cannot be assumed to work on Forge or NeoForge, and a small game patch can require a different mod file. Fabric’s installation guide ↗ explicitly calls for matching game version and loader.
There is no single best Minecraft version for every modpack. Start with the pack you actually want: if an essential mod is unavailable on the newest release, that release is not a useful default for this group. Follow the pack author’s supported combination instead of upgrading just one component.
02 A server pack is not a copy of the client instance
Download a server distribution when the pack author provides one. It can include loader startup scripts, configuration and scripts or data that the client’s mods directory alone does not contain. A client instance may also include graphics, menu or input mods that do not belong on a headless server.
| Inventory item | Record before upload |
|---|---|
| Core software | Game, loader and pack release. |
| Required files | Server mods, configuration, scripts and custom data named by the pack author. |
| Client requirements | The exact client pack and any required resource dependencies. |
| Runtime | The supported Java executable and startup script. |
| Rollback | A complete old world and a copy of the working pack. |
Fabric’s own FAQ ↗ links several pack-distribution platforms. Use the original author’s release and documentation, not a reupload with a similar name.
03 Start clean, then import a world
- Create a separate instance with the chosen pack’s server files.
- Run its documented installer and startup script with the required Java runtime.
- Read the licence and accept only if you agree; wait for a completed startup.
- Join using the matching client pack and verify a pack-specific feature.
- Stop, copy the old world into a working test instance, then validate its content.
A fresh world that works while the imported world fails points toward world or configuration compatibility, not automatically a bad host. Keep the old instance untouched until the imported world has been checked. Avoid running the same live directory from two processes.
04 Size using a representative session
Pack downloads are not a reliable RAM calculator. Record memory pressure, repeated tick delays and disk growth while players use the pack’s actual machines, entities and dimensions. Leave operating-system headroom; allocating all machine memory to the Java heap can make the rest of the system unstable.
If startup fails, use the exit-code diagnostic workflow. If it starts but is slow, capture a compatible spark profile. Ask the host whether you can change Java, use the pack’s custom script, export everything and upgrade without recreating the world. Those controls can matter more than a broad “full mod support” badge.
05 Update the pack as one controlled change
Record a working manifest and export the whole world and required pack files before upgrading. Read the pack’s migration notes, test the new release on a copy and let regular players inspect progression and custom blocks. Downgrading a save already opened by newer mods may not be safe; preserve the pre-upgrade copy.
Missing dependencies such as Cloth Config should be resolved using the exact loader and required release, as explained in the dependency guide. Shader problems belong to client rendering diagnostics, not an automatic reinstall of the server. Keep fixes small enough that the next error has an identifiable cause.