# 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](#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](how-it-works/client-updates#automodpacks-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

| v4 | v5 |
| --- | --- |
| `/automodpack host connections` | `/automodpack host activity` |
| `/automodpack host fingerprint` | The same command, now with `dns` and `share` subcommands |
| `/automodpack generate` | The same command, now with `preview`, `notes`, `if-content`, `history`, `revert`, `storage`, and `export-http` subcommands |
| (new) | `/automodpack groups` |
| (new) | `/automodpack host bootstrap pin` and `/automodpack host bootstrap install` |
| `/automodpack config reload` | Unchanged |

## What v5 adds

- [Groups](groups): split the pack into required and optional parts that players pick in-game, with conflicts resolved on the client.
- [Generations](how-it-works/generations): every publish is a numbered generation with patch notes, preview and can be rolled back into.
- [Connection modes](how-it-works/hosting): 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](how-it-works/hosting#http-contract-export): the whole pack is three HTTP GET routes, so any static HTTPS host or S3-compatible bucket can serve it.
- [New verification methods](security): published [DNSSEC records](security#dnssec-amp1), [pinned join addresses](security#pinned-join-addresses), and [bootstrap files](security#bootstrap-files) for one-file onboarding.
- [Human-editable configs](configuration/server-config): `server.conf` and `client.conf` replace the old jsons.
- [Swappable waiting music](pack-content#waiting-music): drop an `.ogg` in the pack sources and players hear it during downloads.
- [A sharper editable policy](how-it-works/client-updates#editable-files): 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](how-it-works/loader-behavior): 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](how-it-works/safety-nets): an instance timeline that records every step, offline pack history with restore, detachment, storage repair and cleanup.