Tailscale vs. NetBird

Zero Trust mesh VPNs have gotten really good at making secure remote access boring, in the best possible way. Tailscale is probably the name most people know here, and for good reason. It hides a ton of the complexity that comes with a traditional VPN. But it isn't the right fit for everyone, and NetBird has shipped enough over the last two years that this comparison looks pretty different than it used to.

So what I want to do here is walk through how each one handles the stuff you actually deal with day to day. Access control, routing, DNS, SSH, exposing services, and so on. I'll call out where each one comes out ahead, because they both do in places.

Let's start with the overview and then dive into the details.

TL;DR: The Differences That Matter

Peer Management

Both handle the basics you'd expect. Editing, deleting, renaming, seeing status and IP address. Tailscale adds device approval and Tailnet Lock, which verifies new nodes before they're trusted, though do note that the two features are mutually exclusive. Device approval is on all plans, while Tailnet Lock is currently limited to Personal and Enterprise. Tailscale can also update supported clients automatically from the CLI, and its MDM profiles cover managed Windows and Apple deployments.

Peer permissions still live in the tailnet policy, but you don't have to hand-edit HuJSON for routine changes anymore. The visual policy editor now covers grants, groups, tags, tests, posture rules, SSH rules and auto approvers, with the underlying file still there for GitOps and advanced configuration.

NetBird does the same basics and also shows you the country a peer is connecting from. The whole thing is group based, so you're configuring groups rather than individual machines, which saves a lot of clicking once you're past a handful of peers. NetBird can also sync users and groups from your identity provider, so access policies can follow the structure you already manage there.

NetBird has closed most of the admin gap here over the past year or so. There's user approval , so you control whether someone can join the account and connect peers at all. Optional automatic client updates for Windows and macOS are in there too, off by default and with a configurable max version. You also get MDM configuration profile support for Windows Registry and macOS plist deployments, and the desktop client was rebuilt recently and now ships in ten languages.

Self-Hosted Option

This is the big one for a lot of people, so let's be precise about it.

Tailscale open sources the core client and its DERP relay server, but not the coordination server. The full clients are open source on open source operating systems, while the GUI wrappers for Windows, macOS and iOS are closed. The coordination server is theirs and it runs on their infrastructure.

You can point clients at a custom control server, which is how Headscale works, and Headscale is genuinely good for homelab and small networks. Do note that it's a community reimplementation rather than an officially supported Tailscale product, so you're leaning on a third-party project instead of the vendor, and it does not support every feature available in Tailscale's hosted service.

NetBird open sources both sides, the client and the coordination server, including the iOS and Android apps. You can self-host the entire stack, or use the managed cloud if you'd rather not. One licensing detail worth knowing: the management, relay, and signal components are licensed under AGPLv3, while the client uses the BSD-3-Clause license.

Self-hosting also got a lot easier recently with the embedded identity provider. It used to be that self-hosting meant standing up something like Zitadel alongside NetBird, which was easily the most tedious part of the whole setup. Now local users work out of the box with no external IdP at all, and you create and manage them right in the dashboard. There's a setup wizard for the first run, and if you do want an external provider you configure it from an Identity Providers tab in the UI instead of editing config files. Existing deployments kept working, and the old Zitadel quickstart is still there.

Network Architecture

Tailscale runs userspace WireGuard, specifically their own fork of wireguard-go. That's deliberate. It keeps behavior consistent across Linux, macOS, Windows and BSD, and it leaves room for their NAT traversal and policy layers. Userspace has historically cost you some throughput compared to the kernel module, but Tailscale has published some serious optimization work that closes most of that gap on Linux, so I wouldn't treat it as the knock it used to be.

NetBird can use either userspace or kernel WireGuard on Linux, so you get the portability of one and the raw performance of the other where it matters.

Two other things are worth knowing about. NetBird has its own WebSocket- or QUIC-based relay implementation, automatically selecting the best available option, and it also supports third-party TURN relays such as coturn. A peer can use the relay for a fast initial connection while it negotiates a direct path in the background. Separately, lazy connections mean the client doesn't build tunnels to every peer at startup, it sets them up on demand. That makes a real difference once your network is large and any given peer only ever talks to a few others. Tailscale follows a similar on-demand connection approach.

NetBird also has optional post-quantum cryptography through Rosenpass, which you turn on with or a toggle in the desktop app. It targets the harvest now, decrypt later problem, where someone records your traffic today and waits for a quantum computer to open it later. This is a genuine difference between the two. Tailscale's own documentation says their WireGuard implementation "is not post-quantum secure and does not use PSKs", and explains that WireGuard's deliberate avoidance of protocol agility makes it awkward to retrofit.

