1. Pilae
2. Apps
3. NetBird

Running NetBird in production: what it takes

1. Deploy the control plane on PostgreSQL

   Management, signal and relay, pinned to a version we have run, on PostgreSQL rather than the default SQLite files, audit log included. The relay runs as its own service. The control plane is published through the gate on port 443, with UDP 3478 open for STUN.

2. Sign-on and groups from your directory

   People sign in only through Keycloak or Entra ID, with groups read from the token. Peer session expiration makes each laptop enrolled through sign-on re-authenticate on a schedule, so a disabled account stops connecting at the next expiry.

3. Keep policies in Git

   Groups, policies, routes, DNS and posture checks are Terraform in your repository. We never create a group by hand with the name of a directory group, because NetBird will not sync a group whose name is already taken.

4. Restore under the same hostname

   The database, the data directory and config.yaml, which holds the store encryption key, go offsite daily, encrypted. Once a month we restore them into a scratch environment under the same hostname and check that peers, policies and setup keys are there.

5. Upgrade without dropping tunnels

   Direct connections do not pass through the server, so they survive its restart, and the separate relay keeps relayed ones up. An upgrade is tried on a copy first and applied by the Pilae Agent in your window once you approve it. Client updates roll out separately, through your MDM or package repository.

What NetBird is, and who runs it

NetBird system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory

2 vCPU · 4 GBUpstream asks for one CPU and 2 GB at least. Management and signal carry no user traffic, so they grow with peers and policy changes rather than bandwidth. The relay carries only the connections that cannot go direct.

Database

PostgreSQLHolds peers, groups, policies and setup keys. We point the audit log at it too, which otherwise stays in a SQLite file of its own. SQLite cannot be shared by a second management instance and is backed up by stopping the server.

Public ports

TCP 443 · UDP 3478Laptops and phones reach the management server before they are on any private network, so it is published through the gate on 443. The gate passes the client address on, so country checks see the device and not the gate. STUN needs UDP 3478, which no HTTP proxy can carry.

Identity provider

OIDCKeycloak, Entra ID or any OIDC provider, with groups in the token. Entra ID sends group object IDs rather than names, and drops the claim for a user in more than 200 groups, so only the groups NetBird needs are assigned to it. SCIM provisioning needs the commercial licence.

DNS and TLS

2 hostnamesOne for the management server, kept for life: every client is enrolled against it, and a restored server is only found again under the same name. One for the relay, whose address clients learn from the server.

Migrating from Tailscale to NetBird

Tailscale and NetBird are built the same way: WireGuard tunnels between devices, a coordination service that hands out public keys and policy, and relays for the connections that cannot go direct. The move changes who runs the coordination service. Nothing carries across on its own. Every device gets the NetBird client and enrols again, which for laptops is a software deployment through your MDM rather than a visit to each desk. NetBird has no official importer for the tailnet policy file, so each rule, tag, subnet router and exit node is rewritten as NetBird groups, policies and routes. That rewrite is where the time goes, and it is where rules nobody can explain any more are removed rather than copied.

1. Rewrite the policy file as code

   ACLs or grants, tags, subnet routers and exit nodes become NetBird groups, policies, routing peers and exit nodes in Terraform, reviewed rule by rule against what the old policy actually allowed.

2. Check the address range, then connect sign-on

   Tailscale and NetBird both draw addresses from 100.64.0.0/10. We check the NetBird range against the addresses in use before the first device joins, because changing it later re-addresses every peer. Then we connect Keycloak or Entra ID.

3. Enrol servers, then people

   Servers join with one-off setup keys that place them in their groups. Laptops get the client and your management URL through your MDM on Windows and macOS. Phones are pointed at your server from the app settings and sign in through your IdP.

4. Take Tailscale off each machine

   On Linux, a leftover Tailscale firewall rule can drop traffic from the shared address block that arrives on any other interface, NetBird traffic included. So the old client is removed and its rules checked machine by machine. The subscription ends when the last device has moved.

NetBird access policy, written as Terraform

# access/finance.tf in the acme repository (excerpt)
data "netbird_group" "finance" {
  # Entra ID sends the group's object ID in the groups claim, not its name
  name = "5d3c9a8e-1f2b-4c7d-9e6a-0b8f2d4c1a37"
}

resource "netbird_group" "erp" {
  name = "erp"
}

resource "netbird_network_resource" "erp_web" {
  network_id = netbird_network.datacentre.id
  name       = "erp-web"
  address    = "erp.acme.internal"
  groups     = [netbird_group.erp.id]
  enabled    = true
}

resource "netbird_posture_check" "managed_laptop" {
  name = "managed-laptop"

  os_version_check {
    darwin_min_version         = "14.0"
    windows_min_kernel_version = "10.0.22631"
  }

  geo_location_check {
    action    = "allow"
    locations = [{ country_code = "CH" }, { country_code = "FR" }]
  }
}

resource "netbird_policy" "finance_to_erp" {
  name                  = "finance to erp"
  enabled               = true
  source_posture_checks = [netbird_posture_check.managed_laptop.id]

  rule {
    name          = "https only"
    action        = "accept"
    bidirectional = false
    enabled       = true
    protocol      = "tcp"
    ports         = ["443"]
    sources       = [data.netbird_group.finance.id]
    destinations  = [netbird_group.erp.id]
  }
}

What Pilae is responsible for

Where it runs

zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware

Who holds the credentials

You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.

If you leave

The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running NetBird

Pricing is on request: a fixed price for onboarding, then a monthly price for NetBird, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size

The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.

High availability

One machine with tested restores, or a replicated setup that keeps serving when a node fails.

Storage and backups

How much data it holds, how long backups are kept, and point-in-time recovery for its database.

Plan and support

Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.

Region

Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.

Sign-on and integrations

Single sign-on, directory sync, mail relays and the other systems the app has to reach.

NetBird: common questions

Also in engineering and security