Thanks for the thoughtful write-up, Pierre. I support your proposal. While the need for version controlled flows still exists, a lot has changed since the introduction of NiFi Registry, and I believe the needs of most of the community are better met by the git-based registry client rather than the NiFi Registry Server implementation. As one of the original authors of the initial NiFi Registry implementation, I think if we were doing it over today we would consider a git repository client based approach for the design rather than a complimentary web service. I look forward to future improvements to version controlled flow definitions, such as the NIP-13 proposal for branch support [1], and I think deprecating the existing NiFi Registry Server implementation makes those plans more achievable.
[1] https://issues.apache.org/jira/browse/NIP-13 Cheers, Kevin On Mon, Jan 12, 2026 at 12:50 PM Pierre Villard <[email protected]> wrote: > > Hello NiFi community, > > I'd like to start a discussion about the future of NiFi Registry and > propose that we deprecate this component. > > **Current State** > NiFi Registry has accumulated a significant number of security > vulnerabilities (CVEs) related to its Angular-based frontend, with the > count now reaching double digits. Unfortunately, these CVEs cannot be > resolved through simple dependency updates. The only viable path to > address the security issues requires completing a full rewrite of the > Registry UI to use modern Angular, an effort that was started but > remains incomplete as of today. > > **Maintenance Challenges** > Over the past several years, NiFi Registry has received minimal > maintenance attention. The UI modernization effort has stalled, and > there is currently no clear path to completion without significant > volunteer contributions. While an initial PR was submitted and merged, > the remaining work—including user/group management pages, > comprehensive testing, etc—still needs to be addressed. As a PMC, we > have an obligation to respond to CVEs in software we release. > Continuing to ship NiFi Registry with known, unresolved security > vulnerabilities is not sustainable. > > **Alternatives Available** > NiFi 2.x introduced direct integration options with Git-based registry > clients that provide an alternative path for flow versioning: > - Git-based registry clients offer native integration with existing > version control infrastructure > - These clients are actively maintained and do not carry the same security > debt > > The main feature gap is the permission model in NiFi Registry that > allows users to access specific flows based on permissions (useful for > multi-tenant deployments). With Git-based clients, access control is > typically all-or-nothing at the repository level. However, the > advantages of Git-based registry clients largely compensate for this > limitation for most use cases. > > **Maintenance Requirements** > If you or your organization depends on NiFi Registry and would like to > see it continue as part of the project, now is the time to step > forward and contribute to its maintenance. The work required includes: > - Completing the Angular UI rewrite > - Complete testing following the full rewrite > - Backend changes to have feature parity in terms of OIDC/SAML support > for authentication, remove support for Kerberos, etc > > **Proposal** > I propose that we: > - Immediately deprecate NiFi Registry - Mark it as deprecated in the > documentation and codebase, clearly communicating to users that they > should migrate to alternative solutions. > - Set a removal timeline - Plan to remove NiFi Registry from the > codebase as part of NiFi 3.0, giving users adequate time to migrate. > - Welcome community contributions - If any community members or > organizations rely on NiFi Registry and wish to maintain it, we > welcome contributions to complete the UI rewrite and address the > outstanding CVEs. The deprecation decision could be revisited if > substantial progress is made. > > Without active maintainers willing to do this work right away, > deprecation and eventual removal is the responsible path forward. > I look forward to hearing the community's thoughts on this proposal. > > Thanks, > Pierre
