NetBird vs OpenZiti: which to choose

NetBird vs OpenZiti: when each one fits

Choose NetBird when the main need is private network reachability between people, servers and networks, with one admin console deciding who can reach what. Its clients run on a wide range of operating systems and network appliances, including pfSense, OPNsense, MikroTik RouterOS and TrueNAS, so existing hosts can join the overlay without code changes. The access model is built around groups, rules, SSO and MFA, device posture checks and SSH policies, which suits teams whose controls are applied at the device and network layer. Before committing, confirm which of these checks your identity provider and plan tier support, because the pricing page ties SCIM provisioning, device approvals and posture checks to different paid tiers.

Choose OpenZiti when access must be decided per service or per application, and when you can place an SDK or tunneler next to most of the workloads you need to protect. Its *dark services* have no listening ports, the controller issues x509 identities to every participant, and revoking access terminates active connections immediately. Three deployment models can be mixed: network access through an edge router, host access with a tunneler beside the service, and application access with an embedded SDK. The extra effort is real: every workload that needs the strongest guarantees needs an SDK or tunneler, and someone must run the controller and the edge routers as a mesh that you own.

The decision turns on three questions. First, is the control point the network path or the individual application? Second, how many workloads can take an SDK or tunneler, and how many are closed vendor appliances that cannot? Third, who will operate the controller, the routers and the upgrades, and do they have the time for it? Ask both vendors for a written reference architecture for your environment, run a pilot against one service in each design, and confirm the operating model before you commit. Because NetBird and OpenZiti use different license terms and different control planes, also check the licensing and support obligations that apply to your deployment.

Which platform fits which scenario

This table maps common scenarios to the platform that usually fits better, with the condition that tips the balance. Read each row against your own network, device mix and application ownership, since the right answer often depends on whether you control the application code.

Scenario	Better fit	Condition that decides it
Remote staff reaching internal servers and tools	NetBird	Staff use laptops and phones on the supported client list, and access is per user or group with SSO, MFA and posture checks. Confirm the device types you need against NetBird's client list.
Site-to-site connectivity across a mixed device fleet	NetBird	Many endpoints run Linux, Windows, macOS, mobile or network appliances such as pfSense, OPNsense, MikroTik or OpenWRT. Its client coverage makes a single overlay easier to roll out.
Exposing a legacy service without opening inbound ports	OpenZiti	The service can run a tunneler beside it, or sit behind a private router that only makes outbound connections. Dark services with no open ports fit this case directly.
Embedding identity and encryption in a custom application	OpenZiti	You own the application code and can add an SDK for Go, C, Python, Node.js, Java, Swift or C#. Traffic is then encrypted application to application, which a network overlay alone does not provide.
Locking down a SaaS-facing or partner-facing API	OpenZiti	The API is served by your own code, so an embedded SDK or host-side tunneler can enforce identity per call. Confirm the integration effort with your application team before committing.
Adding a device-posture gate to an existing employee network	NetBird	You need posture checks, activity logs and central SSH policies across many machines. Check which posture and logging features require the Business plan on NetBird's pricing page.

How NetBird and OpenZiti are built and deployed

NetBird and OpenZiti both separate a management plane from the traffic path, but they place that split in different spots. NetBird bundles its control services into one self-hosted stack, while OpenZiti spreads routing across edge routers and puts services behind outbound-only connections. The cards below cover what each design means for patching, scaling and recovery.

NetBird combined control services

A self-hosted NetBird deployment runs management, signal, relay and STUN from one combined configuration rather than as separate services. That makes the stack simple to stand up, but every control component shares one upgrade and restore cycle. Ask how a single-host failure affects peer coordination, and whether relay capacity can be added without touching management.

NetBird dashboard, Traefik and Dex

The self-hosted stack includes a dashboard container, a Traefik reverse proxy that obtains Let's Encrypt certificates by default, and an embedded Dex identity provider. Dex can add external SSO providers such as Google, Microsoft or Okta. Confirm which identity provider your team will use before go-live, since moving users between an embedded Dex and an enterprise provider is an integration task you own.

NetBird quickstart requirements

The quickstart calls for a Linux virtual machine with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443 open, UDP port 3478 open and Docker with the Compose plugin. NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves. Plan a tested restore of the management data and a recurring upgrade window from day one.

