Irony Mod Manager: a Paradox mod manager that understands how mods interact

What it replaces and why

Irony Mod Manager is described as a moddable, high-performance mod manager primarily focused on Paradox games, with Stellaris, EU4 and HOI4 given as examples.

The word that carries the argument is aware. The README says it replaces the built-in Paradox launchers with something faster, more reliable, and actually aware of how mods interact with each other. That last clause is the actual differentiator, because speed alone is a modest claim for a launcher replacement.

The problem it addresses is specific to how Paradox games ship their mods. Each mod normally lives in a separate directory, and the game loads them in a defined order. When two mods touch the same data, the one loaded later wins, and the launcher is where you set that order. The official launcher does this, but it is not fast, and its interface for diagnosing which mod is overriding which is limited. A mod manager that models the dependency graph properly is a different tool from a launcher with a settings page.

The supported game list in the topic tags is broad and specific at once: Stellaris, Europa Universalis IV and V, Hearts of Iron IV, Crusader Kings III, Imperator Rome, Victoria and Victoria 3. That is the whole Paradox catalogue, not one game, and the fact that the manager works across all of them is what makes it a manager rather than a launcher for a single title.

The project is written in C#, the licence is MIT, the default branch is master, and the release naming shows the project's own convention: v1.28.102-rc, v1.28.100-rc and v1.28.97-alpha. The suffix is the pre-release channel, and the rapid alpha and rc succession indicates a project that ships test builds to a community willing to run them. The last push was on 2026-10-20, with v1.28.102-rc published the same minute.

The README is also a pointer to the Wiki, which covers installation and basic usage, supported games, load order, conflict resolution and advanced features, and troubleshooting and known issues. The build guide in the README is unusually detailed for a README, which suggests the project expects people to build it rather than only download it.

Downloading, and how package managers get their binaries

The distribution model is straightforward, and it is worth reading because it says something about the project's reach.

The README says to always download the latest version from the releases page, with the latest release link as the single entry point. Official Irony Mod Manager binaries are published on GitHub Releases. Package managers such as winget and AUR source their downloads from there.

So there is one distribution point and the packaging ecosystems are downstream of it. winget and the Arch User Repository are both mentioned by name, which means the project has a presence on two of the three major package manager ecosystems for Windows and Linux respectively. The homepage is at bcssov.github.io/IronyModManager, and the description carries an official Discord link, so there is a community channel alongside the issue tracker.

For a user, the experience is that of installing any desktop application. For a packager, the requirement is that the release assets follow a predictable naming convention, and the fact that two different packagers source from the same place suggests that convention is stable.

The project also ships a command-line entry point in the repository layout, in a cmd/ directory, alongside a publish/ directory for packaging and a Tools/ directory. That combination suggests the same codebase serves both the desktop application and a headless or scripted path, which is a common pattern for a tool that needs to run in an automated setup, though the README does not document the command-line surface.

The tree also holds Credits/ and References/ directories, a Wireframes/ directory, a Directory.Build.props for shared MSBuild properties, a nuget.config, and a version.json for the version stamp. The Wireframes directory in particular suggests the interface was designed deliberately rather than accreted, and the per-plugin key layout described in the build guide implies the codebase has a plugin model.

Building on Windows, and the two things that will stop you

The build guide is one of the more complete ones you will find in a README, and it is all for Windows and Visual Studio 2022.

The prerequisites are Windows, Visual Studio 2022 with the .NET 8 workload, Git, and a command line in either CMD or PowerShell. Then the steps go:

Clone and enter the repository.

git clone https://github.com/bcssov/IronyModManager.git
cd IronyModManager

Build the LocalizationResourceGenerator, which is a batch script rather than a dotnet command.

cmd\build-tools.bat

Then the part that will stop most people, which is the private CWTools NuGet package. Irony uses a newer CWTools build than the public NuGet package, so you create a folder for local NuGet packages, download and unzip the private build CWTools.Irony-Private.0.4.0-alpha8 into it, and optionally add that folder as a package source through Visual Studio's NuGet Package Manager settings.

That is a real barrier for contributors, and it is worth understanding why it exists rather than treating it as friction. The parser at the heart of the manager is built on CWTools, and the project needs a build of it that the public feed does not carry. The README also credits tboby for extending the CWTools API for Irony, with a link to the CWTools repository on GitHub, so the dependency is a fork rather than merely a newer version.

The second barrier is signing. The guide has you create a keys folder, then run sn -k twice to generate key pairs for the main assembly and the plugin assembly, then sn -p twice to produce the public key files, and copy those into the src\IronyModManager.DI directory. The private keys stay with you and the public ones go into the source tree, which is the standard strong-name arrangement for an application that loads plugins.

