FerrFlow

FerrFlow is an open-source command-line release manager for conventional-commit workflows. It is best for maintainers coordinating versions across repositories or monorepos in CI, especially when they want processing to stay on their own machines. Its broad versioning and forge support are useful, but teams seeking a general build or package-management system should choose something else.

Overview

FerrFlow turns conventional commits into release actions: it can calculate version bumps, write changelogs, create tags, and publish GitHub releases from CI. That makes release work repeatable instead of a sequence of manual commands, with GitHub publishing explicitly covered while forge support also extends to GitLab and self-hosted installations.

The tool runs as a single Rust binary with no plugins. FerrFlow says execution stays on a developer machine or CI runner, with no account, database, or API endpoint handling user data. Its security position is unusually clear for a release utility: it says there is no telemetry, error reporting, analytics, data transmission, storage, or phone-home behavior. Releases are built in GitHub Actions with provenance attestations targeting SLSA L3, and binaries and container images are signed. Vulnerability reports are accepted by email or private GitHub advisory, with a stated 90-day default coordinated-disclosure period.

Key features

Four versioning strategies—semver, calver, sequential, and zerover—cover conventional software releases as well as calendar- or sequence-driven policies. A small project with one established scheme may find this choice unnecessary, but teams with differing package policies gain room to standardize on one tool.

Monorepo support is more than a shared version number. Packages can be versioned independently, while shared paths, dependency chains, and per-package changelogs help represent relationships between components. This is a strong fit when packages release on different schedules; it also brings configuration overhead that a single-package repository does not need.

FerrFlow supports more than 14 version-file formats, including Cargo.toml, package.json, pyproject.toml, and Chart.yaml. Branch-based or flag-based alpha, beta, release-candidate, and development channels let CI distinguish pre-release stages without changing tools. Installation and pipeline integration are offered through Cargo, npm, Docker, a GitHub Action, and a GitLab CI template. A task graph and package-manager integrations for Cargo and npm further suit dependency-aware release jobs.

Pricing

Free and open source — free. The MIT-licensed plan is the complete FerrFlow offering described here, delivered as a single Rust binary. There is no paid tier, seat charge, quota, or trial period to weigh, so individual maintainers and organizations can adopt the same release workflow without a subscription renewal. The trade-off is that teams must operate the command and CI integration themselves rather than buying a hosted release service.

Platforms

FerrFlow supports Linux, macOS, Windows, web, and self-hosted use. Its CI-oriented distribution through Docker, GitHub Actions, and GitLab CI makes it practical for hosted runners, while the local binary covers workstation-based release preparation.

Who it's for

Choose FerrFlow for repositories already using conventional commits, teams with monorepos or multiple repositories, and organizations that require release processing to remain on their own infrastructure. It is particularly well matched to projects needing independent package versions, dependency-aware task ordering, or several pre-release channels.

Look elsewhere if you need a general build system, a package manager as the primary product, or a hosted service that removes CI and operational responsibility. FerrFlow's breadth is aimed at release automation rather than broader software delivery.

Pros and cons

Pros

• Open-source and free: the MIT license and 0.00 USD plan remove subscription and seat-cost barriers.
• Strong monorepo controls: independent versions, dependency chains, shared paths, and per-package changelogs handle uneven release schedules.
• Broad compatibility: four versioning models, 14-plus file formats, three forge families, and multiple CI installation routes reduce migration friction.
• Privacy-focused operation: local or runner execution with no telemetry or user-data handling keeps release inputs in the team's environment.
• Supply-chain measures: signed artifacts and provenance attestations provide signals for security-conscious CI operators.

Cons

• Self-managed workflow: the free binary leaves setup, CI maintenance, and policy configuration to the team.
• Potentially excessive configuration: multiple strategies and monorepo rules are valuable for complex projects but unnecessary for a simple single-version repository.
• Publishing emphasis is GitHub: forge support is broad, while release publishing is specifically described for GitHub.

Alternatives

Bazel is the better choice when the primary need is Google's free, open-source build and test tool across Linux, macOS, and Windows, rather than release-version automation.

bento suits teams seeking a self-hosted storage-oriented service with a free 10 GB plan and 14-day retention, not FerrFlow's commit-driven release workflow.

Bit is a better fit for component collaboration and Bit Cloud personal use across web, mobile, API, and self-hosted environments.

Blaze is another free option for teams whose requirements are met by its cross-platform offering rather than FerrFlow's release-specific controls.

Bun is the alternative when an open-source, MIT-licensed JavaScript runtime and toolkit is the priority.

EvoMaster fits teams looking for an open-source API testing tool with no paid external services.

manypkg is preferable for a focused, MIT-licensed package-management CLI.

mise is the better match for managing development tools on macOS, Linux, and Windows with an MIT-licensed open-source utility.

For a wider comparison of repository tooling, see Monorepo Management Tools.

Verdict

FerrFlow is a strong choice for maintainers who want free, self-hosted release automation across monorepos or multiple repositories, with flexible version rules and CI integration in one binary. Choose it for privacy-conscious, conventional-commit workflows; look elsewhere if you need a hosted service, a build system, or a package manager rather than a release manager.