Amethyst Mod Manager: a Linux-native launcher-side mod manager

An MO2-style layout on Linux, without the Wine manager

Amethyst Mod Manager describes itself as a mod manager for Linux, and its interface is deliberately a copy of Mod Organizer 2, described in one line as a MO2 style interface with the motto that if it is not broke, do not fix it. That is a strong design signal. MO2's model, where mods live in their own directories and a virtual file system assembles the view of the game folder, is what a mod manager should do, and porting that model to a native Linux application means the deployment layer is not a Windows program emulated through Wine. The primary language is Python, the licence is GPL-3.0, the project is not archived, and the last push was on 2026-10-15 with releases v2.5.5-beta.3 on 2026-10-15, v2.5.4 on 2026-10-10 and v2.5.3 on 2026-10-03, so the beta line is where the active work is. The repository layout is a hybrid of Python and native code, with `src/`, a `native/` directory, `meson.build`, `flatpak/`, `nix/` and a `flake.nix`.

Three deployment methods, and what restoring actually does

The deployment layer is the part with real consequences for your game folder, and the manager offers three methods: deploy as symlinks, deploy as hardlinks, or deploy as a VFS. Restoring reverts the game folder back to its previous state. That is the property that makes a virtual-file-system approach attractive on Linux, where symlink support in the game's directory is usually not a problem but is not universal, and where a game's own updater can clobber a folder you have written files into. Hardlinks avoid symlink issues and share the mod file's data rather than copying it, while symlinks are cheap but depend on the game resolving them. The choice is per installation rather than global, and it is the first thing to think about if you have a game that patches its own files.

Nexus collections, Wabbajack lists and the in-app browsers

The download and dependency handling is where a mod manager earns its keep, and here the manager leans on two external sources plus a built-in browser. Nexus collections are installed directly, with the manager handling fast mod installs, collection load orders, applying fomod options and mod diff patches automatically. The manager can also create, edit and upload Nexus collections, which makes it a two-way tool rather than a downloader. Wabbajack mod lists can be browsed and installed, and the list is managed in the manager. There is an in-app Nexus Browser so you can view and install mods straight from the manager, and an in-app Thunderstore Browser for games Thunderstore supports, which is the route for the mod.io and Thunderstore ecosystems that many Linux games use. Loot support comes from libloot being built into the application and optimised for fast plugin sorting, which is the standard way to order a load order with conflicts.

Game detection across Steam, Heroic, Lutris and Faugus

Mod managers have to find the game before they can do anything, and this one detects installations from four launchers: Steam, Heroic, Lutris and Faugus. On a Linux desktop that is the difference between a manager that works and one that asks you to paste a path, and it is the detail that matters most for a Steam Deck or SteamOS setup, where the game library is managed by Steam and the working directory conventions are particular. The supported list is broad, with almost 100 games added or supported according to the documentation, and the named categories are all Bethesda titles, Cyberpunk 2077, Baldurs Gate 3, Stardew Valley, RE Engine titles, BepInEx games and a lot of Unreal Engine 5 titles. The design goal is stated as making adding game support easy, which is why the wiki holds the authoritative list and the application can be extended without waiting for a new release.

Root folder building and automated tool setup

Two features exist because many mods ship files that belong in the game root rather than in a mod folder. Root folder building handles the common cases automatically, with no setup needed, and anything else can be toggled to go to root with a couple of clicks. That toggle matters, because the reason a file needs to be in the root is usually that the game reads it by path, and once the manager knows which files those are it can deploy them correctly without you symlinking each one by hand. The second feature is automated tool setup, which runs tools such as Pandora, pgpatcher and dyndolod with a few clicks. These are the post-install patchers that many mod lists expect to have run, and automating them removes a whole class of 'the mod installed but the game does not see it' problems. The repository also carries a `Changelog.txt` and a `meson.build` alongside the Python sources, and the wiki is built into the manager and can be viewed there as well as on the web.

Three install routes and the keyring question

Installation is offered three ways. The AppImage route pipes a script straight into bash:

curl -sSL https://raw.githubusercontent.com/ChrisDKN/Amethyst-Mod-Manager/main/src/appimage/Amethyst-MM-installer.sh | bash

The application then appears in your applications menu under Games and Utilities, notifies you when a new update goes live, and reruns the same script when you press the update button. The Flatpak route installs from a flatpakref:

flatpak install --user https://chrisdkn.github.io/Amethyst-Mod-Manager/amethyst.flatpakref

Or you can add the remote yourself and pick a branch, where the repo carries a `stable` and a `beta` branch:

flatpak remote-add --user --if-not-exists modmanager-origin https://chrisdkn.github.io/Amethyst-Mod-Manager/amethyst.flatpakrepo
flatpak install --user modmanager-origin io.github.Amethyst.ModManager//stable

Swapping to the beta branch means reinstalling with the beta channel name, and `--user` can be swapped for `--system`. The third route is the AUR, with a package page linked from the README. One thing to expect on first run is a password prompt, which is for the OS keyring that stores your Nexus API key rather than a plain text file, and the documentation says to set the password to anything you want.

The Flatpak 32-bit compatibility gap

There is a specific trap in the Flatpak route that will bite anyone running Windows tools under Proton or wine. Installing from a bundle skips the 32-bit compat extensions that running those tools requires, and the app installs them automatically on first launch or you can add them yourself:

flatpak install --user flathub org.freedesktop.Platform.Compat.i386//24.08 org.freedesktop.Platform.GL32.default//24.08

So the failure mode is a working manager that cannot launch the mod tools or the game. It is worth doing this install before you start adding mods rather than after you have a load order to debug. Beyond that, the Flatpak has the usual sandbox consequences, and the AppImage has the usual consequence of being outside the distribution's package manager, though the AppImage notifies you when an update goes live, while the Flatpak updates through your package manager.

Editorial conclusion

Adopt Amethyst Mod Manager if you mod Linux games and want a native application with MO2-style profiles, in-app Nexus and Thunderstore browsing and a choice of symlink, hardlink or VFS deployment. Skip it if you need a 32-bit Proton or Wine tool to run alongside the game and cannot install the compatibility extensions, since the Flatpak route skips them on install and you must add them by hand. Before committing, check that the game and mod sources you use are in the supported list, run the Flatpak install of the i386 and GL32 compat extensions if you installed from a bundle, and expect the Nexus API key to be stored in the OS keyring, which means the application may ask you to set a keyring password on first run.

Frequently asked questions

Official sources

1. ChrisDKN/Amethyst-Mod-Manager on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases