Upgrading from v4

A v5 install converts a v4 config the first time it starts. Pack data from v4 does not carry over, so every player downloads the pack again on their first v5 join. The mod itself needs no hand upgrade: a v4 client with version syncing on, which is the default, pulls the v5 jar from Modrinth on its own (see clients follow the server).

What migrates automatically

• The config file. On the server, v5 reads automodpack-server.json and then server-config.json if it finds them. On the client, it reads automodpack-client.json and then client-config.json. The values land in the new server.conf or client.conf, and the old JSON is renamed to end in .backup.
• The file rules. The v4 syncedFiles list becomes the from-server list of the default main group, and allowEditsInFiles becomes that group's editable list. Leading slashes are stripped, and ! rules survive. The migrated main group lands in a category called General and is forced to required and selected by default, so every player keeps receiving the core files.
• The connection mode. A v4 setup with requireMagicPackets: false and an explicit bindPort becomes HTTP. Every other v4 setup becomes HOLEPUNCH, the v5 default.
• The settings that kept their names under a new spelling: modpackName becomes modpack.name, requireAutoModpackOnClient becomes require-modpack, addressToSend and portToSend become advertised-endpoint-host and advertised-endpoint-port, and the nag, bind, bandwidth, secret, loader-accept, and self-updater settings all carry over. On the client, syncAutoModpackVersion becomes sync-automodpack-version, syncLoaderVersion becomes sync-versions, and playMusic, updateSelectedModpackOnLaunch, and selfUpdater follow the same pattern.
• Dropped v4 options, named in the log: forceCopyFilesToStandardLocation, nonModpackFilesToDelete, updateIpsOnEveryStart, autoExcludeUnnecessaryFiles on the server, and selectedModpack, installedModpacks, allowRemoteNonModpackDeletions on the client.

What does not migrate

• Old pack data on clients. v5 reads none of it: not the automodpack/modpacks/ folders, not the v4 metadata caches next to the old config, not the v4 selectedModpack name. A v5 client downloads the pack again on its first join and picks the server's pack up there.
• The old certificate and pins. v4 kept its TLS pair and the client trust store under automodpack/.private/; v5 uses automodpack/credentials/ and a per-user pin store, and migrates neither. A fresh v5 server generates a new self-signed certificate, so every player verifies the server once more on their first v5 join, even if they verified it under v4.

Leftovers

On the first v5 boot, the log lists what older versions left behind in the automodpack folder, with sizes:

Leftovers from an older AutoModpack are still using X in ...: This version does not read them and deleting them is safe.

Deleting the listed entries is safe. v5 never reads them again.

Clients follow the server

When you update the server to v5, clients do not need a hand from you. On their next launch or join, a client with version syncing on fetches the v5 build for its Minecraft version and loader from Modrinth and restarts into it. Version syncing is on by default (sync-automodpack-version); a player who turned it off stays on v4 and gets a version mismatch kick that names the version to install. The same rule covers every later AutoModpack update: clients follow the version the server runs. The details, including the per-client self-updater setting, are in AutoModpack's own updates.

Upgrade steps

1. Back up the server folder, including automodpack/.
2. Replace the AutoModpack jar in the server's mods folder with the v5 jar. It is the same mod on the same Modrinth project; do not keep both jars.
3. Start the server. The old config becomes server.conf, and the log lists every dropped option and every leftover folder. Read server.conf once: the modpack section is the new home of your old syncedFiles rules.
4. Run /automodpack generate to publish the first v5 generation.
5. Connect once with a clean client that has only AutoModpack installed. It downloads the pack again in the v5 format and verifies the server's new certificate.
6. Players: nothing to hand out by default. Their clients sync themselves to v5 on the next join. Only a player with sync-automodpack-version: false needs the v5 jar by hand.

Commands

What v5 adds

• Groups: split the pack into required and optional parts that players pick in-game, with conflicts resolved on the client.
• Generations: every publish is a numbered generation with patch notes, preview and can be rolled back into.
• Connection modes: the new HOLEPUNCH mode carries the pack over the Minecraft connection itself, so servers behind Minecraft-only firewalls, lan share mods, proxies, and some hostings now just work with no additional setup.
• Hosting rework: the whole pack is three HTTP GET routes, so any static HTTPS host or S3-compatible bucket can serve it.
• New verification methods: published DNSSEC records, pinned join addresses, and bootstrap files for one-file onboarding.
• Human-editable configs: server.conf and client.conf replace the old jsons.
• Swappable waiting music: drop an .ogg in the pack sources and players hear it during downloads.
• A sharper editable policy: All editable files copy to client root, player edits survive, until modpack modifies them they get backedup and overwritten, after which players can edit them freely again.
• More reliable in-place loading: v4 often falled back to force-copying mods into the standard mods folder, which cost a restart per update. v5 loads more mods straight from the managed projection.
• Client-side safety nets: an instance timeline that records every step, offline pack history with restore, detachment, storage repair and cleanup.