I don't want to oversell it though. Rosenpass in NetBird is still experimental, it isn't supported on mobile, and both ends of a connection have to enable it unless you run in permissive mode.

UI/UX and Usability

Tailscale isn't hard to use, but there is still a learning curve around its policy model. The admin console is clean, and the visual editor now handles most of the things that used to send you straight into HuJSON. The file is still the source of truth and remains useful for bulk changes, advanced settings and GitOps, but learning the syntax is no longer a prerequisite for normal administration.

NetBird leans hard on the UI. Setup and onboarding are quick and most day-to-day configuration is buttons and dropdowns. If you're newer to networking that's going to feel a lot friendlier. We'll get into where that tradeoff actually bites when we hit access control.

It's also worth mentioning NetBird's Control Center, which visualizes access relationships between peers, groups and resources. That makes it easier to see who can reach what without tracing policies manually.

Remote Server Access

Tailscale SSH brokers and authenticates connections for you, so there are no SSH keys to manage for those sessions. They've built on that with a browser-based SSH console in the admin panel and SSH session recording that can go to S3-compatible storage or local disk. Session recording is still in beta and is currently listed for Personal and Enterprise plans. Taildrop covers direct file transfer between devices, and RDP works over the tailnet like anything else.

NetBird approaches SSH from a different angle. Every peer can run a built-in SSH server, which you enable with , so you get an SSH endpoint without exposing port 22 to the internet. Sessions authenticate through your identity provider over OIDC by default, which means your audit trail records which user got into which machine rather than which key was presented.

The integration with existing tooling is nice. NetBird listens on TCP 22022 and quietly redirects port 22 traffic inside the NetBird network to it, so whatever you already do keeps working. The client also drops in a for OpenSSH, so plain , and all route through NetBird without you thinking about it. You get local and remote port forwarding, and caches tokens so you aren't re-authenticating constantly. If you'd rather have host-based trust, puts you back on the older machine identity model.

There's also fine-grained access control, so you can map NetBird users and groups to specific local OS accounts on the target machine. Sessions are fail-closed, meaning an unmapped user gets denied by default.

One gap I should be straight about: NetBird has no built-in device-to-device file transfer like Taildrop. You can reach SMB and other file servers across the network, and works fine over the SSH path above, but firing a file straight at another peer is still an open feature request.

Exposing Internal Services

Both can publish an internal service without opening inbound firewall ports, but they go about it differently, and this is probably the biggest gap that's opened up since 2024.

Tailscale splits the job in two. Serve publishes a local port, directory or file to the rest of your tailnet over HTTPS, and Funnel publishes it to the public internet. Both handle certificates automatically and both are available on every plan, which is great. The constraint is naming. Their docs are explicit that DNS names are "restricted to your tailnet's domain name ()", and that Funnel "can only use DNS names in your tailnet's domain". There's no serving under your own domain. Funnel also only listens on ports 443, 8443 and 10000, and there are bandwidth limits you can't configure.

NetBird went and built a full reverse proxy that you configure from the dashboard. Incoming traffic lands on a NetBird proxy cluster and then travels through the mesh to the target service, so your internal machines don't need public IP addresses or open inbound ports. Cloud deployments get a free auto-generated domain, but you can also point your own domain at the cluster with a CNAME record and NetBird handles the certificate. You can put SSO, a PIN, a password or header-based auth in front of a service, and you get access logs, path-based routing to multiple backend targets, and controls like host header passthrough and redirect rewriting.

It goes well past HTTP, too, with layer 4 support for TCP, UDP and TLS, plus access restrictions and session idle timeouts. CrowdSec IP reputation filtering is available when the selected proxy cluster has it configured. NetBird-only services are also limited to clusters advertising the capability. On NetBird Cloud that means running a bring your own proxy account cluster, while self-hosted deployments need a proxy running in embedded peer mode.

For anything ad hoc, there's a one-liner. An administrator has to enable Peer Expose first, and the resulting service is ephemeral, so it lasts only while the command is running. Publishing a local dev server is just:

And just like that it's behind the reverse proxy. The same command carries the protections you'd otherwise click through in the dashboard:

There are a few more flags for password protection (), naming () and the backend protocol (). It's the same basic idea as for quick sharing, with the difference that the result can sit on your own domain behind an auth gate.