The rest of the sequence is short. CWTools depends on FSharp.Core v4.7.0, which you install by right-clicking the IronyModManager.Parser project, choosing Manage NuGet Packages and installing FSharp.Core 4.7.0. Then you build once so Visual Studio restores dependencies, rebuild the solution, set IronyModManager as the startup project and press F5. If everything is configured correctly, Irony Mod Manager will launch.

The plugin model and why the assembly split matters

The build guide says more about the architecture than any amount of prose about features would, because the strong-name key ceremony is not arbitrary.

Two keys are generated, one for the main assembly and one for the plugin assembly, and the public keys go into src\IronyModManager.DI. A directory named after the dependency injection container sitting next to the project source is a strong hint about how the application is put together: the plugin system is wired through the same container as the rest of the application, and the plugin assemblies are loaded with their own identity so that a plugin cannot present itself as the host.

That arrangement is what makes a mod manager for games with third-party modding communities practical. If the manager can load code that other people write, then the code that runs inside your installation is code you did not write, and the question of what it is allowed to touch becomes a design question rather than a social one. The separate signing key for plugins is the mechanism that makes the distinction enforceable at the loader.

The rest of the tree is consistent with a large desktop application in C#. There is a solution file, IronyModManager.sln, a src/ directory, a tests setup in Test.runsettings, a Wireframes/ directory for the interface designs, and a publish/ directory for the packaging pipeline. There is also a GlobalSuppressions.cs, which is a standard mechanism for suppressing analyzer warnings in bulk.

The Credits/ directory and the Special Thanks section point at CWTools on GitHub and at the early adopters and testers who gave feedback. The README frames that as thanks for support rather than a formal contributor list, which is typical of a project whose community is its test cohort.

For a reader evaluating the tool, the important structural fact is that the parser builds on CWTools, a private build of which the project depends on and helps extend. That puts much of the parsing work in the CWTools dependency, and it also means the manager's parsing behaviour is only as current as the private CWTools build the maintainers publish, and there is no public package to point at.

Where Irony Mod Manager is the wrong choice

There are three limits, and the first is the one the topic tags make obvious.

The first is that it is a Paradox-only tool. Every game in the topic list is a Paradox title, and the supported games are documented on the Wiki. If your library contains a game from another publisher, this manager has nothing to offer, and the launcher that ships with the game remains the right tool.

The second is that the fast path only applies to Paradox mod conventions. The awareness of how mods interact with each other is awareness of a specific model: separate mod directories, an explicit load order, and later-loaded files overriding earlier ones. A manager built around that model does not transfer to a game with a different mod architecture, which is the same limitation every launcher-replacement project in this space has, and it means the effort spent on conflict resolution would have to be redone rather than reused.

The third is the build story, and it is worth being blunt about it: contributing to this project today is harder than contributing to a typical .NET project. A private NuGet package has to be downloaded from a release attachment, unpacked into a local package folder, and registered as a source. A fork of a dependency has to be fetched rather than resolved. Two strong name keys have to be generated and the public halves placed in a specific directory. A specific FSharp.Core version has to be installed into one project by hand through the Visual Studio UI. And the build tools step is a batch file rather than a documented dotnet invocation.

Every one of those steps is documented, and a determined contributor will get through them in an afternoon. But it is a real tax, and it means the pool of people who can change the parser behaviour is much smaller than the pool of people who can use the manager. That is the structural weakness of the design: the private dependency is what keeps the manager ahead of the official launcher, and it is also what keeps the contributor list short.

The honest alternative is the official Paradox launcher or the third-party launchers that already exist for these games. Those have the advantage of being either already installed or available without a key ceremony, and they will always understand the mod formats because the publisher maintains them. What Irony Mod Manager offers in exchange is speed and a clearer model of conflicts, and for someone with several hundred mods installed that exchange is often worth making.

For the developer rather than the player, the alternative is to work on CWTools directly. The interesting problems in a mod manager, parsing the mod scripts, resolving overrides, keeping up with new game versions, are mostly CWTools problems, and a contributor who wanted to work on the parser rather than the manager would find a smaller and more tractable surface.

Editorial conclusion

Adopt Irony Mod Manager if you play Paradox games with several mods installed and the official launcher is slow or does not explain the conflicts, since this tool is built to be aware of how mods interact with each other. Do not adopt it for a game outside the Paradox list, because the supported games are documented on the project Wiki. Before you build from source, note the private CWTools NuGet package and the strong name key step, both of which are required, and see the last push was on 2026-10-20 with v1.28.102-rc the same day.

Frequently asked questions

Official sources

1. bcssov/IronyModManager on GitHub
2. License: MIT
3. Project website
4. README
5. Releases