FerrFlow

FerrFlow is a CI release tool for maintainers who want commit-driven version bumps, changelogs, and tags across repositories. It is strongest for teams with monorepos or a release workflow they want to keep on their own runner.

Its focused release automation is the draw; teams seeking a build system or package manager should look elsewhere.

Overview

FerrFlow turns conventional commits into version bumps, changelogs, and release tags, and can publish GitHub releases from CI. That makes it a practical fit when release steps should follow commit history rather than depend on a separate manual process. GitHub release publishing is the publishing workflow described, while the tool also supports GitHub, GitLab, and self-hosted forges.

It runs as a single Rust binary without plugins, on a user's machine or CI runner. FerrFlow says it has no account, database, or API endpoint handling user data, and collects, transmits, or stores no user data. Its stated lack of telemetry and phone-home is a meaningful advantage for teams that want release processing to stay in their own environment.

Key features

Four versioning strategies—semver, calver, sequential, and zerover—cover projects whose release policy does not fit one standard scheme. Teams with a simple semver-only workflow may have little need for the extra choices, but the range is useful across repositories with different conventions.

Monorepo support allows independent package versions, shared paths, dependency chains, and per-package changelogs. Those controls matter when packages change and release on different schedules; for a single-package repository, they add flexibility the workflow may 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, rc, and dev channels let teams represent pre-release stages within their workflow.

Installation and CI options include Cargo, npm, Docker, a GitHub Action, and a GitLab CI template. This gives maintainers several ways to bring the binary into a release pipeline without turning FerrFlow into a hosted service.

Its security posture also includes release builds in GitHub Actions with provenance attestations targeting SLSA L3, and signed binaries and container images. Vulnerability reports are accepted by email or GitHub private advisory, with a stated 90-day default coordinated disclosure period.

Pricing

FerrFlow is free and open source: the plan is free and MIT licensed. There is no paid tier or trial to weigh against the free offer. The tradeoff is straightforward: users get the release tool without a subscription, while operating it in their own environment is part of the self-managed approach.

Platforms

FerrFlow supports Linux, macOS, Windows, web, and self-hosted environments. Its single-binary design and CI options suit teams that want to run release automation alongside their existing pipeline; it is not a hosted release service.

Who it's for

FerrFlow is best for maintainers using conventional commits who need repeatable releases, especially teams managing multiple packages or repositories with distinct versioning rules. The monorepo controls, several version strategies, and broad version-file support make it more compelling as release policies grow. A project that needs general build orchestration or package management should choose a tool designed for that job instead.

Pros and cons

Pros

• Independent package versions, dependency chains, and per-package changelogs address release coordination in monorepos.
• Semver, calver, sequential, and zerover accommodate different project versioning policies.
• Local or CI execution without user-data collection, plus signed artifacts and provenance attestations, supports teams prioritizing control over their release environment.
• Free, MIT-licensed software avoids subscription costs.

Cons

• The workflow is based on conventional commits, so it is not a natural fit for teams that do not use that commit format.
• It automates releases rather than serving as a general-purpose build system or package manager.
• GitHub release publishing is the publishing capability described, even though other forge types are supported.

Alternatives

Monorepo Management Tools is a useful starting point for comparing tools in that category.

• Choose npm instead when public package publishing and access to a public registry are the priority; its free plan is for public package authors and supports unlimited public packages.
• Bazel is a free open-source build and test tool from Google, a better direction when build and test orchestration is the need.
• Nx may suit teams seeking CI capacity and contributor-based limits, with its free Hobby plan offering 50,000 monthly-reset credits, five contributors, and 10 concurrent CI connections.
• Yarn is a free open-source package manager with no paid plans or usage limits stated, so consider it for package-management needs.
• affected is a free MIT-licensed standalone CLI, an alternative to consider for a standalone command-line tool.
• bento offers free storage with 10 GB and 14-day retention, making it relevant when stored artifacts and retention are the concern.
• Bit is an open-source option with free personal use through Bit Cloud, for readers considering that platform.
• Blaze is free to use, for readers comparing another no-cost option.

Verdict

Choose FerrFlow if you use conventional commits and want free, self-managed release automation with meaningful monorepo controls. Its main advantage is bringing versioning, changelog generation, and tagging into one CI-oriented tool; look elsewhere if you need a build system, package manager, or release workflow not centered on conventional commits.