So the practical split is who the service is for. Tailscale's version is great for sharing something quickly under a predictable tailnet name. NetBird's is aimed at publishing an internal app on your own hostname to people who may not run a client at all. Self-hosted deployments need a NetBird proxy instance for the data plane and Traefik in front of it for TLS passthrough.

Browser-Based Access

Both have shipped browser-based access built on WebAssembly, which I think is a genuinely cool bit of convergence.

Tailscale's SSH Console runs "the Tailscale client code, WireGuard®, a userspace networking stack, and an SSH client" right in the browser, and it's available on all plans. It's scoped pretty tightly though. SSH only, sessions have to start from the admin console rather than standalone, only Owner, Admin, IT admin and Network admin roles can use it, and all of the traffic goes over DERP relays instead of peer-to-peer. The feature is still in beta.

NetBird's Browser Client runs a NetBird peer as WebAssembly and covers both SSH and RDP with nothing to install. The RDP support is the main thing it adds over Tailscale's console.

There are two important caveats. You currently need an admin account to start a Browser Client session because NetBird creates a temporary peer and ACL rules for it, and browser connections are relay-only rather than direct peer-to-peer. So this is useful for administrators and support staff who already hold that role, but it isn't a general contractor portal yet. Both browser implementations are admin-oriented and relay-only today.

Access Control

Tailscale handles access control through a tailnet policy stored as HuJSON. They've put real work into making that approachable since 2024. The visual policy editor now covers grants, SSH rules, tests, groups, tags, posture, auto approvers and most other routine policy sections. You can switch between the visual and JSON editors, and GitOps workflows can review and apply the same policy through GitHub, GitLab or Bitbucket.

Tailscale has also introduced grants , which it now recommends over classic ACLs, and which push policy past network-layer IPs and ports into application-layer capabilities.

That's a solid policy-as-code story. It versions cleanly and it scales, while the visual editor means you don't need to know the syntax for normal administration. The policy model itself still takes some learning, and HuJSON remains the better fit for bulk edits and options that don't have a visual form.

NetBird goes the other direction with UI controls , so groups and policies are buttons and dropdown lists in the admin console. For a lot of teams that's simply faster, and it's much easier to hand off to someone who isn't deep in networking.

The advantages go past friendliness though. Groups are the unit of access rather than tag syntax, and because groups can sync from your identity provider, a policy you write once keeps tracking your org structure as people move between teams. Each policy carries its sources, destinations, protocol, ports and any posture checks in one place, so what you review in the console is what gets enforced, with no second file to keep in sync. If you do want automation, the same policies are reachable through the public API.

Seeing Who Can Reach What

Writing a policy is one problem. Understanding what it actually permits once it's grown is a different problem, and the two products answer it in different registers.

Tailscale gives you two answers here. Tests assert intended access and run before a policy change is saved, so a change that would quietly open or close a path fails instead of shipping. The Preview rules view is the more immediate option. You select a user and get a list of destinations they can reach, the rule responsible for that access, and the other users or groups covered by the same rule.

NetBird's answer is Control Center , which "visualizes who can access what across your environment. It maps Peers, Groups, and Networks to the resources they can reach and shows the access control policies that permit those connections." There are separate Peers, Users, Groups and Networks views, you can follow the policy path granting access to a resource when you're troubleshooting, and you can click a policy node to edit sources, destinations, protocols, ports and posture checks without leaving the graph. It's available on all NetBird Cloud plans and self-hosted, with editing limited to Admin and Network Admin roles.

So Tailscale is no longer code-only here. Its preview is list-based and tied closely to the policy, while NetBird gives you an interactive graph you can follow and edit. Tests catch regressions before they land, and a map is nicer for exploring the state you already have. Which one you prefer depends on whether your team reviews network policy like code or wants to navigate it visually.

Network Routes (subnet routing)

Configuring network routes in Tailscale typically takes a few steps across a few different tools. You enable IP forwarding on the subnet router device, advertise the subnet routes using the Tailscale CLI, approve them in the admin console, then update the access rules so peers can actually talk to the advertised subnets. Auto approvers can remove the manual approval step once you've configured them. It works, it's just spread across the device, console and policy system, so you need to understand each piece.

Tailscale has some genuinely good tooling around this. App connectors route traffic to specific SaaS domains rather than raw subnets, and 4via6 handles sites with overlapping IPv4 ranges, which is a genuine headache solver. They also support a Mullvad VPN add-on for exit nodes, which NetBird has no equivalent for. That one is licensed separately at $5 per month for every five devices.

