Thanks all for the feedback so far. Just my thoughts on some comments that have been made.
- Shane, Scott, The community truly appreciates the work that has been done so far to rewrite the UI over the past half year. And I believe that regardless of this discussion, this work needs to happen anyway. As I said, we have a responsibility of addressing the CVEs for the software that we ship and the NiFi Registry has a very long list of CVEs as of today. Having said that, as David said, this is not the full picture. A lot of work would also need to happen on the backend side and we have not seen (significant) contributions for the NiFi Registry in a long time. I think that keeping the NiFi Registry as part of the Apache NiFi project would be great but it needs real ownership with enough contributions for a group of people that is large enough. This is the reason why I said the deprecation decision could be revisited whenever we start a discussion for NiFi 3 (which is not something I'm expecting soon). - Mark, Definitely agree that it would be a nice improvement and it would close the gap. I think this is a very fair approach. - Mike, That is correct, since NiFi 2, it is possible to configure Flow Registry Clients that are directly integrated with git-based solutions (as of today: Github, Gitlab, Bitbucket, Azure DevOps). This direct integration provides a lot of advantages compared to the integration with the NiFi Registry. - Yuanhao, > "Yes, you can create branches, but only from the repository side, not nifi > side" There is an open Pull Request to add support for creating branches from the NiFi side. This is something coming. Just need more people willing to review/test the many pull requests we have :) > "I cannot create a branch for a specific flow, but only the entire registry" This is how git-based solutions work: a branch is always for the complete repository, you cannot create a branch for specific files. > "the merging/rebase is not possible for single flow from nifi side" I have not seen any request for that before. Usually, flow developers would follow a more traditional developer UX where the changes via a branch are submitted through a pull request that can be reviewed and tested before it gets merged there and it can trigger CI/CD pipelines. Thanks, Pierre Le mar. 13 janv. 2026 à 09:07, Yuanhao Zhu <[email protected]> a écrit : > > 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.
