Arma Reforger Dependency Blockers
Load a live server, your Mod Manager list, or a config.json, pick the mods you want to remove, and see exactly what requires them: direct blockers, the chains behind them, and the mods that become removable along with them. Remove several at once to see what a whole cleanup would break.
Every mod the server actually loads. Dependencies are only meaningful against the full list, so import the whole thing rather than a few mods.
Step 2 — mods to remove
Pick one mod, or several. Removing a set together is not the same question as removing each on its own: a mod that only breaks because another mod in the set requires it is not a blocker when both go.
See it visually An interactive graph of what requires what. Mods that require your selection sit above it; the mods it requires sit below. Expand
Only Workshop mod IDs are sent to the API. Passwords, admin IDs, and other config fields never leave your browser.
How the analysis works
Dependency metadata for every mod in the pack is assembled into a directed graph, where an edge from Mod A to Mod B means "A requires B". To test whether a mod can be removed, the graph is walked backwards: every mod that can reach it through requires-edges is a blocker. Mods one step away are direct blockers, anything further back is transitive, and the shortest path from each blocker is shown as the explanation.
What the verdict means
Safe means no installed mod declares your target as a dependency. Blocked means at least one does, directly or transitively. Unknown means no blocker was found but some mods had no dependency data, so the scan is incomplete. A safe verdict covers Workshop metadata only: mission scripts, server configs, and undeclared dependencies can still rely on the mod.
Removing several at once
Selecting several mods asks one question, not several. A mod inside the removal set is never counted as a blocker for another mod in the set, because both are going away together, so a framework and everything built on it can be cleared in one step. Blockers are only the mods you are keeping.
The graph and the API
The graph stays collapsed until you open it: the blocker and orphan lists answer the question in text, and remain the accessible version. Opened, it puts your selection in the middle row, what requires them above, and what they require below. The same analysis is available as POST /v2/tools/dependency-analysis.
Frequently asked questions
Can this prove a mod is safe to remove?
No. It proves only that declared Workshop dependency data did or did not lead back to the mod you selected. Runtime dependencies and mission-specific assumptions are invisible to Workshop metadata, and mods whose dependency data could not be fetched are reported rather than assumed safe.
What is a transitive blocker?
If mod C requires mod B, and mod B requires mod A, then removing A breaks B directly and C indirectly. C is a transitive blocker. The tool walks the whole dependency graph and shows the chain that explains each one.
What does 'also becomes removable' mean?
Some mods are installed only because the mod you are removing needed them. Once it is gone, nothing else in the pack requires them, so they can be deleted too. The tool lists them and adds their bytes to the space you would reclaim.
How does it handle very large modpacks?
The summary counts always cover the whole modpack. The graph itself opens with the rows nearest the selected mod and collapses the rest behind expandable badges, with a text version below it for screen readers and small screens.