NetBird takes a more UI-driven approach. Its Networks and Resources model lets you expose a single IP, a CIDR range, a domain or a wildcard domain as a resource, which makes least-privilege access practical. NetBird's own guidance is to prefer single-host resources over broad ranges. You assign a peer or peer group as the router and grant access with a resource policy, without advertising the route from the client CLI.

Multiple routing peers give you automatic failover, and equal-metric peers let clients choose the lower-latency path. Do note that disabling masquerade also disables high availability because the destination network has no way to return traffic through whichever peer takes over. Tailscale includes subnet router failover on all plans too, though its regional routing, which steers clients to the nearest of several overlapping routers, needs Premium or Enterprise.

The older NetBird Network Routes feature is now considered legacy and deprecated. Networks and Resources is the default for remote access and site-to-site connections, while legacy Routes remain necessary for exit nodes. Distribution groups still apply DNS configuration and legacy route configuration to groups of peers.

DNS Management

Tailscale's MagicDNS lets you reach devices by name instead of IP address and supports private DNS servers and split DNS. Pretty straightforward and it works well.

NetBird does the same, applied through distribution groups, and supports match domains so you can route queries to specific nameservers. That's handy for internal DNS that only internal servers can resolve.

NetBird went further with custom DNS zones , which let it host private DNS records itself rather than pointing at an external server. You create a zone like , add A, AAAA, CNAME and wildcard records, and distribute it to specific peer groups. Resolution happens locally on each peer and records propagate automatically as group membership changes.

Because distribution is group based, different teams can resolve different records for the same zone. That makes split-horizon setups and environment separation pretty simple, so production, staging and development each get their own zone visible only to the people who need it.

It pairs well with routed networks too. You can map friendly names onto private IPs sitting behind a routing peer and let NetBird handle both the name and the path to it, so your team hits instead of remembering .

User Authentication

Tailscale supports the popular SSO providers and MFA. Since 2024, SSO with any OIDC-compliant identity provider has been included on every plan, including the free Personal tier, which was a genuinely good move on their part. User and group provisioning with SCIM starts at the Standard plan at $8 per user per month. That tier also limits you to 10 ACL groups, so medium and large environments that need a more granular policy structure may have to move to a higher plan with larger group limits.

NetBird supports SSO and MFA with popular identity providers on the free plan. MFA there comes from the identity provider itself, so if you use Google, Microsoft or GitHub and have MFA configured, it carries over automatically. Advanced identity providers come in from the Team plan onward, and user and group provisioning is available at that same tier.

Activity Logging & Streaming

Tailscale separates configuration audit logging, which records what changed in your tailnet and who changed it, from network flow logging, which records node-to-node activity. Both can stream to a long list of destinations: Datadog, Splunk, Elasticsearch, Axiom, Cribl, Panther, Vector, Amazon S3 and S3-compatible stores, Google Cloud Storage and Azure Blob Storage, plus any SIEM that speaks Splunk HEC. That breadth is a real advantage. The one thing to budget for is that log streaming itself requires the Premium or Enterprise plan.

NetBird draws the same distinction with audit events for administrative changes and traffic events for network flows. Traffic events capture peer-to-peer, site-to-site and peer-to-resource connections along with source and destination IPs, ports, protocols and the policy that allowed the connection.

The list of streaming targets is narrower, covering Datadog, AWS S3 and Amazon Data Firehose, but there's a generic HTTP endpoint integration that will POST each event as JSON to any URL you want, which in practice covers most SIEMs. One limit to know about: streaming audit and traffic events needs the Business plan on NetBird Cloud, or a commercial license if you self-host.

EDR Integration and Posture Checks

Tailscale's device posture support has broadened well past a single vendor. Built-in attributes cover the operating system and version, client version and release track, whether auto-update is on, and whether client state is encrypted at rest. From the Standard plan up you also get the country and public address a device connects from. On top of that it integrates with CrowdStrike Falcon, SentinelOne, 1Password XAM, Fleet, Huntress, Iru (formerly Kandji), Jamf Pro and Microsoft Intune. Third-party integrations need the Standard plan or above, and custom posture attributes are Premium and Enterprise only.

Posture rules use conditions on individual grants or a baseline in the underlying policy. You can configure them through the visual editor now, while HuJSON remains available when you want the policy reviewed and versioned as code.

