Skip to main content
boxd can serve your organization over NetBird, whether you use NetBird Cloud or run your own management server. Once enabled, your machines keep every name they already have (myapp.boxd.sh, subdomain proxies like api.myapp.boxd.sh, and your org’s wildcard domain) and the same TLS certificates. What changes is who can reach them. Those names now resolve and route only inside your NetBird network. This is enforced at boxd’s edge, well beyond hiding a DNS record. Someone who knows the public IP and your machine’s name gets the same 404 a nonexistent machine gets. HTTPS, SSH, and raw port forwards all move onto your NetBird network together. Management stays where it was. The CLI, console, SDKs, and boxd connect go through the boxd API, so they keep working from anywhere. It’s traffic to your machines that needs NetBird.

​
Set it up

NetBird runs per organization and the boxd team enables it together with you, so start by reaching out.
1

Reach out with a setup key

Send your org name and a setup key to contact@boxd.sh, or post them in the Slack channel you share with the boxd team. If you self-host NetBird, include your management URL too, such as https://netbird.example.com:443.Create the key in your NetBird dashboard under Setup Keys with Reusable on, no usage limit, and Ephemeral Peers off. Reusable matters because boxd registers one peer per edge server. Add an auto-assigned group such as boxd if you want the peers grouped for your access policies. The boxd team enables NetBird for the org and stores the key encrypted, so edge servers added later can register with it too.
2

Allow access

boxd’s edge servers appear in your network as peers named boxd-proxy-*. If you kept NetBird’s default policy that lets every peer reach every other, there is nothing to do. Otherwise, add an access policy that lets your users’ group reach the group the boxd peers are in, on all TCP ports.
3

Connect

Join your NetBird network on your laptop and use your machines exactly as before:
Off the network, the names stop resolving.

​
Good to know

  • Everyone needs to be on the network. DNS for your machines answers with the NetBird address only, so org members outside your NetBird network lose access to the hostnames. That is the point, but tell your organization before turning it on.
  • NetBird or Tailscale, not both. An organization is served over one private network at a time. To move from Tailscale to NetBird, the boxd team turns Tailscale off first.
  • Custom domains: org-wide only. Your org’s wildcard domain follows the network, because boxd serves its DNS. A per-machine domain can’t follow, because its apex A record lives in your own DNS zone pointing at boxd’s public IP. boxd machine domain add refuses the combination and names the conflict.
  • No device expiry to manage. Peers registered with a setup key aren’t subject to NetBird’s login expiration, so boxd’s peers stay connected without any change on your side.
  • Setup keys can expire. That only matters when boxd adds edge capacity, since an expired key means a new edge server can’t register. If a machine ever stops being reachable over NetBird, create a fresh key and send it over. Enabling again replaces the stored key.
  • Bot protection is off on the network. Only your NetBird network can reach the machines, so requests over it never get the bot protection check. Webhooks, API clients, and curl from inside the network wake a sleeping machine as before.
  • Turning it off. Ask the boxd team to disable it. Your machines return to the public path, and boxd’s peers are removed from your NetBird network.
If machine names resolve on one network and fail on another, check the local resolver. Some corporate and router DNS setups strip answers in NetBird’s 100.64.0.0/10 range as DNS-rebinding protection. Point your device at a resolver that keeps them, or use NetBird’s own DNS.