Ferium CLI for multi-source Minecraft mod management

Ferium's cross-platform mod update workflow

Ferium addresses a specific problem in Minecraft modpack maintenance: profile files can come from several services, while compatibility depends on both Minecraft and the mod loader. Its supported sources include mods from Modrinth, CurseForge, and GitHub Releases, plus modpacks from Modrinth and CurseForge. The intended audience is a player, server operator, or pack maintainer who wants to automate acquisition and updates rather than visit each source independently.

Ferium organizes this work through profiles. A profile can define a mod loader, Minecraft version, output directory, and a collection of mods. Once that configuration exists, the README identifies `ferium upgrade` as the command for updating every configured mod. Ferium checks whether the selected file version is compatible with the profile's loader and Minecraft version before downloading it. That check is central to its value, but the README does not explain conflict solving, dependency metadata handling, or what happens when several releases satisfy one profile.

Ferium also separates individual mod management from modpack installation. The documented command `ferium modpack upgrade` downloads and installs the latest configured modpack version. The README does not provide syntax for creating a profile, adding a mod, or attaching a modpack, so that part of the setup cannot be reproduced without consulting the executable's help output. A successful upgrade command alone is not a complete first-use tutorial.

Modrinth, CurseForge, and GitHub data flow

The documented flow starts with a profile containing selected mods and a compatibility target. Ferium queries the configured sources, identifies an appropriate version, downloads it, and places the result in the configured output directory. The README says network-intensive tasks use multithreading. It describes concurrent network work, not a persistent background service.

The repository layout shows a client-oriented Rust workspace. The root `src/` directory contains the application, while `libium/` is a separate library component. `Cargo.toml` names `ferinth` and `furse` as wrappers for the official Modrinth and CurseForge APIs. GitHub access comes through `octocrab`, and HTTP requests use `reqwest` with `rustls-tls`. Configuration parsing is based on `serde_json`, while command parsing uses `clap` with environment support. These dependencies expose the external service and command-interface boundaries, although the README does not describe Ferium's cache format or update state machine.

Ferium is therefore presented as a client for locating files through upstream services, not as a replacement for those services. The README does not claim offline dependency resolution, conflict remediation, mirror hosting, or account-based synchronization. It also does not specify retry behavior, rate-limit handling, or what happens when a GitHub release lacks an asset for the required platform. Those omissions limit how confidently Ferium can be treated as a fully deterministic build service.

Installing Ferium on macOS, Windows, and Linux

The README provides package-manager commands for several operating systems. On macOS or Linux with Homebrew installed, this command installs Ferium from its published formula:

brew install ferium

The package manager should place `ferium` with the user's other command-line tools. The README does not document a version-query command, so this tutorial does not add one.

Windows users can install the winget package:

winget install GorillaDevs.Ferium

The README also lists Scoop. Its documented setup first adds the `games` bucket, then installs Ferium:

scoop bucket add games
scoop install ferium

The README does not state which GUI or nogui artifact these desktop package managers select.

For a Rust developer working from the checkout, the `justfile` provides a development installation command:

cargo install --offline --debug --force --path .

This installs from the current checkout into Cargo's binary directory. The offline flag requires dependencies to be available locally. The default features include `gui`, so a local Linux build can have different runtime requirements from a prebuilt executable.

Linux GUI dependencies and nogui selection

Linux packaging has an important split. Prebuilt executables from GitHub Releases require no external runtime dependencies, according to the README. A regular Linux build needs a desktop environment offering an XDG Desktop Portal so Ferium can display its folder picker. A headless server may have neither, making the regular build a poor deployment choice.

`Cargo.toml` makes the distinction explicit. The default feature set is `gui`, which enables `rfd` with `xdg-portal`. Its description says the feature replaces CLI text input with a graphical folder-selection dialog. The README tells users without GNOME, KDE, XFCE, or a comparable environment to use a nogui release.

The README mentions `--no-default-features` when compiling from source, but it does not print a complete `cargo build` or `cargo install` command using that option. The confirmed packaged or prebuilt route is to select a `nogui` artifact from the installation choices.

