Contribute to NetBird

You do not need to begin with a large code change. A clear bug report, a tested reproduction, a documentation correction, or a helpful answer in the community can remove a real obstacle for the next person. If you do want to write code, start by finding the repository that owns the behavior and agreeing on the problem before investing in a patch.

Find a first task

Start with a problem you understand. The core repository's good first issue and help wanted searches can point you toward scoped work. Read the issue and its latest comments before you claim it; an open label does not guarantee that the task is unassigned or that the proposed approach is still current.

A first contribution can also be one of these:

• Reproduce a report on a supported platform and add the version, configuration, exact steps, and observed result that were missing.
• Turn a setup or usage question into a focused Q&A discussion, or answer one when you have verified the solution.
• Share a concrete use case in Slack or the community so maintainers can understand where the current workflow falls short.
• Correct a typo, stale link, unclear step, or unsupported claim in the documentation.
• Help translate the desktop UI through NetBird on Crowdin; the core repository's locale files are synchronized from there rather than edited by hand.

For a bug, regression, feature, or integration idea in the core project, search Discussions before opening a new one. Use the category that matches the report and describe the problem, affected component, environment, expected behavior, and actual behavior. Never post a suspected vulnerability publicly; use the private reporting process.

Before you write code

Read the target repository's CONTRIBUTING.md, AGENTS.md, CLAUDE.md, pull request template, and workflow files when they exist. Repository-local instructions are authoritative: they define the accepted workflow, tool versions, generated files, test commands, title format, sign-off rules, and contribution agreements for that project.

The core netbirdio/netbird project is discussion-first. Except for trivial fixes, begin in the appropriate GitHub Discussion, wait while the report and direction are validated, and write code only after there is an agreed issue to link. Public APIs, protocols, existing behavior, peer connectivity, host networking, authentication and authorization, CLI or service configuration, persistence, and new features always need agreement before implementation. The contribution policies explain this boundary.

Small documentation corrections, typo and broken-link fixes, focused tests, and a one-line fix that already has an issue can normally go straight to a pull request. When you are unsure, ask in the target repository or on Slack before building a large patch.

A practical contribution flow

1. Choose the repository and component that owns the change.
2. Confirm the problem and the expected direction under that repository's rules.
3. Build and test the smallest useful change, containing privileged networking work in a disposable environment.
4. Prepare a reviewable pull request with the linked issue, real verification, and one clear purpose.
5. Respond to human and automated review, keeping the repository's local policy authoritative throughout.

Choose where to contribute

The canonical repository map groups projects by the kind of contribution you want to make and covers cross-repository changes.

Open a reviewable pull request

Follow the complete pull request workflow and review checklist.

Using AI tools

Coding assistants are allowed in the core project, but they do not change the contribution standard: you must understand every line, verify the result yourself, and answer review questions directly. Read the tooling and authorship policy and then follow the target repository's local rules.

Documentation changes

Every published docs page includes Edit on GitHub near the bottom. Use it to open the source file for a typo, broken link, or small clarification, make the focused edit in GitHub, and propose the change as a pull request. Explain what was unclear and, for a technical correction, include the source or test that establishes the new behavior.

For a new page, navigation change, component edit, or larger rewrite, fork netbirdio/docs, preview the affected routes locally, and use the documentation-site workflow. Verify product behavior before changing commands, defaults, UI labels, ports, or compatibility claims. Do not hand-edit src/pages/ipa/resources; those API pages are generated from the core OpenAPI schema.

Terms and conduct

Licenses, contribution agreements, sign-off requirements, and review rules can differ by repository. Read the target project's files rather than carrying a rule over from another NetBird repository. See Contribution policies for conduct, licensing, public-data, security, and authorship guidance.