Add explicit peer kind support to Management API

[ramphex]

Describe your changes

This PR adds explicit peer kind support to the Management API so peers can be classified as auto, device, or server.

Today, the dashboard has to infer peer type from enrollment behavior: peers enrolled with setup keys are treated as servers, and peers enrolled through SSO are treated as user devices. That inference is probably correct for most installations most of the time, but it is not always true. Some setup-key peers are regular devices, and some SSO-enrolled peers may function as servers, shared infrastructure, or unattended systems. Using enrollment method as the only source of truth makes the implementation clunky and limits the dashboard’s ability to represent the user’s actual environment.

This PR keeps the current behavior compatible by making auto the default value. In auto mode, dashboards and clients can continue using the existing inference logic. Newer dashboards can optionally let users override the classification by setting kind to device or server.

Changes included:

• Adds a peer Kind field in the management server model.
• Supports three values: auto, device, and server.
• Defaults existing and new peers to auto.
• Adds a store migration to backfill the new kind field on existing peer records.
• Includes kind in peer list and single-peer API responses.
• Accepts optional kind updates through the peer update API.
• Validates invalid peer kind values server-side and rejects them with an invalid argument error.
• Updates the optimized/raw SQL account loader so peer kind is loaded consistently across store paths.
• Updates the OpenAPI schema and generated API types for the new field.
• Adds tests for valid peer kind updates, invalid peer kind rejection, persistence, preservation when omitted, migration/default behavior, and account copy/store consistency.

This is intended to support the companion dashboard change that restores the combined Peers page and allows the UI to respect explicit peer type when the backend provides it.

Issue ticket number and link

Supports dashboard issue: netbirdio/dashboard#663
Supports dashboard PR: netbirdio/dashboard#668

Issue #663 reports that the split Peers UI reduced functionality by forcing users to move between separate User Devices and Servers pages instead of working from one complete peer list. This API change addresses the underlying classification limitation that made the split awkward: the existing server/device distinction is inferred from enrollment method, which is useful as a default but not always accurate.

Stack

Companion dashboard PR: netbirdio/dashboard#668

Checklist

• Is it a bug fix
• Is a typo/documentation fix
• Is a feature enhancement
• It is a refactor
• Created tests that fail without the change (if possible)
• This change does not modify the public API, gRPC protocols, functionality behavior, CLI / service flags, or introduce a new feature — OR I have discussed it with the NetBird team beforehand (link the issue / Slack thread in the description). See CONTRIBUTING.md.

Because this adds a public REST API field, I left the public API checklist item unchecked unless maintainers consider the linked dashboard issue/PR sufficient prior discussion.

By submitting this pull request, you confirm that you have read and agree to the terms of the Contributor License Agreement.

Documentation

Select exactly one:

• I added/updated documentation for this change
• Documentation is not needed for this change (explain why)

This change adds a small Management API field used by the dashboard to classify peers as automatic, device, or server. It does not introduce a new setup flow, operator configuration step, CLI flag, or user-facing self-hosting procedure. The dashboard companion PR presents the relevant behavior directly in the UI through the Peers page controls and peer detail field.

Docs PR URL (required if "docs added" is checked)

Paste the PR link from https://github.com/netbirdio/docs here:

https://github.com/netbirdio/docs/pull/__

Summary by CodeRabbit

• New Features
  • Peers can now be classified with a kind field (auto, device, or server)
  • The kind field is included in peer API responses and can be updated
  • Invalid kind values are rejected with appropriate error responses

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d2b35b44-cc74-4860-bd65-43dae7f11cfe

📥 Commits

Reviewing files that changed from the base of the PR and between cd77739 and 1c4c031.

📒 Files selected for processing (10)

• management/server/account_test.go
• management/server/http/handlers/peers/peers_handler.go
• management/server/http/handlers/peers/peers_handler_test.go
• management/server/peer.go
• management/server/peer/peer.go
• management/server/peer_test.go
• management/server/store/sql_store.go
• management/server/store/store.go
• shared/management/http/api/openapi.yml
• shared/management/http/api/types.gen.go

---

📝 Walkthrough

Walkthrough

Introduces a Kind field on the peer model with three values: auto, device, and server. The type is defined in the domain layer with validation and normalization helpers, propagated through the OpenAPI spec, generated API types, a DB migration, the SQL store, the UpdatePeer service method, and HTTP handler request parsing and response serialization.

Changes

Peer Kind Classification

Layer / File(s)	Summary
Kind type, Peer model, and API contracts management/server/peer/peer.go, shared/management/http/api/openapi.yml, shared/management/http/api/types.gen.go	Defines Kind string type with auto/device/server constants and IsValid/Normalize helpers, adds Kind to the Peer struct with a GORM varchar(16) default, normalizes on Copy, adds PeerKind enum to the OpenAPI spec as a required response field and optional request field, and generates corresponding Go types with Valid() and updated Peer, PeerBatch, PeerRequest structs.
DB migration and SQL store management/server/store/store.go, management/server/store/sql_store.go	Inserts a pre-auto migration to add the kind column defaulting to auto, and updates the pgx getPeers query to select and scan peer_kind, setting p.Kind with normalization.
UpdatePeer service logic and tests management/server/peer.go, management/server/peer_test.go, management/server/account_test.go	Extends UpdatePeer to validate and normalize update.Kind when non-empty, returning InvalidArgument on unrecognized values. Adds TestUpdatePeer_Kind covering kind persistence and preservation, and updates the TestAccount_Copy fixture to include KindAuto.
HTTP handler kind validation, response serialization, and tests management/server/http/handlers/peers/peers_handler.go, management/server/http/handlers/peers/peers_handler_test.go	updatePeer reads and validates req.Kind, rejecting invalid values with HTTP 422. toSinglePeerResponse and toPeerListItemResponse both populate Kind via Normalize(). Handler tests add "kind":"server" to PUT payloads, assert the returned Kind, and cover the invalid-kind rejection path.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

• pascal-fischer

Poem

🐇 Hop, hop, what kind am I?
Auto, device, or server high?
A new field blossoms in the peer,
Normalized and validated clear.
The rabbit stamps each kind with care —
No "workstation" nonsense here! 🌿

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 10.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely summarizes the main change: adding explicit peer kind support to the Management API, which is the primary objective of this PR.
Description check	✅ Passed	The description is comprehensive and well-structured, covering the motivation, changes, implementation details, and testing. It addresses all critical sections including rationale, issue links, and checklist items.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
9.3% Duplication on New Code

See analysis details on SonarQube Cloud