Phil, Thanks for asking. Thus far there has not been any discussion on a timeline for NiFi 3.
Over a number of NiFi minor versions, there have been a handful of minor component deprecations, which would also be subject to removal. With major work going on right now on a development branch for Connectors under NIP-11, I would not expect any formal steps to NiFi 3 until after that feature has landed. On the practical impact for NiFi Registry, I would expect incremental dependency upgrades as maintenance for the coming months, following the pattern of recent years. Regards, David Handermann On Sat, Jan 31, 2026 at 11:04 AM Phil Lord <[email protected]> wrote: > > Given this development... Is there any kind of loose estimate on a release > date for NiFi 3? > > Thanks, > Phil > > On Fri, Jan 30, 2026 at 3:38 PM David Handermann > <[email protected]> wrote: >> >> Pierre et al, >> >> Following up on this discussion, it looks like the general sense is in >> favor of, or not strongly opposed to, deprecating the NiFi Registry >> project for removal. >> >> As with a number of features and extensions in NiFi 1, this highlights >> lessons learned along the way. Although there may be certain use case >> gaps to consider and address, reducing the overall NiFi project >> maintenance footprint should be a net benefit in focusing community >> efforts. >> >> I recommend moving this discussion to a formal vote on deprecation, >> and subsequent removal in a future NiFi 3 release version. >> >> Regards, >> David Handermann >> >> On Tue, Jan 20, 2026 at 10:55 AM Kevin Doran <[email protected]> wrote: >> > >> > 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.