OpenZiti controller as management plane

The OpenZiti controller issues and verifies x509 identities for every participant, defines which identities reach which services through which edge routers, and exposes a REST API and web admin console. Because the controller holds identity and policy state, its backup, certificate lifecycle and access to the admin API are the recovery priorities. Ask your team who can change service policies and how those changes are logged.

OpenZiti public and private edge routers

Public edge routers are entry points reachable from the internet, while private routers inside private networks make only outbound connections, so no inbound firewall rules are needed there. This forms a mesh data plane that you can scale by adding routers in each zone. Check how many public routers you need for your regions, and whether private routers can reach their controller across your segmentation boundaries.

Three OpenZiti deployment models

OpenZiti offers network access through an edge router in a trusted zone, host access with a tunneler beside the service, and application access with an embedded SDK and no listening ports. The models can be mixed in one estate, so a legacy server may use a tunneler while a new service embeds the SDK. Each model moves the patching burden: routers and tunnelers are infrastructure to maintain, while SDK changes ship inside your application release.

Dark services and outbound connections

OpenZiti services can be dark, with no open ports, because the service or its tunneler connects outbound to an edge router. Revoking access terminates active connections immediately, which simplifies incident response. The trade-off is that every consuming client must run an OpenZiti identity and tunneler or SDK, so confirm client coverage for each platform on your list before committing.

Capabilities side by side from the published facts

This table compares NetBird and OpenZiti on the capabilities the published sources document, so you can see where each one is confirmed and where you need to ask the vendor. Read a cell as a fact from the source, or as a prompt to verify in a pilot before you commit.

Capability	NetBird	OpenZiti
Core license	BSD-3-Clause for most of the repository, AGPLv3 for management, signal, relay and combined directories	Apache 2.0, created and sponsored by NetFoundry
Access control model	Groups and rules for access control, with a centralized control plane	Identity-based policy: controller issues x509 identities and defines which identities reach which services through which edge routers
Device posture checks	Listed in the README; Business tier on the pricing page. Confirm the checks offered on your tier	Not listed in the sources reviewed. Confirm with the vendor before assuming posture-based policy
SSO and MFA	Listed; Team tier on the pricing page adds SSO and MFA with an enterprise identity provider	Not covered in the sources reviewed. Confirm how identity providers integrate with your environment
SCIM provisioning	Listed on the Team tier of the pricing page	Not covered in the sources reviewed. Confirm with the vendor
SSH access policies	Listed in the README as SSH with central access policies	Not covered in the sources reviewed. Confirm whether it applies to your use case
Public API and infrastructure as code	Public API, Terraform provider and Ansible collection listed in the README	REST API and web admin console listed. Confirm Terraform or Ansible tooling
Client platforms	Linux, macOS, Windows, Android, iOS, FreeBSD, pfSense, OPNsense, MikroTik RouterOS, OpenWRT, Synology, TrueNAS, Proxmox, Raspberry Pi and others	Tunnelers for Linux, Windows, macOS, iOS and Android; SDKs for Go, C, Python, Node.js, Java, Swift and C#
Dark services (no open ports)	Not a stated feature in the README. Confirm how inbound access is handled in your network	Supported: services can be dark, with the service or tunneler connecting outbound to an edge router
Encryption scope	WireGuard overlay between peers, with relay fallback when a direct path is not possible	With SDKs, end to end between applications using libsodium and mTLS; with tunnelers, tunneler to tunneler
Managed offering	NetBird Cloud, with plans listed on the pricing page; Enterprise pricing is custom	NetFoundry offers a managed, globally distributed network with SLAs and enterprise support; confirm terms directly

Licensing and paid editions for each platform

NetBird's code is licensed under two terms. Most of the NetBird LICENSE file applies BSD-3-Clause, a permissive license that allows use, modification and redistribution with light conditions. The management, signal, relay and combined directories are licensed under AGPLv3, and those are the components that form the control plane of a self-hosted deployment. Copyright is held by NetBird GmbH and individual authors.

