Play
Installing, removing, and updating mods
Review dependency-aware plans and make content changes with recovery protection.
Two versions of this page follow. Step by step walks through the task in order. In depth explains the underlying behavior. They describe the same product, at different levels of detail.
Step by step
Follow the steps in order. No prior modding knowledge assumed.
Agora plans content changes before touching the instance. The review screen explains added dependencies, conflicts, file changes, and the snapshot that protects the operation.
After this you will be able to
- Install a project into the correct instance.
- Review dependencies and resolve conflicts.
- Update or remove content without bypassing recovery.
Install from a detail page
Select Install to Instance, choose the target, select a compatible project version, and review the plan. Packs use Create Instance from Pack because they define a complete starting instance: its form asks for a name and release, and Check pack previews the mods and versions before anything is created. Modrinth packs ask for a pack version and then open the normal install review.
- Confirm the target instance, Minecraft version, and loader.
- Choose an exact-compatible file when available.
- Review required and optional dependencies.
- Resolve every conflict shown in the plan.
- Check the snapshot and file summary, then apply the operation.
Remove safely
Use Remove from the Mods tab instead of deleting the file manually. Agora can identify dependents, stage the removal, create a recovery snapshot, and run health checks afterward.
Check for updates
On My Instances, select Edit on the instance, open its Mods tab (Resource Packs, Shaders and Data Packs have the same control), and select Check for updates. Update an item from its row, or use Update All to review one plan for every update in that tab. Locked instances cannot be updated until you unlock them.
- Locked instances are skipped.
- A newer version is not automatically compatible with every other mod.
- The result screen reports success, cancellation, failure, or automatic health rollback.
Results are remembered, and badges count them
Once checked, results are stored, so they survive navigating away and restarting Agora. Waiting updates show up in the instance editor, and Agora re-checks quietly in the background on an interval you can change in Settings.
See what changed, and pin what should not
Where the author publishes one, the changelog for a version is shown before the update applies, so you can decide with the release notes in front of you. If a mod is at a version you want to keep, pin it from the three-dot menu at the end of its row: Pin updates. Pinned mods are skipped by Update All, stop counting toward the instance badge, and can still be updated deliberately whenever you choose. The same menu item unpins.
In depth
How the system actually behaves, and why, for readers who prefer the model to a recipe.
The Install Flow is a transaction planner. Use its dependency graph, conflict choices, snapshot boundary, hash checks, and post-apply health result to reason about complex changes.
After this you will be able to
- Evaluate and revise a resolved install plan.
- Use batch operations without losing atomic recovery.
- Know what cancellation and health rollback guarantee.
Inspect the resolved plan
The plan is computed from the intent, selected artifact, dependencies, optional choices, conflicts, current files, and instance state. Changing an optional dependency or conflict resolution causes the plan to be resolved again before execution.
- Blockers must be fixed before execution.
- Warnings deserve review but may be acceptable for a controlled test.
- File changes show the operation's actual scope, not only the top-level project.
Understand the transaction boundary
Agora creates a recovery snapshot, downloads and verifies artifacts, applies the planned changes, then runs health validation. If the final state has health blockers, Agora restores the recovery snapshot automatically.
Batch changes strategically
Group updates that belong to one compatibility family, such as a library and its dependents. Avoid updating every subsystem at once on a large instance. Smaller batches produce clearer diffs and make crash investigation more decisive.
- Snapshot the known-good baseline.
- Select one coherent update group.
- Review changed artifacts and hashes.
- Apply, launch, and test.
- Continue only after the instance is stable.
This guide is the same text Agora shows in its built-in Help & Guide, which is searchable and links directly to the screens it describes.