Feedback: v0.74.0 #6634
Replies: 4 comments 4 replies
-
|
Hello, I upgraded to 7.4.0 and getting this error when running docker compose up -d Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint netbird-proxy (a1665292b6ca1eb7ee62177a2a8230f142471ee71b141deef6b7986b1b6f860f): failed to bind host port 0.0.0.0:51820/udp: address already in use Any ideas what is causing this? Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
is possible that you have another process using the :51820 port? |
Beta Was this translation helpful? Give feedback.
-
|
My agent network settings are open and the necessary updates have been made. The options in Log Collection are not working. There is a small "object object" situation in the notification.
|
Beta Was this translation helpful? Give feedback.
-
|
Could you pls share logs from your netbird-server when the issue happens? |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
Before posting
Product area
Dashboard / Admin UI, Management service / API
Problem or use case
Agentic workloads demand tighter control, so organizations are turning to virtual keys to gate access to company-controlled endpoints and cap costs. But this introduces its own problems. Managing the keys is a burden, and it doesn't solve the classic secret-sharing problem: people can leave the company with these keys—and plenty of others—still in hand.
Proposed solution
New Feature: Agent Network
This release introduces Agent Network, a per-account LLM gateway that gives people and agents keyless, identity-based access to LLM APIs and internal resources over the tunnel. It is built on top of the existing reverse proxy and private services, so the transport is still NetBird's WireGuard overlay and the identity model is still your IdP. Have a tunnel, get access; no tunnel, no access.
Agents point at a tunnel-only endpoint instead of the provider's URL. NetBird holds the upstream provider key server-side, injects it per request, and ties every call to a real identity from your IdP. Client-supplied auth headers are stripped before the request is forwarded, so a hardcoded key never reaches the provider. The whole thing is default deny: nothing reaches a provider until a policy explicitly allows it.
Alternatives or workarounds considered
No response
Community impact and priority
Examples from other tools or products
No response
Security, privacy, and compatibility considerations
No response
Implementation ideas
No response
Are you willing to help?
Yes, I can submit a PR if the approach is accepted.
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions