[GH-ISSUE #1173] Feature Request: API-based Agent client "Platform" #1853

Open
opened 2026-08-05 00:44:13 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @ReK42 on GitHub (Sep 26, 2023).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/1173

Is your feature request related to a problem? Please describe.

Dedicated network hardware is beginning to have support for Wireguard, but cannot run the agent software for management and control. This necessitates using additional hardware and more complicated networking to connect sites to the mesh when the site router would otherwise be capable of it directly.

Describe the solution you'd like

Many such devices include REST-based APIs for automation, for example Mikrotik's RouterOS API can POST to /interface/wireguard. If the agent software could be run elsewhere in the local network, either containerized or as a daemon on a server, it could connect to the cloud/self-hosted instance as normal but then push the required configuration to the external device via API, rather than local commands/config files. Information and tests required to determine public addressing, NAT, etc. could also be retrieved from the API. Vendor-specific APIs could then be implemented as modules to this "API-as-a-Platform" agent.

Describe alternatives you've considered

  • Some platforms support running containerized applications, however this does not lend itself to performance if the Wireguard tunnel is run inside the container. This is especially problematic as these devices generally rely on hardware offload for much of their function and so have very anemic general-purpose compute resources. It would be ideal to run the proposed agent controller container on platforms which support it, however.
  • Polling-based agents, like proposed in #496 would require a new agent architecture, whereas this could likely be implemented in a way that takes advantage of the existing, already cross-platform, agent code and agent-to-instance communication.
Originally created by @ReK42 on GitHub (Sep 26, 2023). Original GitHub issue: https://github.com/netbirdio/netbird/issues/1173 **Is your feature request related to a problem? Please describe.** Dedicated network hardware is beginning to have support for Wireguard, but cannot run the agent software for management and control. This necessitates using additional hardware and more complicated networking to connect sites to the mesh when the site router would otherwise be capable of it directly. **Describe the solution you'd like** Many such devices include REST-based APIs for automation, for example Mikrotik's [RouterOS API](https://help.mikrotik.com/docs/display/ROS/REST+API) can POST to `/interface/wireguard`. If the agent software could be run elsewhere in the local network, either containerized or as a daemon on a server, it could connect to the cloud/self-hosted instance as normal but then push the required configuration to the external device via API, rather than local commands/config files. Information and tests required to determine public addressing, NAT, etc. could also be retrieved from the API. Vendor-specific APIs could then be implemented as modules to this "API-as-a-Platform" agent. **Describe alternatives you've considered** - Some platforms support running containerized applications, however this does not lend itself to performance if the Wireguard tunnel is run inside the container. This is especially problematic as these devices generally rely on hardware offload for much of their function and so have very anemic general-purpose compute resources. It would be ideal to run the proposed agent controller container on platforms which support it, however. - Polling-based agents, like proposed in #496 would require a new agent architecture, whereas this could likely be implemented in a way that takes advantage of the existing, already cross-platform, agent code and agent-to-instance communication.
saavagebueno added the feature-request label 2026-08-05 00:44:13 -04:00
Author
Owner

@renne commented on GitHub (Mar 5, 2026):

Would also be great for SOHO mesh networks with e.g. Fritz!Boxes as uplink routers.

<!-- gh-comment-id:4005076616 --> @renne commented on GitHub (Mar 5, 2026): Would also be great for SOHO mesh networks with e.g. Fritz!Boxes as uplink routers.
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#1853