This page follows one pack through a client: when updates apply, where the bytes come from, and what happens to files players have touched.
When updates apply
With update-selected-modpack-on-launch on (the default), every launch fetches the server's current generation and applies it before the game loads anything. No restart is involved at all: the update finishes before the loaders run, so the fresh mods are simply what loads, and configs land on disk on the way.
Even at launch, a restart is forced when the loader type, the loader version, or the game version changes, and when files have to land in the standard mods folder: first-install removals of player-approved local mods, corrected pack-owned copies, editable mods, nested-jar fixes, and removed duplicate or pack-owned mod copies all write there. At launch, picking optional groups never forces a restart; in-game, a group change that adds or removes mods requires one.
Joining a server while in-game goes through a review screen instead: it shows what the update would change, asks for consent when your own extra mods would be touched, and applies group selections. Mod jars that could not be matched on Modrinth or CurseForge are listed as unverified and need an explicit risk acknowledgement before the download starts. A first install always waits for this review. A pack installed through a trusted bootstrap is the exception and applies on that launch. In-game the rules change, because mod loaders cannot hot-swap mods and AutoModpack can only alter loading very early, before the game starts: any change that touches mods, in the managed projection or the standard folder, requires a restart to load the fresh jars. A change to other files applies in place and only offers a restart, and you can return to the game without it.
When an installed pack starts being served from a new address, the client shows an origin change prompt before trusting the address, and remembers the approved origins per pack. A player who declines the prompt cancels the join: the game returns to the multiplayer screen, the local pack stays as it is, and the prompt shows again on the next join.
With update-selected-modpack-on-launch off, launch loads the current state without contacting the server, and updates happen only when you join.
Where files come from
The client first asks the platform APIs. Files found on Modrinth or CurseForge download straight from their CDNs through direct links, so mod authors get the download credit and your server ships less traffic. The client matches files by SHA-1 on Modrinth and by content fingerprint on CurseForge.
If a platform source is too slow and the pack host measures much faster, the client pulls those files from the host instead. A platform that already delivers at a healthy speed stays first.
Everything else downloads from the modpack host over its TLS connection.
Editable files
editable marks pack files players may change, such as options.txt and config/** by default. Every editable file keeps its copy in the game directory, no matter the type: an editable mod jar materializes in the standard mods folder and loads from there. The client records the player's copy in an overlay that shadows the pack version, so ordinary edits survive every update.
Removing an editable file is a statement, not an accident: the file stays away through updates and through edits to other files. The removal is spent when the server replaces that file's content or removes the path from the editable list; either one brings the pack's version back exactly once.
The comparison that matters is between the server's new generation and the generation currently installed. When the server changes an editable file:
- The instance timeline records the player's copy before AutoModpack writes.
- The new server version is applied, exactly once.
- Edits made after that go into the overlay again until the server changes the file once more.
An operator who wants a file's edits to never be replaced simply never changes that file on the server. Every editable file follows the same rule; there is no second list.
A file that is not editable but no longer matches the pack is treated the same way: the player's bytes are recorded on the instance timeline, then the pack version is written. The instance timeline labels these files Brought back in sync with the pack, so silent sync-backs of files that rewrite themselves, like configs with a timestamp header, are visible in the file list with their older bytes one restore away.
Deletions are measured
When a file leaves the pack, clients remove their copy only when the generation's ownership ledger proves the file is AutoModpack's: the path is a managed location, and the local hash and size match a historical entry. Anything the player created or changed survives, and so does everything under saves/, screenshots/, logs/, and automodpack/. Before a deletion, the file's bytes are kept in the client's own store. The same reserved roots bound the write side: a pack can never write into saves/, screenshots/, logs/, or automodpack/ either, and a manifest that tries fails validation at publish.
AutoModpack's own updates
Clients follow the AutoModpack version the server runs when sync-automodpack-version is on, updating or downgrading through Modrinth. This flow never runs through the pack: /automodpack generate excludes the AutoModpack jar, so the jar a client loads depends only on the server's version, not on pack content. A client with self-updater on also checks Modrinth for newer releases on its own. Updates stage a version swap and apply it on restart. The mod never moves a client below version 5.0.0; a client already below it, such as a beta or release candidate, still follows the server forward. Both settings are in the client config.