The person who maintains the modpack

The version pins, the split between server-side and client-side mods, the config overrides that stop a known crash, the update calendar, the client download and the Discord thread explaining why a favourite mod is gone: on almost every modded server, one person owns all of it. The server's stability is largely a record of that person's judgement, and it tends to last about as long as they do.

The job, game by game

On a Minecraft modpack server the curator chooses the mods and their versions, down to the loader version they all have to agree on. They ship config changes that fix problems the mod authors have not, and they keep client-only mods off the server, where some will crash it at start-up (why the two sides differ). They also set how large the download is allowed to get, which goes a long way towards deciding how many people finish it (why modded servers take so long to join). The job is big enough that tools exist for it. One of them, packwiz, keeps a pack as small TOML files that can live in git, pulls mods from CurseForge and Modrinth, and its installer can bring a server up to date from the pack's URL every time the start script runs.

On Arma 3 the mods come from the Steam Workshop and the chores change. Each mod's signing key goes into the server's keys folder, and a Linux host needs the mod files in lower case, which some mods do not ship, so somebody runs a renaming script after updates.

Garry's Mod splits the work again. The server mounts a Workshop collection at start-up with +host_workshop_collection, but apart from the current map and the gamemode, clients download only what the server marks for them: one resource.AddWorkshop line per addon that carries content such as models or sounds. Lua-only addons need no line. A missing one shows up as error models and missing textures on players' screens, and all of these calls together share a limit of 8,192 downloadable files. The collection and the lines are two lists, often kept in step by hand.

Deciding when

Most of the curator's decisions are about timing. Mod authors publish fixes on their own schedules, loaders move on theirs, and on Workshop games the clients update subscribed items automatically, so the server has to keep pace with its own players. Update the day a new version lands and something else in the pack may break. Wait a month and the fix players asked for arrives a month late, with a bigger jump behind it. No interval is right; the curator picks one they can defend.

Each decision has a social side, and the curator carries that too. Removing a mod whose author has stopped updating it (what happens when mod authors walk away) means explaining, usually more than once, why a player's base now has a hole where a machine used to be. Adding one means answering the other requests in the queue, most of them with a no.

A bus factor of one

Software people call it the bus factor: how many people would have to disappear before a project stalls. On most modded servers it is one. The knowledge that matters is rarely written down: why a mod is pinned two versions back, which config line stops the crash on world load, which library is there only because something else needs it, which update was tried last spring and rolled back. The accounts tend to sit in one place too, with the Workshop collection on one Steam account and the pack project behind one person's login.

Curators burn out the way other admins do (what burnout looks like, and how to hand over), but the failure looks different. When a moderator leaves, the server keeps running and gets a little worse. When the curator leaves, the pack freezes. Nobody else can update it safely, so nobody does, and the server stays on whatever versions were current the week they stopped. Whoever inherits it often finds that rebuilding the pack from scratch is easier than reverse-engineering the old one.

Habits that let the curator take a week off

None of these remove the bus factor, but each lowers the cost of the curator's absence.

• A changelog that records reasons as well as changes, such as the crash a pin avoids or the mod it is waiting on. It answers players' questions before they are asked (a changelog people actually read), and it doubles as the handover document nobody has time to write later.
• A test server. A copy of the world on a second instance, where each update runs first and a real client joins, catches most breakage before players see it (updating without breaking things).
• A fixed update day, announced in advance, which turns a stream of separate arguments into one expected event.
• The pack in version control, so every change is dated and can be undone.
• A second person with access to every account, and a written policy for mod requests: what a mod needs to get in, and what gets one removed. The policy lets the curator say no without it becoming personal.