When NetBird Cloud fits and when self-hosted NetBird fits
Choose NetBird Cloud when your team wants the access network and its policies without running servers, a public domain or the upkeep that comes with them, and when a per-user, per-machine subscription fits your budget model. Choose self-hosted NetBird when data residency rules, internal policy or contract terms require the management, signal, relay and dashboard stack to run inside your own infrastructure, or when you already operate an identity provider and have staff to own backups and upgrades. Both models run the same overlay network and access control concepts, so the decision is mainly about who operates the control plane and where its data lives.
Start with residency and identity. If your regulator, customer contracts or internal rules restrict where network metadata, user records and access logs may be stored, confirm with NetBird where cloud-hosted data sits before you assume the managed plan qualifies. Self-hosting keeps that data in your environment. Identity matters just as much: the Team and Business tiers on the pricing page add SSO, MFA and SCIM with an enterprise identity provider, while a self-hosted deployment ships with an embedded Dex provider that can be extended with external SSO. If your identity provider is already authoritative and you want SCIM-driven lifecycle, check that the external connection you need is supported in the edition you plan to run.
The AGPLv3 license applies to the management, signal and relay components, so a self-hosted operator who modifies and offers those components over a network must meet its source obligations. The cloud plans are priced per active user and per machine, so costs grow with headcount and device count, and the pricing page notes that billing counts only active users and machines. Before you commit, get a written quote for your user and machine numbers, and ask NetBird which features your edition includes. Self-hosting trades that subscription for staff time: the quickstart requires a Linux VM, a public domain, TCP ports 80 and 443, UDP port 3478 and Docker with the Compose plugin, and NetBird states that operators own backups, upgrades and scaling. Assign those tasks an owner before you choose self-hosting.
How the two models differ on features, cost and control
This table sets NetBird's published cloud plans against running the stack yourself, row by row across data location, identity, plan features, price, licensing and operations. Read the feature rows against the pricing page first, then confirm anything it does not list before you decide which model fits your controls.
| Factor | NetBird Cloud | Self-hosted NetBird |
|---|---|---|
| Data location and control | Managed by NetBird; confirm the hosting region and data residency terms in writing before you commit | Runs in your own VM or cloud account, so you choose where management, signal, relay and dashboard data live |
| Identity provider options | SSO and MFA with an enterprise identity provider on Team and above, per the pricing page | Embedded Dex can add external SSO such as Google, Microsoft or Okta, so you configure the provider and its lifecycle |
| SCIM provisioning | Listed on the Team plan | Confirm with NetBird whether SCIM is available in your self-hosted setup and which release supports it |
| Audit event logging | Listed on the Team plan | Available as a feature, but you own storage, retention and export of the logs |
| Device approvals, MDM and EDR controls | Listed on the Business plan | Not listed on the self-hosting quickstart; confirm availability and parity with NetBird before planning |
| Posture checks and traffic logging | Listed on the Business plan | Confirm which posture and traffic logging capabilities apply to your self-hosted build |
| Published price and limits | Free for up to 5 users and 100 machines; Team at 6 euros and Business at 12 euros per user per month, with extra machines at 0.50 euros, per NetBird pricing | No license fee for the self-hosted software under BSD-3-Clause and AGPLv3; you pay for the VM, domain, staff time and any support you buy |
| Who handles backups and upgrades | NetBird operates the service | You do, according to NetBird's documentation, including scaling |
| Licensing | Subscription to a managed service; the plan terms govern use | Management, signal and relay code is under AGPLv3, so review the obligations with counsel if you modify it |
| Minimum infrastructure | None on your side; no servers or domain needed | Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP 80 and 443, UDP 3478, and Docker with Compose |
What runs in your environment under each model
In the managed model, NetBird operates the control plane: the management and coordination services that distribute peer configuration and access policy, along with the dashboard you use to manage them. You do not provision a server, a domain or a reverse proxy. Your devices still form a WireGuard overlay, and peer traffic is encrypted between endpoints, with relay fallback used when a direct path cannot be established. Your organization's coordination data, group membership and policy definitions sit with the vendor, and your identity data is handled through the identity provider you connect.
- Control plane location: NetBird runs management and coordination for you, so the operational boundary for those services is the vendor's, not your data center.
- Peer traffic: Encrypted WireGuard traffic flows between your endpoints. Ask NetBird where relay servers sit and whether relayed traffic has any different handling from direct traffic.
- Identity: Users authenticate through an SSO or MFA provider you connect, which the pricing page ties to its Team plan and above.
- Operational work: Backups, upgrades and scaling of the control plane are handled by NetBird, which keeps your team's runbook shorter.
- Plan limits: Plan limits on users and machines apply, and billing counts only active users and machines.
Before you commit, confirm in writing where coordination and log data are stored, which regions relays use and what contractual terms apply to access to your tenant.
When you self-host, you run management, signal, relay and STUN from one combined configuration, along with the dashboard container. A Traefik reverse proxy handles TLS, with Let's Encrypt as the default certificate source, and the stack includes an embedded Dex identity provider. Every component that coordinates peers and stores policy now sits inside your infrastructure, so the trust boundary moves to your own hosts, cloud account and operators. Peer traffic still runs over WireGuard, but the coordination and identity services that broker it are yours to secure and patch.
- Components: Management, signal, relay and STUN share one configuration, and the dashboard runs as its own container behind Traefik.
- Quickstart footprint: The quickstart calls for a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443, UDP port 3478 and Docker with the Compose plugin.
- Certificates: Traefik requests Let's Encrypt certificates by default, so confirm that outbound issuance is permitted in your network or replace the default with your own certificate process.
- Data custody: Coordination data, policy and logs stay on hosts you control, which matters for data residency and for incident response scope.
- Ownership of operations: NetBird's documentation states that you handle backups, upgrades and scaling yourself.
Before you deploy, check the self-hosting quickstart against your network rules and confirm which ports your firewall policy must open.
The trust boundary question is the same for every model: who can read or change coordination data, who can see identity assertions, and who can reach relayed traffic. Peer traffic is encrypted end to end over WireGuard, so the relay operator should not be able to read payload contents. Coordination data, which holds peer identities, group membership and access rules, is the sensitive part. Identity data depends on whether the identity provider is external or the embedded Dex instance, and the answer changes your audit evidence and your incident scope.
- Peer traffic: Encrypted between endpoints under WireGuard, whether the path is direct or relayed.
- Coordination data: Holds the peer map and access policy. In the cloud model this sits with NetBird, and in the self-hosted model it sits with you.
- Identity data: Under the cloud model it flows through the SSO provider you connect. Under self-hosting it flows through your chosen provider or the embedded Dex service.
- Logs and events: Activity and traffic event logs are stored where the control plane runs, so retention and access control are shaped by the same boundary.
- Key material: Confirm how WireGuard keys and setup keys are generated, rotated and revoked under each model.
Ask NetBird to document each boundary in writing so your security team can map it to your own data classification.
The self-hosted stack includes an embedded Dex identity provider. NetBird's quickstart states that Dex can add external SSO providers, and it names Google, Microsoft and Okta as examples. Using an external provider keeps user lifecycle and credential policy with your existing identity team, while Dex handles the connection to NetBird. Confirm which connector your provider needs, how group claims are mapped to NetBird groups and how deprovisioning reaches the mesh, because a disabled account in the upstream provider should lose access without manual cleanup.
- Google: Named in the quickstart as an external provider Dex can add.
- Microsoft: Named in the quickstart as an external provider Dex can add, and often the natural choice where Entra ID already governs staff access.
- Okta: Named in the quickstart as an external provider Dex can add.
- Group mapping: Decide whether groups come from the provider or are managed inside NetBird, because that decision drives your access policy design.
- Offboarding: Test that disabling a user upstream removes their peer access, and document the time it takes.
The quickstart does not give a full list of supported connectors, so confirm the exact connector and version with NetBird before you commit to a provider.
Self-hosting moves recurring work onto your team. Because NetBird's documentation assigns backups, upgrades and scaling to the operator, you need a plan for backing up the management data, testing restores, applying releases and watching the health of the combined stack. Each release is published on NetBird's GitHub releases page, so your team needs a process for reading release notes and scheduling upgrades. The cloud model removes this work, but it also removes your direct control over timing.
- Backups: Define what must be backed up, where copies live and how a restore is tested.
- Upgrades: Plan a change window for the combined stack, and test the dashboard and proxy together.
- Scaling: Size the VM against your user and peer count, and watch relay load as traffic grows.
- Monitoring: Alert on certificate renewal, container health and relay availability.
- Skills: Your team needs Docker, Compose and reverse proxy operation skills in-house or under a support arrangement.
For a quote, ask who performs each of these tasks, what happens during an outage of the coordination services and how a support retainer would cover upgrades.
Data location, access control and compliance implications
Moving NetBird from the managed cloud to your own servers changes who holds the coordination data, the admin accounts and the logs. Each card below is a decision or check that follows from that shift, and most of them need an answer from NetBird or your own environment before you sign.
Where coordination and log data sits
Coordination data, peer records, policies and activity logs live wherever the management service runs. On NetBird Cloud, that is NetBird's infrastructure. Self-hosted, it is the Linux VM you provision, its Docker volumes and any backups you take. Ask NetBird for the exact cloud data location and where support access terminates, and confirm your own host's region and disk encryption against your data residency rules.
Who holds administrative access
On the cloud plan, NetBird operates the control plane and you manage tenants through the dashboard. Self-hosted, your team holds root on the VM, the Docker host, the reverse proxy and the database, so every one of those becomes an administrative path. Document who can reach the host, how those credentials are rotated and whether break-glass access is logged outside the NetBird dashboard.
SSO and MFA configuration
Team and Business plans add SSO and MFA with an enterprise identity provider and SCIM provisioning, according to NetBird's pricing page. Self-hosted, login runs through the embedded Dex identity provider, which can add external SSO providers such as Google, Microsoft or Okta. Confirm which MFA method applies to each path, how SCIM deprovisioning reaches both deployments and what happens to access if your IdP is down.
Audit and activity logging
NetBird lists activity and traffic event logging, and Team plans include audit event logging, while traffic logging and streaming sit on Business. Self-hosted, you decide where those events are shipped, how long they are retained and who can read them. Check whether the log export and retention you need exist on your chosen plan, and test that a sample event reaches your SIEM before relying on it as audit evidence.
AGPLv3 obligations for modified server code
NetBird's management, signal, relay and combined directories are licensed under AGPLv3, while the rest of the repository is BSD-3-Clause. If you modify that server code and make it available to users over a network, the AGPLv3 requires you to offer those modifications to them. Get legal review before patching the server, and keep client changes separate, since the client directories fall under the permissive license.
Compliance evidence and certifications
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Before you assume NetBird Cloud carries any certification your framework requires, ask NetBird directly for its current certifications and data processing terms, then map those against the controls your own environment must still evidence.
What your team runs and maintains in each model
This table lists the recurring work of running NetBird yourself against the managed NetBird Cloud plans, and marks which items the cloud removes and which stay with your team. Read each row as a question to answer for your own environment before choosing a model. The main takeaway is that self-hosting moves the operational load for the whole stack onto your team, not only the initial install.
| Operational item | NetBird Cloud | Self-hosted NetBird |
|---|---|---|
| Servers and host sizing | Removed: NetBird runs the infrastructure | Remains: a Linux VM with at least 1 CPU and 2 GB of memory per the quickstart, sized up as peers grow |
| Public domain and DNS | Removed: no domain needed | Remains: you own a public domain for the management endpoint |
| Network ports | Removed: no inbound ports to manage | Remains: TCP 80 and 443 and UDP 3478 must be open and kept open through firewall changes |
| Container runtime | Removed | Remains: Docker with the Compose plugin, patched and monitored |
| TLS certificate renewal | Removed | Remains: the default Traefik setup uses Let's Encrypt, so confirm renewal works and alerts fire on failure |
| Identity provider configuration | Partly removed: SSO and MFA are plan features | Remains: the embedded Dex provider or an external SSO provider must be configured and maintained |
| Backups and restore tests | Removed: handled by NetBird | Remains: back up configuration and data, and test restores on a schedule |
| Upgrades across releases | Removed: NetBird deploys updates | Remains: plan and test each release, such as the v0.81 line, before rolling it out |
| Scaling | Removed: capacity is NetBird's responsibility | Remains: scale the combined management, signal and relay components as peer count grows |
| Monitoring and on-call | Removed for the service itself | Remains: alerting, log review and out-of-hours response are your responsibility |
What drives the cost of each model
The cloud bill is metered by people and machines, and the published rates are the easiest part to model. 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, and custom Enterprise pricing. Business includes 100 machines, with 10 per user, and extra machines are 0.50 euros each. Billing counts only active users and machines, so the number to model is the peak active headcount and device count across a billing period, not the number of seats on an org chart. Before you sign, confirm with NetBird how inactive users and machines are counted, whether Team's SSO and SCIM features are priced differently from Business's device controls, and what Enterprise adds in writing. Check the current page at NetBird pricing because published rates change.
Self-hosting moves the bill from a vendor invoice to your own budget, and most of it recurs. The infrastructure is a Linux VM that meets the quickstart minimum of 1 CPU and 2 GB of memory, plus a public domain, open TCP 80 and 443 and UDP 3478, and Docker with the Compose plugin. The larger costs are staff time for the combined management, signal, relay and STUN stack, the dashboard, Traefik and the embedded Dex identity provider, plus backup storage for the management database and configuration, and the upgrade work that NetBird's documentation assigns to the operator. Costs rise with the number of sites, the number of relays you run, the frequency of upgrades you test, and any external SSO you add. Ask any implementation partner for a written scope that lists each component, who patches it, the backup retention you need, and the recovery test you will run. Those items, not the software license, set the real cost of the self-hosted option.
DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for the components in scope, the environment they run in, the number of users and machines to be supported, the identity provider integration, the backup and restore testing, the upgrade approach, and the ongoing support model, which can be a retainer or a one-off handover. Also ask which items are one-time work, such as the initial deployment and identity integration, and which recur, such as upgrades, monitoring and support. Compare the self-hosted quote against the cloud invoice over the same period, including your own internal staff time, which the quote will not cover.
Moving between NetBird Cloud and self-hosted NetBird
This sequence moves users, groups, access policies, setup keys, routes and enrolled devices from one NetBird model to the other, and ends with a checked cutover. Several steps depend on your identity provider and on which features each plan or self-hosted build includes, so confirm those points before you start.
Inventory identity and network objects
Before either move, the administrator who owns the current environment lists every user, group, access policy, setup key, route, exit node and private DNS setting, and records which identity provider signs in each user. This step depends on your identity provider: group membership and SSO mappings only carry over cleanly if the new environment connects to the same provider with the same group names. Ask NetBird to confirm which of these objects it can export or import for your plan and version, and treat any object without a confirmed path as a manual rebuild. Output: a written inventory with one named owner for each item.
Prepare the target environment
For cloud to self-hosted, provision 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, following the self-hosting quickstart. Self-hosted deployments embed Dex, which can add external SSO providers such as Google, Microsoft or Okta, so decide which provider you will use. For self-hosted to cloud, confirm the plan that covers your needs, because SSO with an enterprise identity provider and SCIM provisioning are listed on Team, while device approvals, posture checks and traffic logging are listed on Business. Assign owners for backups, upgrades and scaling before data arrives. Output: a reachable target with an agreed owner for every ongoing task.
Rebuild groups, policies and routes
Recreate the inventoried groups, access policies, network routes, exit nodes and private DNS in the target, in dependency order: groups first, then the policies that reference them, then the routes those policies depend on. Where the path confirmed in the first step does not cover an object, rebuild it by hand and record the source setting beside the new one. If you manage configuration through the public API, the Terraform provider or the Ansible collection, keep the definitions in version control so the rebuild can be repeated. This step depends on your identity provider: confirm that group names and SCIM mappings match the new provider before any policy depends on them. Output: a target configuration that matches the inventory, with every difference explained.
Issue setup keys and re-enroll devices
Create setup keys in the target for each device group, then enroll each client again on its platform, such as Linux, macOS, Windows, Android or iOS. Plan each device as a fresh enrollment in the target, and confirm with NetBird how existing peers are handled during any migration before you retire the source. Users who sign in with SSO should authenticate through the target identity provider during enrollment, so test that path with one account from each group first. Output: a device list in the target that matches the source inventory, with no unexplained gaps.
Validate access before cutover
Test from a representative set of users and devices that covers each group, each policy, each route and each exit node, and check results in both the target dashboard and its activity logs. Confirm that SSO and MFA prompts reach the intended provider, that posture checks and device approvals behave as your plan requires, and that SSH access follows the central policy. Record pass or fail for each test case, and hold the cutover until failing cases are fixed or formally accepted by the system owner. Output: a test record that names the tester, the date and each open exception.
Cut over users and close the source
Announce the window to users, move the remaining devices, and update any DNS entries, bookmarks or documentation that point to the old environment. Keep the source available for an agreed period so the team can compare logs and roll back if needed, and confirm with NetBird how long the source remains accessible before you close it. Retire setup keys and any remaining enrollment paths in the source. Output: all users and devices active in the target, with the source closed and the change recorded.
Document the new operating model
Record who now owns the work that moved with the environment. In a self-hosted setup, that includes backups, upgrades and scaling, which NetBird's documentation says the operator handles. In NetBird Cloud, record who manages plan changes and user counts, since billing counts only active users and machines. Note which identity provider settings, SCIM mappings and API or Terraform definitions must be reviewed after any change. Output: a short runbook that a new administrator can follow without the migration team.
Questions buyers ask before choosing a hosting model
How much does self-hosting NetBird cost compared with the published plans?
Self-hosting replaces the per-user subscription with your own hosting bill and staff time, so the comparison is between the plan prices and the costs you carry yourself. NetBird's pricing page lists Team at 6 euros and Business at 12 euros per user per month, with Business including 100 machines plus 10 per user, extra machines at 0.50 euros, and billing that counts only active users and machines. The published pricing covers the managed plans only, so ask NetBird about any self-hosted licensing terms before you build a budget. The self-hosting quickstart needs a Linux VM with at least 1 CPU and 2 GB of memory, so the infrastructure line is usually modest. The larger recurring cost is the people time for backups, upgrades and scaling, which you should cost in hours per month before comparing totals.
How long does the initial self-hosted NetBird deployment take?
The duration depends mainly on how quickly your team can meet the network and DNS prerequisites and how much identity work sits on top of the base install. The quickstart requires a public domain, TCP ports 80 and 443 and UDP port 3478 open, and Docker with the Compose plugin on a Linux host. Let's Encrypt certificates, which the default Traefik proxy requests, depend on the domain resolving and the ports being reachable. Time also grows with the number of peers, routes and access groups you migrate, and with the external SSO provider you connect through the embedded Dex. No supplied figure gives a duration, so ask for a timeline in writing. DeployOpen agrees scope, deliverables and timelines in writing before fixed-scope work starts.
What skills does a team need to run self-hosted NetBird?
The team needs working knowledge of Linux server administration, Docker and the Compose plugin, DNS and TLS certificates, and reverse proxy configuration. The default deployment uses a Traefik reverse proxy with Let's Encrypt, a combined management, signal, relay and STUN configuration, and a dashboard container, so someone must be able to read and change those files safely. Identity work needs OpenID Connect knowledge if you connect Google, Microsoft or Okta through Dex. Operators also need a tested backup and restore routine and a repeatable upgrade process. Day-to-day network policy work, such as groups, rules and posture checks, is closer to the skills of a network or security administrator. Check these skills against your staff before committing to self-hosting.
Can one engineer run the NetBird quickstart alone?
One engineer with the prerequisites in place can usually stand up a test instance by following the documented quickstart. Running the same deployment for production is a different job, because it needs cover for backups, upgrades, monitoring and incident response when that engineer is unavailable. NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves, so the responsibility stays with your team. Before you rely on a single person, document the host, the domain, the DNS records, the secrets and the identity provider settings, and run a restore test. If your team lacks that depth or cover, DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under fixed scope or an ongoing retainer.
What ongoing backup and upgrade work does self-hosted NetBird need?
The recurring work covers backing up the management data and configuration, testing restores, tracking new releases, and applying upgrades in a controlled order. NetBird's releases are published on GitHub, with v0.81.0 released on October 15, 2026 and v0.81.2 on October 16, 2026, so release tracking is a steady task rather than a one-off. Each upgrade should be rehearsed in a staging copy that mirrors your domain, proxy, identity provider and client mix, because clients, dashboard and server components must stay compatible. Confirm with NetBird which volumes and files hold state in the combined deployment, since that determines what a backup must capture. Build a written schedule for backups, restore tests and upgrade windows before you go live.
Can SSO be configured through Dex or an external identity provider in self-hosted NetBird?
Yes, the self-hosted deployment includes an embedded Dex identity provider, and Dex can add external SSO providers such as Google, Microsoft or Okta. That makes the self-hosted path workable for SSO, but the connector steps, redirect URLs and claims mapping must be checked against your provider's current documentation. On NetBird Cloud, the pricing page places SSO and MFA with an enterprise identity provider, plus SCIM provisioning and audit event logging, in the Team plan. Before you assume the same provisioning features exist in your self-hosted setup, confirm with NetBird which SCIM and MFA capabilities the self-hosted build provides. Test sign-in, group mapping and a user removal end to end in staging before you cut over.
How do I move from NetBird Cloud to self-hosted NetBird, or back?
Plan the move as a rebuild of identity, policy and peer enrollment rather than a simple data copy, since the supplied facts do not describe an automated migration path between the two models. Ask NetBird in writing whether any export or import option exists and which items it covers. Expect to recreate groups, access rules, SSO connections, DNS records and setup keys, and to re-enroll peers on the new management server. The public API, the Terraform provider and the Ansible collection can help you record and reapply configuration as code, which reduces the manual work in either direction. Schedule a parallel run before cutover, and agree the migration scope in writing with whoever will carry it out, whether that is your team or DeployOpen.
Questions to answer before you pick a model
Start with where the control plane is allowed to live. Before comparing plans, confirm whether your data residency rules and contracts permit account, device and traffic metadata to sit with NetBird Cloud. Self-hosting keeps the management, signal, relay and dashboard components in your own cloud account or data center, and that choice often settles the question for regulated teams. Check your data processing agreements, your sector's residency expectations and whether your auditors expect the vendor's contract to cover the managed service. Then decide who inside your organization signs off on that answer, because the outcome changes which quote you ask for.
Map identity provider constraints next, then count users and machines. Self-hosted NetBird uses an embedded Dex identity provider that can add external SSO providers such as Google, Microsoft or Okta, so list which provider is authoritative and whether you need SCIM provisioning. On NetBird's pricing page, SSO and MFA with an enterprise identity provider and SCIM sit in the Team tier, and device approvals, MDM and EDR controls, posture checks and traffic logging sit in Business, so write down which of those features are mandatory. Then count active users and machines, since billing counts only active users and machines and the Free tier stops at 5 users and 100 machines. Confirm the current limits and any overage terms on the pricing page before you rely on them.
Check operations capacity and the AGPLv3 position. Self-hosting makes your team responsible for backups, upgrades and scaling, as NetBird's documentation states, so name the people who will own those tasks and their on-call coverage. Ask whether you can staff a regular upgrade cadence against the NetBird GitHub release stream. Finally, if your engineers plan to modify code in the management, signal, relay or combined directories, which NetBird licenses under AGPLv3 while the rest of the repository is BSD-3-Clause, involve legal counsel before you start. Modifications to those components may carry source-sharing obligations for networked use, so decide that question before a patch reaches production.
How DeployOpen scopes and supports self-hosted NetBird
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For NetBird, that means working out whether a self-hosted control plane is worth running in your environment, then building and handing over the parts that come with it.
How we scope
- Scope is agreed in writing before work starts, covering deployment targets, identity provider choice and access policy design.
- We confirm which management, signal, relay, dashboard and reverse proxy components run in your environment and where each one lives.
- The written scope names backup, upgrade and monitoring responsibilities so ownership of the self-hosted stack is clear before quoting.
How we build
- We install the self-hosted quickstart components against your domain, network rules and Linux hosts, with TCP 80, 443 and UDP 3478 reviewed.
- We configure SSO through the embedded Dex provider or an external identity provider, and document group and access rule mappings.
- We test client enrollment, relay fallback, posture checks and access policies across the operating systems your teams actually use.
How we hand over
- Deliverables include configuration documentation, runbooks for backup, restore and version upgrades, and a record of decisions made.
- We walk your operators through routine tasks such as adding users, rotating setup keys and reviewing activity and traffic logs.
- Handover material is written so your platform team can run the stack without DeployOpen, if that is the chosen model.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial implementation.
- Upgrade work follows the NetBird release notes, and we test changes in a staging environment before production rollout.
- Ask any partner to confirm in writing which quote items cover monitoring, incident response and version support windows.