Permissive client side: BSD-3-Clause covers the code outside the four server directories, so packaging clients for internal fleets and maintaining local forks of that code carries fewer obligations.
Copyleft control plane: AGPLv3 applies to management, signal, relay and the combined directories. If you modify these components and let users interact with the modified service over a network, the AGPLv3 source offer obligations apply.
Unmodified internal use: Running the published server components without changes is a different position from patching them, so record exactly which builds you run and whether any patches exist.
Contributor terms: Because NetBird GmbH and individual authors hold copyright, ask whether any contributor agreement or commercial licensing terms apply if you plan to upstream changes.

Before you patch the management or relay code, have counsel review how AGPLv3 applies to your internal and external use.

What drives the running cost of each platform

NetBird and OpenZiti are priced and staffed in very different ways. NetBird Cloud bills per user and per machine, while self-hosting moves hosting, upgrades and backups onto your team. OpenZiti is open source with no published per-seat fee, so its cost sits mostly in the people who design services, policies and client rollout.

Infrastructure and hosting

Self-hosted NetBird needs 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. Your cloud or data center bill recurs every month, and relays add traffic when peers cannot connect directly. OpenZiti needs controllers and edge routers sized for your service count and traffic, with public routers reachable from the internet. Ask each vendor, or your DeployOpen scope, to size both for your peak connections.

Operator skills and staffing

Self-hosted NetBird documentation states that operators handle backups, upgrades and scaling themselves, so someone on your team owns that work every month. OpenZiti asks for a different skill set: policy design, service modeling, certificate and identity lifecycle, and SDK work inside applications. Check whether your staff can run these tasks in-house or whether you need a retainer. Recurring hours are usually the largest line item in a self-hosted model.

Endpoints and workloads

NetBird Cloud bills by active user and machine, so cost grows with every laptop, server, router or NAS you enroll. OpenZiti's per-identity and per-service model means the cost driver is the number of services, routers and enrolled identities, not seats. Application access through an embedded SDK requires code changes in each application, which is one-time engineering work that recurs when you add new services. Count endpoints and workloads separately in your quote request.

Identity provider integration

NetBird lists SSO and MFA with an enterprise identity provider on its Team plan and SCIM provisioning, and self-hosted deployments can add external SSO providers such as Google, Microsoft or Okta. OpenZiti authenticates participants with x509 identities that its controller issues, so you must plan how your directory maps to those identities and how enrollment and revocation run. Integration effort is mostly one-time, but identity lifecycle changes recur with every joiner and leaver.

Upgrades, patching and backups

NetBird's current release is v0.81.2, published on October 16, 2026, and OpenZiti's latest non-prerelease 2.0 release is v2.0.6, published on September 17, 2026. Each upgrade cycle, patching of clients and routers, and backup testing recur on your schedule in self-hosted models. Ask whether the vendor's managed tier or your DeployOpen retainer covers upgrades, and what the change window and rollback plan look like in writing.

Support options and paid tiers

NetBird's cloud pricing 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's pricing page. OpenZiti is Apache 2.0 licensed, and NetFoundry offers a managed network with SLAs and enterprise support as a separate option. Billing counts only active users and machines, so ask vendors how they count idle devices. DeployOpen does not publish prices. A quote follows from written scope, so request line items for implementation, retainer hours, testing and any vendor subscription separately.

Where implementation projects run long

The schedule risk for NetBird sits mostly outside the overlay itself. A self-hosted deployment needs a public domain, TCP ports 80 and 443 and UDP port 3478 open, and a Docker host with the Compose plugin, and the bundled Traefik reverse proxy with Let's Encrypt is the default path. Teams that already run a reverse proxy, a certificate process or a DNS team often lose time agreeing who owns those pieces. The identity provider step is the next common slip: the embedded Dex provider can be extended with external SSO, but group mapping and the rule design (which groups reach which peers, and through which posture checks) need a named owner who can sign off on access policy before devices are enrolled. Device rollout then tends to expand with each platform added, since the client list spans Linux, Windows, macOS, mobile, NAS and router hardware. Confirm in writing who approves access policy, which device classes are in scope for the first wave, and who handles backups and upgrades after handover, because the self-hosting documentation assigns those tasks to the operator.

