Hi Mike, Regarding the suggestion to add a DatabaseFlowRegistryClient as a replacement for the NiFi Registry DatabaseFlowPersistenceProvider. That's an interesting suggestion. It would also allow for a simple migration strategy for current NiFi Registry users of the DatabaseFlowPersistenceProvider, while also addressing a lot of the security/vulnerability concerns with dependencies mentioned in this thread.
Part of the reason (for me) that it would make sense to deprecate NiFi Registry and replace it with the Git-based registry clients is that git already supports rich version control semantics including branching, making it much more straightforward to build those features into NiFi flow versioning. Any database-backed client is going to have to build more the logic for versioning, branching, merging, etc into the client as those are not native operations the database persistence provider supports. This makes the implementation and maintenance more challenging. In deciding on a path forward, I think it is important to consider which active maintainers are available and willing to do the work near-term and over time. To be candid, I don't have the availability to contribute to the development of a DatabaseFlowRegistryClient, but if others submitted patches to the Apache repo with that functionality, I would not oppose it. Additionally, offering the RegistryClient interface as an extension point in the NiFi framework does allow for some flexibility for solutions to be developed outside of the Apache repo. Cheers, Kevin On Fri, Jan 16, 2026 at 12:28 PM Michael Moser <[email protected]> wrote: > > Would the community support the maintenance of a DatabaseFlowRegistryClient to > take the place of the NiFi Registry DatabaseFlowPersistenceProvider? > > -- Mike > > > On Fri, Jan 16, 2026 at 10:18 AM Pierre Villard <[email protected]> > wrote: >> >> - Dirk, >> >> I'm not sure I'm following the scenario that you're describing. Are >> you saying that you're adding a new version of an existing NAR? and >> you want to update the version of the already instantiated components >> of that NAR to use the new version? >> >> To not have this thread going into many directions, I recommend filing >> a JIRA (or a new thread on the mailing list) and happy to follow-up >> there. >> >> - Geoff, >> >> I'll answer on the JIRA you filed but thanks for bringing this up. >> There is one aspect that is configuration driven but another one seems >> to be a bug that should be addressed. I'll confirm on my side and >> follow up on the JIRA you created [1]. >> >> [1] https://issues.apache.org/jira/browse/NIFI-15475 >> >> Thanks, >> Pierre >> >> >> Le jeu. 15 janv. 2026 à 22:22, Greene (US), Geoffrey N via users >> <[email protected]> a écrit : >> > >> > So, under the assumption that nifi-registry [which we rely quite heavily >> > on] is going to go away, I looked at the replacement, which I gather is >> > GitlabFlow Registry client (with a gitlab backing store) >> > >> > With both nifi 2.7.2 and nifi 2.6.0: >> > >> > >> > >> > Create a simple flow, and check it into the Gitlab FlowRegistry. >> > Reimport that flow, so we now have TWO identical copies of that flow >> > Change one copy of the flow, and check it in >> > The red upgrade needed flag in the upper left corner of the OTHER flow >> > doesn’t appear after many minutes. The greene checkmark remains on both, >> > even though one is out of date. This is really bad for us. >> > Unfortunately, and to make things worse, if you then attempt to make >> > another change in the OTHER flow, it doesn’t recognize the conflict, and >> > that change actually overwrites the change you made in step 3. >> > >> > >> > >> > This is going to have to be fixed in order for us to move from git >> > registry to the new gitlabflow. We have multiple copies of many of our >> > flows (code reuse, what a concept), and we need to know when something is >> > out of date. >> > >> > >> > >> > This seems related to NiFi-14478 but that was supposedly fixed in >> > September 2025, and claims to have a fix version of 2.6.0, yet it >> > continues to be an issue in nifi 2.7.2. >> > >> > >> > >> > To be clear this is only an issue with gitlab flow, not with git registry. >> > >> > >> > >> > Restarting nifi between steps 3 and 4 does mitigate the issue, but isn’t a >> > good fix. >> > >> > >> > >> > Thanks >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Geoff Greene >> > >> > ATF / Senior Software Ninjaneer >> > >> > >> > >> > >> > >> > From: Yuanhao Zhu <[email protected]> >> > Sent: Tuesday, January 13, 2026 3:07 AM >> > To: [email protected] >> > Subject: [EXTERNAL] Re: [DISCUSS] Proposal to Deprecate NiFi Registry >> > >> > >> > >> > EXT email: be mindful of links/attachments. >> > >> > >> > >> > >> > 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.
