01How the manager updates itself
r2modman downloads any available update while it runs and installs that update when you close the application, so the build on disk changes between sessions rather than during one. Updates are checked at app startup. Linux users on the Flatpak remote introduced in 3.2.19 update through Flatpak instead, using the remote that the included flatpak-setup.sh script configures, which keeps manager updates alongside the rest of the system. If the window has been open since an update was fetched, the running process is still the older build until you close it fully and reopen.
02Confirm what you are running now
Before changing anything, record the versions in play. The current release is v3.2.19, published 2026-08-21, and the project has 117 public releases behind it. Note the manager version, the game build, the loader version and the profile you are testing. That single note turns a vague problem that appeared after an update into a comparison between two known states, and comparing it with the release notes is far faster than guessing which change is responsible. Every public release keeps its original assets, so an older installer is still available when you need to step back.
03Take a recovery point first
Open Settings → Profile → Export profile and take both As a code and As a file before any update, and copy configuration or save files that an export does not cover. Keep the installer for the version you are leaving if a recent build misbehaves. The shared download cache makes reinstalls quick, but it holds package archives rather than your profile state, and it is not a backup. Keep the export where you can reach it without opening the manager, because a broken installation is exactly when the manager is least usable.
04Update one layer at a time
The manager, the game, the loader, shared dependency packages and feature mods are independent layers. Update the manager, reopen it and confirm it starts. Then update the loader in a separate test profile and launch once. Add shared dependencies in a small batch and launch again. Update feature mods last. That order shows which layer moved when something breaks; changing all five together leaves nothing to compare against. If a launch fails straight after the manager step, you already know the problem is not a mod. Keep the test profile around until the whole set has survived a session.
05Update packages from the Installed tab
Inside a profile, the Installed tab is where package updates happen. Outdated packages are flagged and each can be updated individually, so a mod that has started misbehaving can stay on its working version while the rest move forward. Update in small batches and launch between them. Record the version numbers before and after; if a shared dependency moved as part of a batch, everyone in a multiplayer session needs the same version, so agree with the group first. The manager also reports when a package you have installed is removed from Thunderstore, which is a different message from an update being available.
06Roll back the smallest change
If an update breaks something, undo the smallest change that could have caused it. Return to the Stable profile, or reinstall the previous version of the package from the version selector in the Online tab, since older releases are downloaded into the cache as well and stepping back is usually quick. Avoid running a manager update, a stack of package updates and a game patch in the same sitting when you are diagnosing a failure. One change, one launch, one observation, and a note of what you reverted. Rolling back is a normal part of updating rather than a failure.
07Sometimes waiting is the better update
Not every release is worth taking on day one. After a major game release, community loaders and the mods that depend on them need time to match the new build, and a profile that still runs is worth more than one that is current. If the game works and nothing in the notes addresses a problem you have, waiting for the loader and your key packages costs you nothing. Loader and package pages usually state which game build they target, which is the fastest way to tell whether the wait is over.
✦ Frequently asked questions
Common questions, answered directly.
Does r2modman update itself automatically?
Yes. It downloads available updates while it runs and installs them once you close the application, and it checks for updates when it starts. If you leave the window open for days, the new build is on disk but the running process is not using it until you close and reopen.
Will updating r2modman delete my profiles?
A normal application update leaves profile data in place, because profiles live in the r2modmanPlus-local data folder rather than inside the application. Export the profiles you care about anyway; that takes one click and covers a failed update, a reinstall or a move to another machine.
How do I update r2modman on Linux or Steam Deck?
Flatpak users update through the Flatpak remote introduced in 3.2.19, which the included flatpak-setup.sh script configures. AppImage users replace the file with the new AppImage and restore executable permission. Native deb, rpm and pacman packages update through the system package manager.
Should I update every mod at once?
No. Batches of a few packages keep the cause of a new problem visible, and the Installed tab updates packages individually. Bulk updates are reasonable once a set has proved stable on your machine, not while you are still finding out what changed.
Can I go back to an older r2modman version?
Yes. The project has 117 public releases and each keeps its original assets, so the installer for a previous version remains available. Keep the installer for the version you are leaving until the new one has survived a few sessions.
Each step on this page ends in a result you can see before the next one starts, so a failure points at one layer instead of the whole stack.
Next: download or update the current build, keep one profile with only the loader enabled, confirm a modded launch from Start modded, then add the rest of your mods in small batches.