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.
