u/netbirdio

If you manage AI access for your team you’ve probably handed out plenty API tokens to individuals or a key for an entire team. That key gets copied into agents, scripts, and .env files. Someone leaves, who knows what they did with the keys. It's the same mess we all lived through with SSH keys for years: shared, copied onto machines by hand, and never revoked when people move on.

https://preview.redd.it/jqnlw679xqah1.png?width=2036&format=png&auto=webp&s=0f5797c558494558ff3c0ef780bce5c27791839f

A lot of customers had started using an AI gateway with their stack and tried to come up with their own solution to wire it back into their identity provider. One night, after a customer call, Misha (our CEO) and Maycon (our CTO) realized the reverse proxy we already shipped was, with a few tweaks, already most of an AI gateway. So we didn't build some giant new AI platform. We wrapped what was already there.

Checkout the release here: https://github.com/netbirdio/netbird/releases/tag/v0.74.0

That's NetBird Agent Network. Any person or agent can use any AI provider without ever holding a key. NetBird holds the provider key server-side, injects it per request, and ties every call to a real identity from your IdP (Okta, Entra ID, Google, and others). And all it requires for the end user is a gateway url and the NetBird client running in the background. The tunnel is the credential. No tunnel, no access, same rule you already know. It allows you to securely route agents to any major AI provider or local model, while simultaneously controlling agent access to internal network resources like databases and APIs. With centralized guardrails such as budget caps, model allowlists, and PII redaction, you maintain complete visibility and control through detailed per-request audit logs, making it simple to manage access and security without the headache of rotating keys.

https://preview.redd.it/qg13f679xqah1.png?width=2048&format=png&auto=webp&s=9a644aa63103d6a51865242358faf1c94c07daac

It's open source and self-hostable. You can test out the Agent Network using this one-liner:

curl -fsSL https://pkgs.netbird.io/getting-started.sh | NETBIRD_AGENT_NETWORK_ONLY=true bash

Already running NetBird? 

You don't redeploy anything. It ships in the same backend, so you flip one environment variable and it shows up in the left menu next to the reverse proxy. Set NETBIRD_AGENT_NETWORK_ENABLED=true to turn it on next to everything else, or NETBIRD_AGENT_NETWORK_ONLY=true if you'd rather have the stripped-down, Agent-Network-only dashboard instead. 

Don't want it at all? There's nothing to do, leave both unset and it stays off. The command above is really just the fast path for people coming purely for the LLM and agentic-access use case, we did this to prevent people coming for the Agent Network getting overwhelmed with our platform. 

We'd love feedback!

- Overview: https://docs.netbird.io/agent-network

- Quickstart: https://docs.netbird.io/agent-network/quickstart

- Interview with Misha: https://youtu.be/IFT-nTyLDro

- Demo video: https://www.youtube.com/watch?v=oqkcFI_3WAU

- Release Article: https://netbird.io/knowledge-hub/netbird-agent-network

The reverse proxy from v0.65 was all about exposing internal stuff to the public internet with auth in front. That's great for things you actually want reachable from anywhere. But a lot of internal tools (monitoring dashboards, wikis, admin panels) should never touch the public internet at all. You still want the nice parts of the proxy, the clean domain, automatic TLS, one place to manage everything. You just don't want a public endpoint sitting out there.

https://preview.redd.it/tr7xfjtybo5h1.png?width=1643&format=png&auto=webp&s=fca428f3cf48564451ef54a76e5a94a60012ca5c

That's what NetBird-Only access does. It's a new mode alongside SSO, password, and PIN. Flip a service to NetBird-Only and it stops being served publicly. The only way to reach it is from a peer inside your network, gated by group membership.

There's no login prompt and no credentials. The connecting peer's identity is the credential. A request comes in over the tunnel, the proxy resolves it back to a NetBird peer, and management checks the peer's groups against the access groups you set. Not in an allowed group, you get a 403. NetBird also synthesizes the DNS records and access policies for you, so no manual DNS entries and no hand-written policies.

https://preview.redd.it/sljiued2co5h1.png?width=2898&format=png&auto=webp&s=975c4dd64e5d22c92444d33333f9587e663b9b5c

Your backend even gets stamped with X-NetBird-User and X-NetBird-Groups headers so your apps know exactly who's connecting. Client-supplied versions get stripped first, so nobody can impersonate a user by setting the header themselves.

Do note: NetBird-Only requires a cluster with the Private capability, which a proxy reports when it runs with the --private flag (or NB_PROXY_PRIVATE=true). Cloud's shared clusters don't advertise it yet, so running your own BYOP cluster is the way to enable private services on Cloud. BYOP also got its full dashboard setup flow this release.

⚠️ Self-hosters: there's a required gRPC router change, plus the private flag to add if you want it. Full writeup here: https://netbird.io/knowledge-hub/netbird-only-private-services

Hey folks, we just published a new tutorial on getting NetBird running on PiKVM.

For those unfamiliar, PiKVM is an open-source KVM-over-IP project built on Raspberry Pi. It gives you full keyboard, video, and mouse control of a remote machine through a web browser. It's great for managing headless servers, debugging boot issues, or accessing BIOS when SSH is dead.

The tricky part is that PiKVM runs on a read-only filesystem to protect the SD card from corruption. NetBird needs to write auth state and WireGuard keys, so we walk through an overlayfs setup that keeps the read-only protections intact while giving NetBird a writable layer backed by RAM.

The tutorial covers:

• Building a DIY PiKVM (hardware list + OS flashing)
• Setting up the overlay filesystem
• Configuring the NetBird systemd service for PiKVM's constraints (journal logging, disabled SSH config writes, overlay dependency)
• Registering via setup key or SSO
• Persisting state across reboots
• Troubleshooting common issues

Once it's set up, you can access your PiKVM's web interface from anywhere on your NetBird network — no port forwarding needed.

Full tutorial: https://netbird.io/knowledge-hub/netbird-on-pikvm

Let us know if you run into any issues or have questions!