Installation Learn more about Balm Mod.

How to Install Balm on NeoForge

Install Balm on NeoForge by choosing a published NeoForge JAR that matches your Minecraft version and the requirements of the mod that depends on it. Copy that file into the correct instance's mods folder while the game is closed, then verify startup and the intended mod feature. The important work is confirming compatibility and preserving a known working setup. This guide covers both personal instances and the additional checks you should make when the same change will later be deployed to a server.

Establish the NeoForge environment first

Open the selected launcher's profile settings and record the Minecraft and NeoForge versions. If you have recently migrated from another loader, check the actual configuration rather than trusting an old profile name. A copied instance can still contain files intended for its previous environment. Before adding another dependency, identify what launches and which mod directory it reads. These facts determine whether any candidate Balm release is relevant to your current installation.

Review the dependent mod's NeoForge release

Find the individual release of the mod you want to use and read its supported loader, game versions, and required libraries. A project may offer multiple builds, but support for one loader on one game version does not establish support for every combination. Choose the gameplay mod and dependency as a compatible pair. If the desired combination is unavailable, pause rather than trying to complete the setup with a file chosen only because its name looks similar.

Record version constraints before changing files

Write down the Balm requirement associated with the dependent release. If other installed mods also use Balm, compare their requirements at the same time. Your target is a single release that fits the active environment and the full set of relevant constraints. The Balm version selection guide explains this comparison in more detail. Complete it before downloading so the release choice has a clear reason beyond being the first result you found.

Locate the active instance folder

Use the launcher's open-folder control or inspect its configured game directory. Check that the contents correspond to the instance you intend to modify. If you operate both a local client and a server, keep those destinations distinct. They may use related mod sets while living in different directories and starting through different commands. Write the intended destination in your notes, especially when more than one copy of the pack exists on the same machine.

Inspect for files left from another loader

A migrated folder may contain a Forge or Fabric build that belongs to an earlier configuration. Do not assume that a familiar project name makes that file suitable for NeoForge. Compare each relevant release against its published metadata. Move unsuitable files into a separate backup rather than leaving them in mods while adding new candidates. The active directory should describe one intended environment, not the history of every environment you have tried.

Distinguish an instance from a pack download

A downloaded pack archive may need installation through a supported launcher workflow rather than direct manual copying. Likewise, the browser's download directory is not normally the authoritative list of active mods. Verify the installed instance, including any dependencies already resolved by its manager. Avoid overwriting a managed configuration without understanding how its updates work. If you want to experiment, duplicate the installed instance and keep the distributed configuration available as a reference.

Protect the current setup before installation

Close the game and stop any server whose files you plan to replace. Make a backup appropriate to the setup, including important worlds and configuration. A copied list of mod names is helpful but does not preserve your save data. Check that the backup can be located and that it represents a completed, stopped state. A recovery plan should be practical enough to use after a failed launch, not just an assumption that an older file can be found later.

Separate the backup from the live mods folder

Keep old releases outside the directory that the loader scans for active mods. Renaming a file vaguely as a backup can make future inspection confusing, especially if its extension still makes it look active. A clearly named recovery folder elsewhere in the instance's parent directory is easier to understand. Record which files were moved and why. This preserves your rollback option while leaving the intended live dependency set unambiguous.

Plan changes that need to happen together

Sometimes the dependent mod update requires a library change, and sometimes it requires a different loader release as well. Treat documented requirements as one planned set. Do not partly apply an update and then conclude that the library is faulty because the remaining components still belong to the old configuration. Conversely, do not upgrade unrelated settings during a straightforward library installation. The scope should follow the requirements, with every changed component accounted for.

Download the matching NeoForge Balm JAR

Use the published Balm release listing and filter for NeoForge and your exact Minecraft version. Open the selected release's details and compare them with your compatibility notes. If a file supports a range of versions, rely on that documented range rather than an assumption based on the download name. Check whether the release satisfies the dependent mod's library requirement. If it does not, choose a compatible set before proceeding to the installation step.

Verify the deliverable after downloading

Inspect the file you received. Confirm its original name, completed download status, and expected JAR extension. For normal player installation, do not use a repository source archive in place of the published mod. Keep source downloads separate from playable releases if you use both for different purposes. A file's presence on disk is only the start of verification; its role, supported environment, and dependency version must also be appropriate.

Avoid assumed compatibility with another loader

Forge and NeoForge labels must be taken seriously in the release information. Do not substitute a build without an explicit statement that the selected file supports your environment. If no suitable NeoForge build is available for the target combination, reconsider the game or dependent mod release. Renaming a file or moving it into a new directory does not change the environment it was built to support. A deliberate compatibility decision is more dependable than trial based on similar names.

Place the file and check the final folder