NetBird has expanded here too and now integrates with CrowdStrike Falcon, FleetDM, Huntress, Microsoft Intune and SentinelOne Singularity . In each case NetBird syncs the vendor's managed device list and checks the agent is present and compliant, blocking network access when it isn't. You configure it through the UI or the API with distribution groups rather than a policy file. Do note these integrations are cloud only.

Alongside the vendor integrations, NetBird supports device posture checks for NetBird client version, operating system, running processes, peer network range, and country and region.

Both cover this well at this point. Tailscale supports a longer list of endpoint vendors, including Jamf Pro and 1Password XAM, which matters a lot if you already run one of those. NetBird covers the most common ones and keeps the whole workflow in the UI, with the same settings available through the API. It's less a capability gap than a question of whether you want the policy file to remain an explicit part of the workflow or would rather configure this in the console.

Governing Access for AI Agents

This is the newest front for both of them, and what's interesting is they landed on very similar answers. Both focus on keyless access: an identity-aware gateway sits in front of LLM providers, so there's no need to distribute API keys to users or agents, and every request can be tied back to a specific identity.

Tailscale's is Aperture , which sits alongside the tailnet as a separate product rather than part of it. It gives you a centralized inventory and ties access to identity instead of keys, routing to upstream providers like OpenAI, Anthropic, Google, AWS Bedrock, Vertex, Microsoft Foundry, OpenRouter and Vercel AI Gateway. It can also proxy self-hosted OpenAI-compatible models. Policies control which models each identity can call, with token and request rate limits per agent, per team or across the org, plus spend caps.

Every interaction gets logged with the caller's identity, model, provider, timestamp and token count. Retention is configurable all the way down to zero for full request and response capture, S3-compatible export is supported, and a pre-call hook system can strip or block PII before requests go upstream. Aperture also has connectors for MCP servers and HTTP APIs, with credential injection and identity-based grants for the tools each user or agent can call. It's self-serve, and currently free with six users included per instance.

NetBird's is Agent Network , built on top of the reverse proxy and private services above, so the transport is still the WireGuard overlay and the identity model is still your IdP. Agents point at a tunnel-only endpoint instead of the provider's URL, NetBird injects the upstream key server-side, and client-supplied auth headers get stripped before forwarding so a hardcoded key never reaches the provider. It's default deny, meaning a policy has to connect a source group to a provider before anything flows. Limits cover token and USD budget caps per user and per group, with account-wide global limits that can only tighten a policy, never loosen it. Guardrails include a model allowlist, optional prompt capture and PII redaction on captured logs, and per-request accounting records identity, provider, model, tokens and cost.

Two differences stand out. NetBird has more named presets for third-party AI gateways, including LiteLLM, Portkey, Bifrost and Cloudflare AI Gateway alongside Vercel AI Gateway and OpenRouter. Both products support custom OpenAI-compatible endpoints and self-hosted models, including Ollama and vLLM on your own GPU boxes. When NetBird forwards to LiteLLM it passes the calling identity along too.

NetBird also documents the client side. Claude Code and the Codex CLI are drop-in: you point them at your Agent Network endpoint instead of the provider's, and the coding agent on a developer's laptop then holds no API key at all, while NetBird authorizes each request against your policies and injects the credential server-side. On the upstream side there are named integrations for AWS Bedrock, Google Vertex AI, Kimi, LiteLLM and vLLM, so managed models and models on your own hardware are governed through the same policy.

NetBird's bigger architectural advantage is that Agent Network is part of the same open source network stack you can run yourself. It extends the same identity and policy model to internal resources, so databases and internal APIs an agent needs are reachable peer-to-peer over WireGuard with no proxy in the path. Aperture's advantage is its connector layer for governing MCP tools and authenticated HTTP APIs.

How you get the gateway differs for now. Aperture is delivered as a hosted service to Tailscale users, while Agent Network is self-hosted, with NetBird Cloud support arriving at the end of August. Once that lands, neither one requires you to operate the gateway yourself, and the decision goes back to the architectural split above: connector breadth on one side, one policy layer over models and private resources on the other.

Managing Multiple Tenants

If you run networks on behalf of other organizations, whether you're an MSP, an MSSP, or an internal team with strictly separated business units, you need more than one isolated network under one roof.

Tailscale supports multiple tailnets within a single organization sharing one identity provider. Each tailnet keeps its own policy file, tags, devices and settings, and you can assign different owners and admins per tailnet. There's an API for creating tailnets programmatically, which suits companies embedding Tailscale into their own product with a tailnet per customer. The caveat is maturity. It's in alpha, and creating multiple tailnets means contacting their sales team.