The schedule risk for OpenZiti is more often architectural and developer-dependent. Controller and router placement comes first: the controller holds identity and policy, public edge routers must be reachable from the internet, and private routers only make outbound connections, so the network team has to agree where each sits before anything else is built. Identity enrollment for every user, device and service is the next gate, and tunneler rollout on Linux, Windows, macOS, iOS and Android has to be scheduled per device class. Where the goal is application-level access through the SDKs (Go, C, Python, Node.js, Java, Swift and C#), the work moves into application code and needs developer time from the teams that own those applications, which is frequently the longest item and the one most often left out of an initial estimate. Undocumented application flows, such as which services call which, or which legacy clients cannot be changed, are the usual cause of slip. Before signing a fixed-scope agreement, confirm the list of applications and their owners, which access mode applies to each (network, host or SDK), and whether the developers who will change code are available inside the timeline.

Moving from one platform to the other

This sequence shows how to move access from NetBird to OpenZiti, or back, without losing track of who can reach what. It ends with a verified cutover and a decommissioned source platform, and it works the same way in either direction.

Inventory users, devices, services and policies
The team that owns network access lists every user group, enrolled device, reachable host and access rule in the current platform. For NetBird that means groups, access policies, routes to external networks, setup keys and any SSH policies. For OpenZiti it means identities, services, service policies and the edge routers that carry them. Each item gets an owner and a note on the business purpose it serves. The inventory is complete when every active rule maps to a named service or host and nothing is left as an untracked exception.
Map what transfers and what must be rebuilt
Separate the items that carry over from the items that do not. Identity sources, group structure and the documented access rules usually transfer as written decisions, but they must be re-expressed in the other platform's objects. Overlay membership, routing, tunneler enrollment and any application changes to embed the OpenZiti SDK are rebuilt, not copied. Ask the vendor or your implementation partner to confirm which import or API paths exist in your versions, because a configuration export from one product is not a native import into the other. The output is a signed mapping sheet listing each item as transfer, rebuild or retire.
Build the target environment and identity links
Stand up the target platform in parallel, without routing any production traffic through it. Connect it to the same identity provider so that user identity and group membership match what the source platform uses. For NetBird, confirm the SSO and MFA setup on the self-hosted or cloud deployment. For OpenZiti, confirm the controller, public and private edge routers and the certificate and identity issuance process. The check that closes this step is a test identity from each group that authenticates on the target and is denied services outside its mapped policy.
Rebuild services and enroll test endpoints
Recreate each mapped service on the target platform, starting with the lowest-risk internal host. For network-level access, enroll a test device with the tunneler or client and confirm it reaches the service. For application-level access, plan the SDK integration as a code change owned by the application team, with its own review and test cycle. Record which services need no change and which need code or configuration work. This step closes when each rebuilt service has a passing reachability test and a documented owner, and the team can show the same test failing for an identity that should be denied.
Run both platforms in parallel
Keep the source platform active while selected user groups use the target for a defined set of services. Compare logs from both platforms for the same access attempts, including denials, and resolve each mismatch by fixing the mapping or the rule. The security team reviews audit output for the period, and the operations team tests failure paths such as edge router outage or revoked identity. The period ends when every in-scope access pattern produces the same allow and deny results on both sides, and the open mismatch list is empty or formally accepted by the risk owner. Ask your partner how the parallel period is scoped in the written plan, since its length depends on your environment.
Cut over services and verify revocation
Move each service group to the target in a controlled change window, one group at a time. After each move, confirm that access works for intended users and that revoking one identity on the target ends its active sessions as expected. For OpenZiti dark services, confirm that no inbound ports are opened on the protected host during the change. For NetBird, confirm that peers no longer reach the moved services through the old policies. The step closes with a signed cutover record per group that lists the test results and the rollback path used if a check failed.
Decommission the source platform
Once every service has moved and the rollback window closes, remove the source platform's policies, enrolled peers, setup keys and API tokens. Archive the final configuration, audit logs and the mapping sheet according to your retention rules, and confirm that recovery needs are covered by the archive. Remove the source platform's identity links and dashboard access. The sequence is complete when the source platform no longer carries any active rule, the archive is verified, and the change record shows which owner approved shutdown.

Questions buyers ask before choosing or hiring help

What drives the cost of running NetBird or OpenZiti yourself?

Software licensing is only part of the bill, because the larger costs are your team's time and your infrastructure. For NetBird, the self-hosting quickstart lists 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. Ongoing work includes backups, upgrades and scaling, which NetBird's documentation assigns to the self-hosting operator. For OpenZiti, the controller, edge routers and tunnelers or SDK integrations are the components you run, and the effort grows with the number of services and applications you bring under the overlay. Ask any vendor, including NetFoundry for its managed network, for written pricing and support terms, and confirm the hosting footprint for your own environment.

How long does a typical NetBird or OpenZiti implementation take?

No researched duration is available for either platform, so treat any number you hear as a guess until it is tied to a written scope. The main factors are the number of peers and clients, the device platforms you need to cover, whether you use SSO and posture checks, how many services you publish, and whether you add routes to external networks. A network access rollout for a few hosts is a different job from moving many applications to SDK-based access. Ask for a scope document that lists each component, integration and test, then compare timelines against that list rather than against headline figures.

What does the implementation need from our own team?

Your team must supply decisions and access, even when an outside partner does the build. Expect to name an identity provider owner, decide which groups and access rules map to real roles, and provide the cloud or data center accounts, DNS control and firewall changes. For OpenZiti, application teams may need to change code if they adopt SDKs, which requires developer time and a release plan. Ask whether the work includes documentation, handover sessions and test evidence, and confirm which tasks remain with your staff after go-live.

Can one engineer run NetBird or OpenZiti in production?

A single engineer can often operate a small NetBird deployment, but you should confirm this against your own risk profile and on-call needs. NetBird's self-hosted model means one team owns the management, signal, relay, dashboard and reverse proxy components, along with backups and upgrades. OpenZiti adds controller, edge router and identity lifecycle work, and its dark services depend on correct policy and router placement. Without a second person who can restore, upgrade and revoke access, the platform becomes a single point of failure. Ask your vendor or partner for the runbook, the upgrade path and the minimum staffing they expect.

Is application-level zero trust worth the extra development work?

It is worth the work when the application itself must authenticate and encrypt each connection, and when you cannot place a tunneler beside the service or expose a network segment. OpenZiti's SDKs embed identity and encryption in the application, and its three deployment models can be mixed, so you can start with network or host access and move selected services to SDK access later. If your main goal is secure access for staff to internal tools and networks, NetBird's overlay with posture checks may cover the need with less development effort. Test one critical service against each model before you commit, and record the code changes, testing and release effort that the SDK path adds.

Does DeployOpen provide a fixed-scope quote for this work?

Yes, most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. To get a comparable quote, ask for the list of components, the target environment, the number of peers and services, the device platforms, the integrations with your identity provider, the testing and documentation you expect, and the handover plan. Ongoing support, upgrades and continuous testing are available as retainers and can be quoted separately. DeployOpen does not issue audit reports or certifications, so any compliance readiness work is prepared for independent assessors.

What recurring costs should we expect after go-live?

Recurring costs fall into three groups: the infrastructure you run, the time your team spends on upkeep, and any subscriptions or support contracts. For NetBird Cloud, published plan prices apply, with Free for up to 5 users and 100 machines, Team at 6 euros and Business at 12 euros per user per month, and billing that counts only active users and machines. Self-hosted NetBird has no published subscription in the supplied facts, so confirm any commercial terms with NetBird. For OpenZiti, NetFoundry offers a managed network with SLAs and enterprise support, and you should confirm its terms directly. Budget for upgrades, certificate renewals and periodic access reviews in every model.

How DeployOpen helps choose, implement or migrate

DeployOpen helps teams decide whether a NetBird overlay, an OpenZiti application-level network, or a mix of both fits their access requirements. We plan, implement, harden, document and support the chosen platform inside your own cloud accounts, data centers or air-gapped networks.

How we scope

We start by mapping which hosts, services and users need network reach and which need application-level access.
The written scope names the client types, platforms and identity provider that the deployment must cover.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen platform in your environment, including the management, relay and identity components it needs.
We configure access policies, posture checks or service definitions based on the groups and roles agreed in scope.
We run security testing against the deployed access paths, including checks that dark services stay unreachable without authorization.

How we hand over

We document the architecture, policies, backup procedures and upgrade steps so your team can operate the platform.
We deliver evidence of configuration and access controls that your compliance assessors can review, without issuing any attestation ourselves.
We walk your operators through daily administration, including adding users, devices and services and revoking access.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades for NetBird or OpenZiti, with changes tested before they reach production.
Support scope is agreed in writing, so you know which platform changes, incidents and tests are covered.

NetBird vs OpenZiti