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. >
