You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.
Higress Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Supporting governance and community documentation is maintained in higress-group/community. Other repositories within the project scope are listed under Sub-Projects below.
Sub-Projects: higress-console, higress-standalone, plugin-server, and wasm-go. Their scope and status are documented in GOVERNANCE.md.
Related Projects: None declared for this application. Higress integrates with and builds on CNCF projects including Kubernetes, Envoy, Istio, Prometheus, and OpenTelemetry, but does not claim those projects as Higress subprojects.
Communication: The official public and private-purpose channels are listed in COMMUNITY.md. Public channels include GitHub Issues, Pull Requests, Discussions, Discord, and the monthly Higress Community Meeting.
This project is applying to join the CNCF at the Incubation level.
Not applicable because Higress is already a CNCF Sandbox project.
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
Ant Digital
Kuaishou
Trip.com Group
Vipshop
Labring, the company behind Sealos
The public evidence is maintained in ADOPTERS.md. The expanded adopter list was merged in community#8.
Adopter Interviews: Five adopter questionnaires were submitted on September 4, 2026 for Ant Digital, Kuaishou, Trip.com Group, Vipshop, and Labring/Sealos, with each submission linked to this application. All contacts have agreed to participate in the CNCF interview. Public identification in the Due Diligence remains subject to company approval. CNCF interviews and TOC verification remain pending.
Application Process Principles
Suggested
Engage with domain-specific TAG(s) to present the technical architecture of the project.
This has not yet been completed. We are available to present the architecture if requested during review.
The project assessment is complete and published in general-technical-review.md. The external Project Reviews request is open in cncf/toc#2266 and is awaiting triage and reviewer assignment. The CNCF DD triage guide states that projects should not be blocked while CNCF associates review and upload vetted snapshots.
The project assessment is complete and published in governance-review.md. The external Project Reviews request is open in cncf/toc#2267 and is awaiting triage and reviewer assignment. The CNCF DD triage guide states that projects should not be blocked while CNCF associates review and upload vetted snapshots.
Higress can be deployed on any conformant Kubernetes cluster in public cloud, private cloud, on-premises, or local environments. It does not require an Alibaba Cloud account, API, or commercial service. Project governance gives no company a reserved seat, veto, or preferred decision weight. Alibaba Cloud's commercial Higress offering is a downstream distribution and has no special authority over the open source project. The project's vendor-neutral governance is documented in GOVERNANCE.md.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Higress completed Sandbox onboarding on June 17, 2026, and acknowledges the current Incubation criteria and ongoing CNCF project obligations.
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
This application requests the review. DD, public comment, resolution of concerns, and TOC decision remain to be completed.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject if completed as a suggested item prior to application.
Suggested
Complete a Governance Review with the Project Reviews subproject
cncf/toc#2267 is open and awaiting triage and reviewer assignment.
Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
Governance, maintainer lifecycle, vendor neutrality, security roles, project scope, and public meeting processes are maintained through public pull requests in the community repository.
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
Subproject scope, status, governance, and lifecycle are documented in GOVERNANCE.md.
Required
Clear and discoverable project governance documentation.
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
The governance model uses public lazy consensus and public issue or pull request records. Current meeting and leadership information is linked from the community repository.
Governance clearly documents vendor-neutrality of project direction.
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Function-based teams are covered in GOVERNANCE.md. Security Response Team membership and responsibilities are documented in SECURITY.md.
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Roles, nomination, annual review, affiliation updates, offboarding, removal, and emeritus status are documented in MAINTAINERS.md.
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
The maintainer roster was formally established through higress#3754, and the lifecycle process and 2026 activity and affiliation review were documented through higress#4177. community#10, merged on September 3, 2026, records the review and its outcome in the canonical maintainer documentation. The project applied the lifecycle review and retained all seven maintainers as active. No project event required an addition, replacement, or emeritus transition, so the project did not manufacture an artificial personnel change solely for this application.
Maintainer affiliations are current and a policy is in place requiring updates within 30 days of employment changes.(If affiliations have lapsed, document how the project identified and corrected them.)
Current affiliations are maintained in MAINTAINERS.md. community#10, merged on September 3, 2026, added the explicit requirement that maintainers update their affiliation within 30 days of an employment or organizational affiliation change.
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
A number of active maintainers which is appropriate to the size and scope of the project.
Higress currently documents seven active project maintainers and public activity evidence for the annual roster review.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
Project-wide maintainers are documented in MAINTAINERS.md, while day-to-day path ownership is delegated through repository CODEOWNERS, including the primary repository rules.
Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.
Project must have, and document, at least one public communications channel for users and/or contributors.
Public GitHub channels, Discord, community groups, and meetings are listed in COMMUNITY.md.
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance if completed as a suggested item prior to application.
Suggested
Complete a joint security assessment with TAG Security and Compliance
This has not been completed. The Security Self-Assessment has been reviewed and approved in cncf/toc#2268, and Higress is available for a joint assessment if requested.
Required
Clearly defined and discoverable process to report security issues.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
The protected main branch requires one approval, a Code Owner review, and successful license/cla, build, lint, and Analyze (go) checks against the current base branch. Force pushes and branch deletion are disabled. Build, Go vet, and CodeQL workflows are maintained in the public repository.
Document assignment of security response roles and how reports are handled.(This is distinct from the security reporting process above — document who is responsible for triaging and responding to reports, not just where to send them. For reference, see the Kubernetes Security Response Committee as a model for named membership, documented responsibilities, and a clear escalation path.)
Named Security Response Team membership, triage, fix, review, release, disclosure, conflict, and escalation responsibilities are documented in SECURITY.md.
The project copy is published in security-self-assessment.md. The canonical CNCF copy is proposed in cncf/toc#2268, where the latest version has received reviewer approval and is awaiting CNCF merge.
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
See ADOPTERS.md, including environment and use case information.
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
Kuaishou, Trip.com Group, Vipshop, and Labring are independent from the project's primary contributing vendor and report production use. Ant Digital is also publicly listed but is not relied upon to satisfy the independence minimum.
TOC verification of adopters.
Five adopter questionnaires were submitted on September 4, 2026. CNCF interviews and TOC verification remain pending. Any published interview summary remains subject to final adopter approval.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
Integrations and compatibility with Kubernetes, Gateway API, Envoy, Istio, Prometheus, OpenTelemetry, OCI registries, service registries, model providers, and related systems are documented in the General Technical Review, architecture documentation, project README, and user documentation.
Specification Project Information (if applicable)
Not applicable. Higress is a software project and does not define normative behavior intended for independent third-party implementation.
Additional Information
The following CNCF review artifacts are already available or in progress:
Review Project Moving Level Evaluation
[x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.
Higress Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Project Repo(s):
Supporting governance and community documentation is maintained in higress-group/community. Other repositories within the project scope are listed under Sub-Projects below.
Project Site: https://higress.ai/en/
Sub-Projects:
higress-console,higress-standalone,plugin-server, andwasm-go. Their scope and status are documented in GOVERNANCE.md.Related Projects: None declared for this application. Higress integrates with and builds on CNCF projects including Kubernetes, Envoy, Istio, Prometheus, and OpenTelemetry, but does not claim those projects as Higress subprojects.
Communication: The official public and private-purpose channels are listed in COMMUNITY.md. Public channels include GitHub Issues, Pull Requests, Discussions, Discord, and the monthly Higress Community Meeting.
Project points of contact:
Yuanxiao Zhao, @EndlessSeeker, 1766508902@qq.com
Yiquan Dong, @CH3CHO, ch3cho@qq.com
(Post Incubation only) Book a meeting with CNCF staff to understand project benefits and event resources.
Not applicable at the time of application.
Incubation Criteria Summary for Higress
Application Level Assertion
This project is currently Sandbox, accepted on 2026-04-13, and applying to Incubation.
The Sandbox application was accepted in 2026, and project onboarding was completed on June 17, 2026.
This project is applying to join the CNCF at the Incubation level.
Not applicable because Higress is already a CNCF Sandbox project.
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
The public evidence is maintained in ADOPTERS.md. The expanded adopter list was merged in community#8.
Adopter Interviews: Five adopter questionnaires were submitted on September 4, 2026 for Ant Digital, Kuaishou, Trip.com Group, Vipshop, and Labring/Sealos, with each submission linked to this application. All contacts have agreed to participate in the CNCF interview. Public identification in the Due Diligence remains subject to company approval. CNCF interviews and TOC verification remain pending.
Application Process Principles
Suggested
Engage with domain-specific TAG(s) to present the technical architecture of the project.
This has not yet been completed. We are available to present the architecture if requested during review.
Required
Complete a General Technical Review (GTR).
The project assessment is complete and published in general-technical-review.md. The external Project Reviews request is open in cncf/toc#2266 and is awaiting triage and reviewer assignment. The CNCF DD triage guide states that projects should not be blocked while CNCF associates review and upload vetted snapshots.
Complete a Governance Review.
The project assessment is complete and published in governance-review.md. The external Project Reviews request is open in cncf/toc#2267 and is awaiting triage and reviewer assignment. The CNCF DD triage guide states that projects should not be blocked while CNCF associates review and upload vetted snapshots.
All project metadata and resources are vendor-neutral.
Higress can be deployed on any conformant Kubernetes cluster in public cloud, private cloud, on-premises, or local environments. It does not require an Alibaba Cloud account, API, or commercial service. Project governance gives no company a reserved seat, veto, or preferred decision weight. Alibaba Cloud's commercial Higress offering is a downstream distribution and has no special authority over the open source project. The project's vendor-neutral governance is documented in GOVERNANCE.md.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Higress completed Sandbox onboarding on June 17, 2026, and acknowledges the current Incubation criteria and ongoing CNCF project obligations.
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
This application requests the review. DD, public comment, resolution of concerns, and TOC decision remain to be completed.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
Installation, operations, end-user documentation, examples, and API references are available from the Higress documentation site and the primary repository.
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject if completed as a suggested item prior to application.
Suggested
Complete a Governance Review with the Project Reviews subproject
cncf/toc#2267 is open and awaiting triage and reviewer assignment.
Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
Governance, maintainer lifecycle, vendor neutrality, security roles, project scope, and public meeting processes are maintained through public pull requests in the community repository.
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
Subproject scope, status, governance, and lifecycle are documented in GOVERNANCE.md.
Required
Clear and discoverable project governance documentation.
See GOVERNANCE.md.
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
The governance model uses public lazy consensus and public issue or pull request records. Current meeting and leadership information is linked from the community repository.
Governance clearly documents vendor-neutrality of project direction.
See the Vendor Neutrality section of GOVERNANCE.md.
Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
See the Decision Making section of GOVERNANCE.md.
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Function-based teams are covered in GOVERNANCE.md. Security Response Team membership and responsibilities are documented in SECURITY.md.
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Roles, nomination, annual review, affiliation updates, offboarding, removal, and emeritus status are documented in MAINTAINERS.md.
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
The maintainer roster was formally established through higress#3754, and the lifecycle process and 2026 activity and affiliation review were documented through higress#4177. community#10, merged on September 3, 2026, records the review and its outcome in the canonical maintainer documentation. The project applied the lifecycle review and retained all seven maintainers as active. No project event required an addition, replacement, or emeritus transition, so the project did not manufacture an artificial personnel change solely for this application.
Maintainer affiliations are current and a policy is in place requiring updates within 30 days of employment changes. (If affiliations have lapsed, document how the project identified and corrected them.)
Current affiliations are maintained in MAINTAINERS.md. community#10, merged on September 3, 2026, added the explicit requirement that maintainers update their affiliation within 30 days of an employment or organizational affiliation change.
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
See MAINTAINERS.md.
A number of active maintainers which is appropriate to the size and scope of the project.
Higress currently documents seven active project maintainers and public activity evidence for the annual roster review.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
Project-wide maintainers are documented in MAINTAINERS.md, while day-to-day path ownership is delegated through repository
CODEOWNERS, including the primary repository rules.Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.
See CODE_OF_CONDUCT.md.
CNCF Code of Conduct is cross-linked from other governance documents.
It is linked at the beginning of GOVERNANCE.md.
All subprojects, if any, are listed.
See Project Scope and Subprojects in GOVERNANCE.md.
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.
Required
Contributor ladder with multiple roles for contributors.
Higress documents Contributor, Code owner, and Maintainer roles in GOVERNANCE.md and CONTRIBUTING_EN.md.
Clearly defined and discoverable process to submit issues or changes.
See CONTRIBUTING_EN.md.
Project must have, and document, at least one public communications channel for users and/or contributors.
Public GitHub channels, Discord, community groups, and meetings are listed in COMMUNITY.md.
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
See COMMUNITY.md.
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
The monthly schedule and joining information are documented in MEETINGS.md, with a recurring entry on the LFX public calendar. Meeting notes are published in the meetings directory.
Documentation of how to contribute, with increasing detail as the project matures.
See CONTRIBUTING_EN.md.
Demonstrate contributor activity and recruitment.
Public evidence includes GitHub contributors, recent activity, CNCF DevStats, and open
help wantedandgood first issueissues.Engineering Principles
Suggested
Roadmap change process is documented.
See ROADMAP.md.
History of regular, quality releases.
See GitHub Releases and the versioned release notes.
Required
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.
The project purpose, differentiation, and use cases are documented in the project README and General Technical Review.
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
See the project README and General Technical Review.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
See ROADMAP.md and the published roadmap.
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
See docs/architecture.md and the General Technical Review.
Document the project's release process.
See RELEASE.md.
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance if completed as a suggested item prior to application.
Suggested
Complete a joint security assessment with TAG Security and Compliance
This has not been completed. The Security Self-Assessment has been reviewed and approved in cncf/toc#2268, and Higress is available for a joint assessment if requested.
Required
Clearly defined and discoverable process to report security issues.
See SECURITY.md.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
The protected
mainbranch requires one approval, a Code Owner review, and successfullicense/cla,build,lint, andAnalyze (go)checks against the current base branch. Force pushes and branch deletion are disabled. Build, Go vet, and CodeQL workflows are maintained in the public repository.Document assignment of security response roles and how reports are handled. (This is distinct from the security reporting process above — document who is responsible for triaging and responding to reports, not just where to send them. For reference, see the Kubernetes Security Response Committee as a model for named membership, documented responsibilities, and a clear escalation path.)
Named Security Response Team membership, triage, fix, review, release, disclosure, conflict, and escalation responsibilities are documented in SECURITY.md.
Document Security Self-Assessment.
The project copy is published in security-self-assessment.md. The canonical CNCF copy is proposed in cncf/toc#2268, where the latest version has received reviewer approval and is awaiting CNCF merge.
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge. (Link to your bestpractices.dev project page below.)
Higress has a current OpenSSF Best Practices Passing badge, with all Passing-level criteria reported as complete.
Ecosystem
Suggested
N/A
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
See ADOPTERS.md, including environment and use case information.
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
Kuaishou, Trip.com Group, Vipshop, and Labring are independent from the project's primary contributing vendor and report production use. Ant Digital is also publicly listed but is not relied upon to satisfy the independence minimum.
TOC verification of adopters.
Five adopter questionnaires were submitted on September 4, 2026. CNCF interviews and TOC verification remain pending. Any published interview summary remains subject to final adopter approval.
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
Integrations and compatibility with Kubernetes, Gateway API, Envoy, Istio, Prometheus, OpenTelemetry, OCI registries, service registries, model providers, and related systems are documented in the General Technical Review, architecture documentation, project README, and user documentation.
Specification Project Information (if applicable)
Not applicable. Higress is a software project and does not define normative behavior intended for independent third-party implementation.
Additional Information
The following CNCF review artifacts are already available or in progress:
The project is ready to answer reviewer questions, join Project Reviews meetings, and provide additional evidence during due diligence.