Hey guys, Thanks for triggering the discussion. From our point of view, we don't mind switching to the git-based flow versioning. However, maybe this is not relevant, are you planning to integrate full git support for single flow versioning? Like branching/rebase/merge for single flow as well? We've noticed the git-based registry client since migration to 2.x, but we didn't choose to switch using that because at the end of the day it still does not enable the flow versioning like git. Yes, you can create branches, but only from the repository side, not nifi side, and I cannot create a branch for a specific flow, but only the entire registry. Also, the merging/rebase is not possible for single flow from nifi side. If the git based registry client actually full support those operations, I think at least we will try to switch to using that ASAP(hopefully more people would agree) cuz it would provide so much more benefit
BR Yuanhao ________________________________ From: David Handermann <[email protected]> Sent: Monday, 12 January 2026 21:48 To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Proposal to Deprecate NiFi Registry CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Pierre, Thanks for initiating this discussion, I concur with your summary of the situation. I believe your proposal is the best way forward under the circumstances. Although a large part of the maintenance relates to the user interface, as I mentioned almost a year ago [1], the minimal amount of maintenance relates to Registry as a sub-project in general. Aside from the substantive progress that Shane and Scott have made on bringing the UI to a maintainable state, the rest of the sub-project has received little attention. Lack of change might prompt one to think that the sub-project does not need maintenance, but a quick comparison to NiFi itself should underscore the fact that maintenance is required. It is not a matter of writing up potential areas to address, but instead a matter of available active committer cycles. As Pierre highlighted, project contributor focus and activity has shifted to direct Flow Registry Client integrations, and that should be the path forward. It is helpful to understand current usage and potential feature gaps, and active project maintainers should take this feedback into consideration. Given limited maintenance cycles, however, it is essential to focus on what is maintainable, and what needs to be abandoned. Following Pierre's emphasis, the core question is active maintainers willing to do the work right away. The corollary question is whether that work should be done given alternatives. I have some additional thoughts, but will hold off for now for additional comments to come in. Regards, David Handermann [1] https://lists.apache.org/thread/xwcrqww4q3yzyq8z3jfbzg55sosnrdx0 On Mon, Jan 12, 2026 at 2:19 PM Mike Brown <[email protected]> wrote: > > Am i understanding this that you are proposal removinal use of Nifi Registry > completely and moving to an option where Nifi can directly communicate with > git and store the configurations in a project in there? > > On Mon, Jan 12, 2026 at 3:13 PM Shane Ardell <[email protected]> wrote: >>> >>> The UI modernization effort has stalled, and >>> there is currently no clear path to completion without significant >>> volunteer contributions. >> >> >> I've been working with Scott Aslan over the past half year rewriting the >> Registry UI. Here is a list of commits made contributing toward the new >> Registry UI [1] and the significant progress made. The last piece of work >> [2] that was merged into the codebase was on November 6th last year, so >> about 8 weeks of inactivity in GitHub. I apologize if it looks like we >> stalled, but that definitely is not the case for those of us working on the >> task. I just happened to take some holiday time towards the end of last >> year, and I'm guessing Scott did as well. >> >> I reached out to Scott last Friday to discuss the last significant piece of >> the rewrite [3], which I offered to start work on. Once that is complete, >> the only remaining necessary work would be to include it in the maven build >> [4]. >> >> Reasons why we'd like to keep Registry in the NiFi project are mentioned in >> an email thread from last year having a very similar discussion [5]. >> >> We have been working in a bit of a bubble (outside of PR feedback we chat >> directly on NiFi's Slack workspace) which doesn't help the greater community >> understand our progress. Perhaps it would help if we had a dedicated channel >> for the rewrite in Slack to give better visibility into where we're at and >> have a record of these discussions. I'm also open to other ideas regarding >> more open communication as we continue toward finishing this piece of work. >> >> Best, >> Shane >> >> [1] >> https://github.com/apache/nifi/commits/main/nifi-frontend/src/main/frontend/apps/nifi-registry >> [2] https://github.com/apache/nifi/pull/10399 >> [3] https://issues.apache.org/jira/browse/NIFI-14321 >> [4] https://issues.apache.org/jira/browse/NIFI-13940 >> [5] https://lists.apache.org/thread/xwcrqww4q3yzyq8z3jfbzg55sosnrdx0 >> >> >> On Mon, Jan 12, 2026 at 11:50 AM 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 > > > > -- > > MIKE BROWN > > [email protected] > > > DISCLAIMER: The content of this email is intended for the person or entity to > which it is addressed only. This email may contain confidential information. > If you are not the person to whom this message is addressed, be aware that > any use, reproduction, or distribution of this message is strictly > prohibited. If you received this in error, please contact the sender and > immediately delete this email and any attachments.
