Open source zero trust access for distributed engineering teams

For regulated or data-sensitive teams, running the control plane in your own cloud account is the common choice, because you keep the coordination server, signal, relay and logs under your control. NetBird's self-hosting quickstart runs management, signal, relay and STUN from one combined configuration, with a dashboard container, a Traefik reverse proxy with Let's Encrypt by default, and an embedded Dex identity provider that can add external SSO providers. The minimum host it lists is a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443 and UDP port 3478 open, and Docker with the Compose plugin. Confirm the sizing for your user and device count with your architect, since the quickstart describes a starting point, not a capacity plan.

Place relays close to where most engineers and workloads are, and keep them reachable on the ports the overlay needs. NetBird uses peer-to-peer WireGuard connections where it can and falls back to relays when direct paths fail, so relay placement mainly affects the connections that cannot go direct, such as those behind strict NAT. A relay in a region far from your users adds latency to every fallback path. Measure how often traffic relays in your environment before adding relays, and confirm with the vendor how relay traffic is encrypted end to end.

An exit node is a peer that forwards another peer's internet-bound traffic, so you can route engineer egress through a company-controlled network path. NetBird supports exit nodes as part of its overlay feature set, alongside routes to external networks and private DNS. Use exit nodes when you need one egress point for logging, allow-listing or geographic control, and remember that every exit node adds bandwidth load and a single point of failure. Put at least two in separate availability zones if the team depends on them, and confirm how each exit node is patched.

A subnet router is an overlay peer inside a private network that advertises routes to that network, so enrolled engineers can reach databases and internal services without a public IP on each resource. NetBird supports routes to external networks, which is the mechanism to use for VPC or data center subnets. Limit each router to the subnets it needs, give it a dedicated role in your access policy, and check that security groups allow traffic only from the router. Confirm the failover model before relying on one router for production database access.

Yes, if the platform exposes an API or infrastructure provider, and NetBird lists a public API, a Terraform provider and an Ansible collection among its features. Managing groups, access rules and setup keys as code gives you review through pull requests, change history and a repeatable rebuild of the control plane. Plan for drift between the console and code, decide which team owns the state file, and store setup keys in a secrets manager rather than in the repository. Confirm which resources the provider covers for your version before writing the module.

Your team does, when you self-host. NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves, while NetBird Cloud is the managed version that needs no servers or domain. That means you need an owner for the VM or containers, a tested restore procedure for the management database and configuration, a schedule for applying releases, and monitoring for the relay and signal services. Ask a partner to write those runbooks and test a restore before go-live, and agree in writing who is on call for control plane incidents.

The cost is driven by the number of people and machines that connect, the number of internal targets they reach, how many identity sources you integrate, and how much device posture work you take on. The software itself is often free to download, so most of the spend goes to infrastructure, integration, migration and the people who run it. Ask any quote to break those components out separately: control plane hosting, relay or gateway capacity, identity provider integration, policy design per application, device posture checks, and documentation and handover. Each of these grows with scope, so a team of 20 engineers reaching three staging environments is a very different job from 200 people reaching production databases from unmanaged laptops.

NetBird's pricing page lists Free for up to 5 users and 100 machines, Team at 6 euros and Business at 12 euros per user per month with 100 machines plus 10 per user and extra machines at 0.50 euros, and custom Enterprise pricing, according to NetBird pricing. Billing counts only active users and machines. Team adds SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging. Business adds device approvals, MDM and EDR device controls, posture checks and traffic logging and streaming. These are list prices for NetBird Cloud, so confirm current terms on the pricing page before budgeting, and remember that a self-hosted deployment replaces the per-user subscription with your own hosting and operations effort.

Recurring costs are the ones you pay every month or every release cycle, whether or not anything breaks. For a self-hosted NetBird deployment, NetBird's documentation says operators handle backups, upgrades and scaling themselves, so those tasks recur. The main items are virtual machine or cloud hosting for the management, signal, relay and dashboard components, a public domain and certificate renewal, identity provider licensing if your IdP is commercial, and time spent on patching and release upgrades. Add on-call coverage for access outages, because a broken control plane can block every engineer at once. Ask the implementation partner to quote these as a monthly run cost with a named owner for each item.

Often yes for a small, well-scoped deployment, but the answer depends on the skills you already have. A team that runs Linux, Docker, reverse proxies, TLS certificates and an identity provider can usually operate a single-region overlay with a clear runbook. The harder parts are policy design across SSO groups, posture signals from managed devices, migration app by app from an existing VPN, and tested recovery when the control plane fails. Note that the Headscale README says its project is aimed at self-hosters and small open-source organizations, so it fits smaller teams differently than a commercial-grade overlay. Assess your staffing against those tasks, and use a fixed-scope partner engagement if you want a documented handover.

The length of a pilot depends on how many apps are in scope, how clean your SSO groups are, and whether devices already have a management agent that can report posture. A pilot limited to one staging environment and a small group of volunteer engineers moves much faster than one that covers production databases, SSH and internal tools at once. Before agreeing a timeline, ask the partner to list the apps, protocols and identity sources in scope, the success criteria for the pilot, and the rollback plan if the overlay blocks a release. Written scope and a dated plan should replace any generic estimate, because no published duration applies to every environment.

An overlay such as NetBird controls which devices can reach which networks, but it does not, by itself, record privileged sessions or require approval for each administrative action. A privileged access management tool becomes necessary when you must record and review administrator sessions to databases or servers, enforce just-in-time elevation, or give auditors per-session evidence. Compliance drivers include the audit controls in the HIPAA Security Rule at 45 CFR 164.312 and the monitoring and logging duty in the FTC Safeguards Rule at 16 CFR 314.4. Many teams use both: the overlay for network reachability and a PAM tool for the database and root sessions inside it. Confirm the exact evidence your framework requires before choosing.

Ask for a written scope that lists every user group, device type, application, protocol and identity source covered, with each deliverable named. The quote should separate one-time work (design, integration, migration, documentation, handover) from recurring work (hosting, upgrades, monitoring, support). Ask which components the partner will hand over to your team and which they will keep operating under a retainer. Request the assumptions behind the effort, such as how many policies exist today and what happens when an app is out of scope. DeployOpen does not publish a price list, and a quote follows from that written scope.