NetBird ships a dedicated MSP Portal built for exactly this. It's multi-tenant by design, so you manage customer accounts from one place and configure each tenant's network settings, billing and access much like you would your own. There's a tiered partner program alongside it if you want a commercial relationship too. The MSP Portal is a cloud feature.

Pricing Model Differences

Tailscale's exit nodes and subnet routers are on all plans, and so is failover for highly available routes. The free Personal plan is intended for non-commercial use and covers up to 6 users, unlimited user devices and 50 tagged resources. Tagged resources include shared infrastructure like servers, subnet routers and app connectors, with additional tagged resources billed at $1 each per month.

For a business deployment, the entry point is Standard at $8 per user per month, which adds SCIM provisioning, third-party posture integrations, up to 10 ACL groups and managed deployment features. Premium at $18 per user per month adds regional routing, network flow logs, log streaming and priority support. Enterprise-level support and custom SLAs are Enterprise only.

NetBird gives you highly available routes and exit nodes on every plan including the free tier, which covers up to 5 users and 100 machines and is positioned for individuals or small teams. The Team plan at $6 per active user per month adds unlimited users, SSO and MFA with an enterprise IdP, SCIM provisioning and audit logging. The Business plan at $12 per active user per month adds device approvals, MDM and EDR controls, posture checks, traffic events and event streaming. Both paid plans start with 100 machines plus 10 for each paid user, with additional active machines at $0.50 per month. Enterprise support is on the Enterprise plan.

Both put SSO and highly available routing within reach, but the free plans are not a straight one-to-one comparison. Tailscale Personal is for non-commercial use, while NetBird describes its free tier as suitable for individuals or small teams. For a business, the more useful comparison is Tailscale Standard at $8 per user against NetBird Team at $6 per active user, along with the different machine and tagged-resource allowances.

Tailscale vs. NetBird: Which One Should You Use?

Both of these are good products. They both give you Zero Trust security, Kubernetes support, a WireGuard data plane and reasonable free tiers, and honestly you'd do fine with either for a lot of use cases.

Both have also moved fast since this article first went up. Tailscale made SSO with any identity provider free on every plan, put subnet router failover on all tiers, grew its posture integrations to eight endpoint vendors, shipped a full visual policy editor and permission preview, added a browser-based SSH console, and launched Aperture with MCP and HTTP connectors. NetBird has put out dozens of releases in the same window, rewriting SSH around identity-provider authentication and adding a built-in reverse proxy, a WebAssembly browser client covering SSH and RDP, custom private DNS zones, an embedded identity provider that drops the external IdP requirement for self-hosting, Control Center, an MSP Portal, and Agent Network.

What strikes me is how much they've converged. Both now do browser-based access built on WebAssembly, and both answered the AI agent question with an identity-aware gateway that holds provider keys server-side and meters usage per identity. If you're picking between them on those two things alone, they're closer than the release notes make it look.

The differences that actually last are architectural. Tailscale keeps a versionable policy file with tests, GitOps workflows and grants, while its visual editor now makes that system much more approachable. That's a real strength if your team wants network policy reviewed like any other code. NetBird is UI-driven, adds Control Center for exploring the effective policy as a graph, keeps a kernel WireGuard path on Linux, and is open source across both the client and the coordination server. You can self-host the whole thing without depending on a third-party reimplementation. Tailscale has advantages in a few specific spots, notably Taildrop, SSH session recording, MCP connectors and the breadth of its log streaming destinations.

The clearest split is how each one handles access without a full client deployment. Tailscale can share individual nodes with people outside your tailnet, but those users still install Tailscale, and public Funnel services stay under a tailnet-owned name. NetBird's reverse proxy can put an internal application on your own hostname behind SSO, a password, a PIN or header authentication with no client installed. The Browser Client removes the install for SSH and RDP too, although it is still admin-only and relay-only today. If customers or occasional users need browser access to internal services, the reverse proxy difference matters more than any single row in the table above.

With all that, NetBird is the stronger fit for teams that want a UI-driven experience, a visual map of effective access, custom-domain service publishing, and one identity and policy layer across people, machines, networks and AI agents. NetBird Cloud delivers that as a managed service, while the fully open source stack gives you a supported self-hosting path when you need it. Tailscale still wins in a few mature areas, but those NetBird advantages are structural, not little checklist extras.

The NetBird Cloud free plan covers 5 users and 100 machines if you want to poke at it, and the complete self-hosted stack is open source. Have a great one.