[Graduation] NATS Graduation Application

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.

NATS Graduation Application

v1.6 This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

Project Repo(s): https://github.com/nats-io

Project Site: https://nats.io

Sub-Projects/repositories:

• nats-server - The NATS server

Client libraries:

• natscli
• nats.go
• nats.js
• nats.py
• nats.rs
• nats.c
• nats.java
• nats.net
• nats-pure.rb
• nats.swift

Kubernetes related:

• k8s - NATS on Kubernetes with Helm Charts
• nack - NATS Operator for Kubernetes

Monitoring related:

• nats-surveyor - NATS Monitoring, Simplified.
• prometheus-nats-exportor - A Prometheus exporter for NATS metrics.

Additional tooling

• terraform-provider-jetstream - Terraform Provider for NATS JetStream

Communication:

• Slack: natsio.slack.com
• GitHub Discussions on each respective repository
• Google Groups: natsio
• YouTube @NATS_io
• Email: [email protected]

Project points of contacts:

• Ginger Collison ([email protected])
• Byron Ruth ([email protected])
• Derek Collison ([email protected])

• (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Graduation Criteria Summary for NATS

Application Level Assertion

• This project is currently Incubating, accepted on 2018-03-15, and applying to Graduate.

Adoption Assertion

The project has been adopted by the following organizations in a testing, integration, or production capacity:

Notable adopters include (from nats.io and CNCF case studies):

• Technology: Alibaba, Baidu, PayPal, Walmart, VMware, Ericsson, Siemens, Hewlett Packard Enterprise
• Financial Services: Capital One, Mastercard
• Automotive: Volvo, Rivian
• Telecommunications: AT&T
• Software: Tinder
• Production case studies: DeFacto (event-driven architecture), Finleap Connect (highly regulated industry with mTLS)
• Cloud Native Ecosystem: wasmCloud, Sophotech

Over 2,000 companies are documented as using NATS across various industries and use cases.

Application Process Principles

Suggested

N/A

Required

• Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
  • This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.
• All project metadata and resources are vendor-neutral. NATS governance explicitly documents vendor-neutrality through organization-based voting where each organization gets one vote regardless of the number of maintainers.
• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
  • Met during Project's application on 15-Mar-2018.
• Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

Comprehensive documentation available at https://docs.nats.io including installation guides, developer documentation, examples, and reference implementations. A fresh update is in progress. See also NATS by Example for a collection of examples.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• 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. NATS governance has evolved from initial creation to the current organization-based voting model.

Required

• Clear and discoverable project governance documentation.

Available at https://github.com/nats-io/nats-general/blob/main/GOVERNANCE.md. Each repository contains the GOVERNANCE.md file.

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes

Organization-based voting system is actively used for maintainer decisions.

• Governance clearly documents vendor-neutrality of project direction.

The current set of maintainers span multiple organizations and independents across the server and sub-projects.

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

• Currently, the NATS project does not define explicit leadership roles.

• Contribution acceptance is based on active maintainers for the respective repo.

• Requests to the CNCF can be requested through [email protected].

• Governance changes and project goals are made by consensus or 2/3 majority organization vote as documented in GOVERNANCE.md

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

Maintainer selection requires 2/3 majority organization vote; removal requires same threshold. See GOVERNANCE.md for details. When voted in as a maintainer, they are added to the respective GitHub nats-io team with permissions required to be a maintainer for the project, e.g. the nats-server or a client.

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

GOVERNANCE.md documents proposal, election (2/3 vote), and responsibilities. Currently, the NATS project does not have an explicit offboarding or emeritus process.

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

Multiple maintainers have been added over the course of the project history; maintainer list is actively maintained. See MAINTAINERS.md. See closed PRs exercising the lifecycle.

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

For nats-server, there 5 active maintainers, whereas each client or tooling project has 1-3 maintainers. This is appropriate for the size and scope of each project.

• Project maintainers from at least 2 organizations that demonstrates survivability.

Maintainers from Synadia, Spiff, and Independent contributors.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

GitHub permissions align with documented maintainer roles.

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

GOVERNANCE.md file explicitly states "NATS follows the CNCF Code of Conduct."

• CNCF Code of Conduct is cross-linked from other governance documents.

Referenced in GOVERNANCE.md

• All subprojects, if any, are listed.

See Sub-Projects section above.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

Each subproject has MAINTAINERS.md; maintainership is per-project basis per governance model.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• Contributor ladder with multiple roles for contributors.

GOVERNANCE.md defines maintainer roles and responsibilities; CONTRIBUTING.md guides new contributors.

Required

• Clearly defined and discoverable process to submit issues or changes.

CONTRIBUTING.md documents PR process including opening issues, PR guidelines, sign-off requirements, and testing expectations.

• Project must have, and document, at least one public communications channel for users and/or contributors.

Multiple channels are documented: Slack (https://slack.nats.io), GitHub Discussions, and Google Groups.

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

Public channels include Slack (https://slack.nats.io), GitHub Discussions, Google Groups, Email ([email protected]). For security issues, [email protected] is used and discourse is non-public.

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

Community engagement primarily through Slack and GitHub; needs formal meeting schedule integration with CNCF calendar.

• Documentation of how to contribute, with increasing detail as the project matures.

CONTRIBUTING.md provides detailed contribution guidelines.

• Demonstrate contributor activity and recruitment.

Active community with 169+ contributors on nats-server, 18.3k+ GitHub stars (at the time of this writing), 11k+ members in Slack. There is continuous PR activity and community engagement.

LFX Insights

Engineering Principles

• 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 requirement may also be satisfied by completing a General Technical Review.

NATS provides a unique connective technology for cloud-native, edge, and distributed systems with focus on simplicity, performance, and security. Goals documented at https://nats.io/about and https://docs.nats.io

• If applicable a General Technical Review was completed/updated on 09-02-2026, and can be discovered at https://github.com/nats-io/nats-general/blob/main/GENERAL-TECHNICAL-REVIEW.md

• Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.

Comprehensive documentation at https://docs.nats.io covers messaging patterns, streaming, KV store, object store, and cloud-native use cases. This is covered in more detail in the General Technical Review.

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

Roadmap maintained at https://nats.io/about/#roadmap.

• Roadmap change process is documented.

Roadmap decisions driven by community discussions, customer use cases, support challenges, and maintainer insights. GitHub milestones are used to track roadmap items.

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

Architecture decision are documented in the https://github.com/nats-io/nats-architecture-and-design repository.

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • Release expectations (scheduled or based on feature implementation).
  • Tagging as stable, unstable, and security related releases.
  • Information on branch and tag strategies.
  • Branch and platform support and length of support.
  • Artifacts included in the release.
  • Additional information on topics such as LTS and edge releases are optional.

See RELEASES.md

• History of regular, quality releases.

Prior to 2.12, the release cadence was based on scope which required variable time to implement. As of 2.12, the minor release cadence is now 6 months.

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.

Currently at Passing level: https://www.bestpractices.dev/projects/1895. Silver/gold badge is aspirational goal.

Required

• Clearly defined and discoverable process to report security issues.

Security policy available; vulnerabilities reported to [email protected] as documented in repository and website.

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

Maintainer access controls are in place and a pull-request review is required before merging.

• Document assignment of security response roles and how reports are handled.

Security reports directed to [email protected]; handled by maintainer team per governance model.

• Document Security Self-Assessment.

• Third Party Security Review.

Trail of Bits audit completed May 2025; 100% of findings resolved or accepted. Report: https://ostif.org/nats-audit-complete/

• Achieving OpenSSF Best Practices passing badge.

Achieved. https://www.bestpractices.dev/projects/1895

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

Adopters listed on https://nats.io/#powering-industry-leaders with company logos; CNCF case studies at https://www.cncf.io/projects/nats/

• 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)

Over 2,000 documented companies using NATS; multiple production case studies available.

• The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. See adopters listed in this document; detailed list can be provided to TOC upon request.

• TOC verification of adopters. Pending TOC review.

• Refer to the Adoption portion of this document. See Adoption Assertion and Adoption sections.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

A list of clients and integrations is maintained here based on community submissions: https://nats.io/download/#clients

Adoption

See ADOPTERS.md