Contribution policies

NetBird repositories do not all use the same intake, testing, commit, sign-off, or licensing rules. The files in the repository you are changing are authoritative. Read them before starting, and follow newer local requirements when this guide and a repository disagree.

Report a vulnerability

Do not open a public issue, discussion, or pull request for a suspected security vulnerability. Public reports can expose the problem before a fix is available.

For open source NetBird code, use one of the private channels in the core security policy:

• Open a private GitHub vulnerability report. This is the preferred route for repository findings.
• Email security@netbird.io.

If the finding affects NetBird Cloud or hosted infrastructure rather than the open source repository, use email. Include the affected component and version or commit, platform and deployment type, required attacker position or privileges, reproduction steps or a proof of concept when available, and the impact you observed. Partial reports are welcome; if you are unsure whether a finding is security-sensitive, send it privately and let the NetBird team assess it.

Keep public contributions safe to share

Issues, discussions, pull requests, comments, CI output, screenshots, and uploaded logs are normally public. Before posting, remove:

• setup keys, personal access tokens, API keys, session cookies, private keys, and identity-provider secrets;
• customer names or data, private email addresses, internal hostnames, production IP addresses, and account identifiers;
• unredacted diagnostics, configuration files, database content, or packet captures;
• signing files, cloud credentials, and credentials embedded in command history.

Use sanitized examples and the private security route when redaction would hide the behavior that matters. A non-security bug in the core product belongs in the appropriate GitHub Discussion, not in a security report.

Changes that need an agreed issue

The core project is discussion-first. For a non-trivial bug, regression, feature, enhancement, or integration idea, begin in Discussions, wait for validation and maintainer feedback, and then link the resulting agreed issue from the pull request.

The following core areas always need the design agreed before code is written:

• the public REST or management API, OpenAPI schema, and dashboard-facing contracts;
• management, signal, relay, or client-daemon gRPC protocols;
• behavior that existing deployments would experience differently after an upgrade;
• peer connectivity, NAT traversal, relay selection, WireGuard or Rosenpass key handling;
• routing, firewall, DNS, interface management, and other host integration;
• authentication, authorization, identity integration, tokens, permissions, or cryptography;
• CLI and service flags, configuration formats, and daemon IPC;
• store models, database schemas, and migrations;
• new features.

A typo, broken link, documentation correction, focused test, or one-line fix with an existing issue can normally go directly to a pull request. Other repositories may draw the boundary differently, so their local issue and discussion rules still take precedence.

Using AI tools

The core project has no policy for or against using an AI coding agent. The author standard does not change with the tool:

• Give the tool the target repository's local instructions and agreed issue before it drafts a change.
• Keep the diff small and single-purpose.
• Review every generated line and remove unsupported claims, unused abstractions, and irrelevant prose.
• Run the behavior and tests yourself; never invent command output or use CI as your first execution.
• Answer review questions directly and be able to explain the implementation, risks, and tradeoffs.

Whatever produced the draft, the person opening the pull request owns every submitted line and its consequences. Maintainers can assess whether the contribution is understandable, maintainable, tested, and aligned with the project's security and design expectations.

Attribution policy varies. The core and Terraform provider repositories do not accept Co-Authored-By or tool-attribution trailers, but that rule must not be assumed for another repository. Check its local contribution and commit guidance.

Licenses, agreements, and sign-offs

Read the target repository's LICENSE, contribution guide, and pull request template. Do not assume that one project's license, contributor agreement, Developer Certificate of Origin sign-off, or bot check applies across the NetBird organization.

The core netbirdio/netbird repository requires the NetBird Contributor License Agreement. Its pull request template links the agreement, and the repository's CLA check determines whether a core contribution can be merged. Check the local process again when contributing elsewhere.

Code of conduct

Participation in NetBird community spaces is governed by the NetBird Code of Conduct. Keep technical disagreement focused on the work, assume good faith while evidence is gathered, and treat contributors, users, and reviewers with respect.

The Code of Conduct lists community@netbird.io for reporting unacceptable behavior. Security vulnerabilities belong in the separate private security process.

When policies differ

Use this order when two instructions appear to conflict:

1. The target repository's current policy, templates, and required checks.
2. Maintainer direction on the issue or pull request.
3. This cross-project contributor guide.

Ask before proceeding when the difference affects security, licensing, generated files, release ownership, a destructive test, or whether the project accepts the change. Do not weaken a local check or substitute another repository's process to make a contribution easier to submit.