This distinction affects deployment. A workstation can use the graphical picker to choose profile output directories. A headless server needs the nogui variant so the program does not depend on a portal. The README does not document alternative profile configuration syntax for that headless workflow, leaving the exact server setup incomplete outside the executable's own help.

Running the first compatible Ferium upgrade

A useful update requires an existing profile with the intended source entries. The README does not document the commands for creating that profile or adding a mod, so a complete setup script would require information the project documentation does not show. After a profile has been configured, the first confirmed mod operation is:

ferium upgrade

The README states that this upgrades all configured mods to the latest compatible versions. Compatibility is evaluated against the profile's mod loader and Minecraft version rather than simply selecting the newest release shown by a source. Ferium also has profile and mod listing interfaces, but the README does not show their command syntax.

Modpack users have a separate command:

ferium modpack upgrade

This downloads and installs the latest configured modpack version from the profile. Ferium supports modpacks from Modrinth and CurseForge, while GitHub Releases applies to individual mods. That split means a source supported for one artifact type should not automatically be assumed to support both.

The key profile check is consistency between the intended Minecraft installation and the configured loader. Automation should not infer a stable JSON output contract from the README because it does not document exit-code behavior, prompts, or machine-readable results.

Ferium limits, releases, and license obligations

Ferium is a focused updater, not a documented general-purpose dependency solver. It updates selected files according to a profile's compatibility target. The README does not say that it resolves arbitrary mod dependencies, detects every incompatibility between installed mods, or negotiates a different Minecraft version automatically. A pack requiring coordinated dependency changes may need additional tools or manual review.

Upstream publication remains an external dependency. GitHub maintainers can rename or remove release assets, and service APIs can change or become unavailable. The README does not promise an offline update operation. The source-build command being offline only concerns Cargo dependency installation and does not mean downloaded mods can later be resolved without network access.

The repository is not archived, and its last push was on 2026-05-16. The listed stable releases are older: `v4.7.1` was released on 2024-09-17, `v4.7.0` on 2024-06-11, and `v4.6.0` on 2024-06-10. At the same time, `Cargo.toml` declares version `5.0.0`. The README does not explain whether that version has a release announcement or migration guide, so users moving from 4.x should check the repository's release documentation before upgrading.

Ferium uses `MPL-2.0`. The license identifies required obligations for distribution and modification, including source availability for covered modified files. Anyone redistributing Ferium or derived code should read `LICENSE.txt` and preserve required notices. This is a licensing consideration, not legal advice.

Ferium versus direct ferinth and furse clients

A concrete alternative is to build a narrow automation tool directly on Ferium's sister libraries. The README identifies `ferinth` and `furse` as Rust wrappers for the official Modrinth and CurseForge APIs. Those libraries provide service access, while Ferium adds profiles, Minecraft and loader constraints, output directories, modpack commands, CLI interaction, and file updates.

The difference is the application layer. A program built on `ferinth` or `furse` may have more direct control over API requests, output formats, and deployment logic because it defines those behaviors itself. Ferium supplies a ready-made workflow for players who already want its profile model and compatibility checks. It is the less attractive choice when required automation depends on source-specific API features that the CLI does not expose.

The README does not publish a feature matrix comparing Ferium with the wrappers, so they should not be called complete drop-in replacements. Their documented role is API access. Ferium's documented role is end-user management of mods and modpacks across its supported sources.

Editorial conclusion

Adopt Ferium if you manage Minecraft mods across several services and want a terminal-centered profile workflow. Do not choose it when you need a documented graphical launcher, automatic conflict remediation, or a Linux build without an XDG Desktop Portal unless you select a nogui release. Before installing, verify that your package supplies the required GUI or nogui variant, then confirm that a profile can represent your Minecraft version, mod loader, output directory, and sources.

Frequently asked questions

Official sources

1. gorilla-devs/ferium on GitHub
2. Issues
3. License: MPL-2.0
4. README
5. Releases