Copy the selected Balm JAR into the active instance's mods folder. Keep the dependent mod and other documented requirements in place. If the correct Balm release was already installed, there may be nothing to copy. If you replace it, remove the superseded active version after preserving it separately. Inspect the folder one final time for duplicates and wrong-loader leftovers. This small review catches avoidable problems before you spend time interpreting a new startup error.

Preserve original release names

File names are useful evidence when you compare an installation with a release listing or ask for help. Avoid changing them into names such as newest or fixed. Those names can conceal the version information another person needs to diagnose the setup. If you want a human-friendly explanation, put it in a separate installation note. The live folder can retain accurate release names while your notes describe why each component belongs in the instance.

Check permission and synchronisation problems separately

If the file cannot be copied, or disappears after a launcher refresh, determine whether a manager, synchronisation service, or directory permission controls that location. Repeated downloads do not solve a destination problem. Use the supported instance-management process and verify the final folder after the manager finishes. Keep the installation task focused: a correct source file must reach the actual live destination and remain part of the selected profile's intended configuration.

Test startup and the dependent feature

Launch the NeoForge profile you prepared. First verify that no missing or unsupported dependency message blocks startup. Then confirm the desired mod is recognised and test its documented behaviour in a disposable world. Save any error report before changing another component. A successful menu launch is a useful checkpoint, but the dependent feature test establishes whether the practical goal of the installation has been achieved in this particular configuration.

Make the test repeatable

Write down the steps used to test the feature, including configuration changes or conditions required to trigger it. Restart once and repeat the important interaction. This prevents a one-time observation from becoming an overly broad claim about compatibility. If the feature fails only after loading a world or joining a server, preserve that context. The phase at which a failure occurs can be as useful as the name of a component mentioned later in the log.

Extend the check for a server deployment

A local client test does not establish that a dedicated server starts or that players can connect. Follow the dependent mod's documented side requirements and prepare a separate server test where appropriate. Record both file sets and check a connection using the intended client configuration. Our client and server Balm checklist covers those additional decisions. Avoid a blanket assumption that every mod belongs on both sides in every deployment.

Recover from a failed installation

Read the first concrete compatibility message and compare it with the environment record. Check the directory, selected loader, game version, dependency range, and duplicate files before adding anything else. If the issue remains unclear, restore the known working set and continue investigation in a copy. A useful rollback returns the dependent mod and its matching libraries together. Reverting only one file can create a new mismatch that was not present in the original setup.

Example of a controlled replacement

Imagine updating a NeoForge convenience mod that now asks for a newer Balm release. In a copied instance, you replace the mod and the library as a planned pair, preserve the old pair outside mods, and test startup. If the loader identifies another unmet requirement, you save that message and compare it with the update notes. If the feature works, you record the tested versions. The original pair remains available throughout, so testing never depends on reconstructing your old setup from memory.

Common NeoForge installation questions

Can the same Minecraft version guarantee compatibility?

No. It is one relevant check, not a complete decision. The loader and dependent release requirements also matter. Treat a candidate as suitable only after the necessary constraints agree. If you are unsure which loader your profile uses, establish that first. A download chosen from incomplete environment information is difficult to validate and may send troubleshooting in the wrong direction before the actual setup has been identified.

Is there a separate item that proves Balm is working?

Do not rely on an inventory item to verify a supporting library. Startup recognition and the dependent mod's documented behaviour are better checkpoints. Record exactly what you tested instead of saying the entire instance is guaranteed compatible. For broad background on the ecosystem and terminology, see Wikipedia's Minecraft modding overview. For practical file selection, continue to use the specific release requirements associated with your NeoForge installation.

What should remain after a successful setup?

Keep a concise record of the Minecraft version, NeoForge version, Balm release, dependent mod release, and test result. Retain the backup until you are confident the expected gameplay is stable. These notes make future updates easier to assess and make support requests more precise. The installation is complete when the intended compatible set is active, the required feature is verified, and the recovery information remains available without cluttering the live mods directory.

Make the NeoForge result reproducible

Record the exact installation sequence after a successful test, including the profile you selected and the releases installed together. Note whether a manager performed any part of the process, because another person may otherwise repeat a manual step that the manager already completed. Keep the feature test specific enough to reproduce. Saying that a particular interface opened or a documented interaction succeeded provides a useful observation; saying that every mod is compatible makes a much broader claim than the test supports. A precise result remains valuable even when the rest of the pack has not been exhaustively exercised.

If you later prepare a second NeoForge instance, do not blindly copy the first instance's Balm file. Compare the new environment and dependent requirements again. Similar profiles can use different game versions or different releases of the same feature mod. Use the original note as a model for the checks, not as universal download advice. Keep each setup's active files and recovery files separate so that changes to one do not silently alter another. This approach preserves both convenience and clarity: you can reuse a dependable process while still making the release decision appropriate to the environment that will actually run it.