TL;DR
The open-source-vs-managed decision for Zero Trust Network Access is not ideological. It is a matter of matching the delivery model to your constraints: engineering capacity, compliance scope, data-sovereignty requirements, scale, and customisation needs. Open source wins when you have platform engineering capacity, need full control, or operate under strict sovereignty rules. Managed wins when you need features fast, want compliance attestations bundled, have a small team, or cannot budget for self-host operations. The total-cost break-even is typically between 20 and 60 users — below that managed is cheaper, above it open source often is. This post gives a structured decision framework that makes the choice explicit, with the four serious options on each side of the line.
Who this is for
Security leads, platform engineers, and CTOs making a build-vs-buy decision for Zero Trust Network Access. This post assumes familiarity with the ZTNA product category and with at least one of the named open-source or managed products; see our ZTNA fundamentals coverage if you want a product-level primer.
Table of contents
- The frame — it is not an ideology question
- What “open-source ZTNA” actually means
- Serious open-source options in 2026
- Serious managed options in 2026
- The five decision axes
- Axis 1 — Engineering capacity
- Axis 2 — Compliance scope
- Axis 3 — Data sovereignty
- Axis 4 — Scale
- Axis 5 — Feature velocity
- Hybrid patterns that work
- Anti-patterns that do not
1. The frame — it is not an ideology question
Teams sometimes pick open source because they believe it is inherently better, or managed because they believe open source is inherently risky. Neither framing helps.
The useful framing: what is your total cost of operation, including engineering time and compliance overhead, under each option, for your specific constraints?
Open source is not free. Managed is not wasteful. Both deliver the same core functionality — encrypted tunnels, policy enforcement, identity integration, audit logging — and the choice is about the operational and organisational shape that fits your team.
2. What “open-source ZTNA” actually means
Three distinct layers can be open source, and the term “open-source ZTNA” covers different combinations.
- Data-plane protocol. WireGuard is open source and widely used. OpenZiti has its own open-source protocol. The data plane being open source matters for auditability and vendor independence.
- Client software. Tailscale clients are closed; the official Tailscale clients are proprietary. Headscale uses those clients but pairs them with an open-source coordination server. NetBird’s clients are open source. OpenZiti tunnelers and SDKs are open source.
- Coordination plane. This is where “open-source ZTNA” most commonly refers to. Headscale (Tailscale-protocol compatible), NetBird, and OpenZiti all have open-source coordination implementations.
When evaluating, clarify which layers you need open source. A team that wants open-source code from the device all the way to the coordination server has one shortlist. A team that just wants an open data-plane protocol has a different shortlist that includes QuickZTNA (WireGuard data plane, proprietary coordination).
3. Serious open-source options in 2026
3.1 OpenZiti / NetFoundry
OpenZiti is an Apache 2.0-licensed zero-trust overlay network. Distinctive feature: application-embeddable SDKs, so applications can have zero-trust connections without an OS-level VPN. NetFoundry is the commercial company offering managed services and support built on OpenZiti.
Strengths. Application-embedded model is unique. Permissive licence. Mature.
Trade-offs. Learning curve for the Ziti concept model. SDK integration is development work.
3.2 NetBird
NetBird is BSD-3-Clause-licensed WireGuard-based mesh VPN, with the same code offered as managed SaaS or self-host.
Strengths. Full self-host from managed-equivalent code. Active development. Permissive licence.
Trade-offs. Smaller ecosystem than Tailscale. Enterprise features still maturing.
3.3 Headscale
Headscale is a BSD-3-Clause third-party implementation of the Tailscale coordination server, compatible with official Tailscale clients.
Strengths. Lets you keep the Tailscale client experience on a self-hosted control plane.
Trade-offs. Feature parity with Tailscale is partial. Independent project roadmap.
3.4 DIY WireGuard
Not a product — a pattern. Run bare WireGuard with static configuration files or a home-built orchestration script.
Strengths. Zero subscription. Full control. Lowest possible complexity for small fixed fleets.
Trade-offs. Manual peer registration. No identity integration. No ACL language. No audit logs. Breaks at scale quickly.
Useful for homelabs and small permanent fleets. Not appropriate for a business beyond a handful of peers with stable membership.
4. Serious managed options in 2026
4.1 Tailscale
Tailscale is the managed mesh VPN category leader. Broad platform support, mature developer experience, generous free tier.
Strengths. Best-in-class developer ergonomics. Rich ACL language. Wide community.
Trade-offs. Coordination plane is proprietary. Feature gating differs by tier.
4.2 QuickZTNA
QuickZTNA is a post-quantum-first full ZTNA built on WireGuard. Hybrid X25519 + ML-KEM-768 on every tunnel. EU + US regions.
Strengths. Post-quantum default. Full ZTNA feature set (session recording, workforce analytics opt-in, device posture, ABAC). Self-host option on Workforce tier.
Trade-offs. Newer than Tailscale; smaller community.
4.3 Twingate
Twingate is a managed ZTNA with Client-Connector architecture and proprietary tunnelling protocol.
Strengths. Mature ZTNA model. Clean resource-level policy.
Trade-offs. Proprietary protocol. Not a mesh. Not self-hostable. See our Twingate alternative post for the deeper comparison.
4.4 Cloudflare Access
Cloudflare Access is edge-native identity-aware proxy, part of Cloudflare Zero Trust.
Strengths. Global edge network. Integration with broader Cloudflare stack.
Trade-offs. Not a mesh. Data passes through Cloudflare. See our Cloudflare Access alternatives post.
5. The five decision axes
Each axis below pushes toward one model or the other. Score each axis on your specific context; the option that wins on more axes is typically the better starting point.
- Engineering capacity. Do you have ≥ 1 platform engineer with time and skill to run infrastructure?
- Compliance scope. Which attestations do you need — SOC 2, HIPAA, ISO 27001, NIS2?
- Data sovereignty. Does the coordination plane need to stay in specific jurisdictions or inside your own VPC?
- Scale. How many users and devices; what growth curve?
- Feature velocity. Do you want features the day they ship, or can you wait?
6. Axis 1 — Engineering capacity
Self-hosted open-source ZTNA requires ongoing engineering time. Ranges we see in real deployments:
- Initial deployment. One to two engineer-weeks for a minimal setup. Three to five weeks for an HA setup with monitoring.
- Ongoing operations. One-half to one engineer-day per month in steady state.
- Incident response. Peaks of four to twenty hours during a major incident.
If your team has a platform engineer who can absorb this load, self-host is reasonable. If not, managed is the honest choice. Managed’s subscription cost is usually far less than the fully loaded cost of a spare engineer-week per month.
Score.
- Platform engineer available: self-host +1.
- No platform engineer: managed +1.
- Part-time: push to managed unless other axes compensate.
7. Axis 2 — Compliance scope
Compliance attestations are effort-expensive. Managed products bundle them.
- SOC 2 Type II. Managed vendors typically hold one. Self-hosting means your deployment of the ZTNA is in scope of your own SOC 2 audit — engineering effort plus auditor fees.
- HIPAA BAA. Managed vendors that serve healthcare offer BAAs. Self-hosting means your BAA chain depends on your own deployment.
- ISO 27001. Similar story.
- NIS2, DORA, CMMC. Compliance at the deployment level; managed provides evidence for the ZTNA portion.
If your compliance scope is extensive and your team is small, managed gives you a leg up. If your team is doing compliance work already at scale, self-host adds marginal effort rather than categorical new work.
Score.
- Multiple attestations required, small team: managed +1.
- Attestations already handled at scale: neutral.
- No formal attestations needed: neutral.
8. Axis 3 — Data sovereignty
Some regulatory contexts require specific data-residency or self-host configurations.
- EU data residency with specific exclusions. Check the managed vendor’s regional deployment footprint. QuickZTNA runs EU regions; Cloudflare runs on its edge network; others vary.
- German KRITIS, ANSSI Renforcée, OIV. Often requires self-host or specific sovereign-cloud deployment. Open source on your own infrastructure is commonly the answer.
- Air-gapped deployments. Self-host is the only option.
Score.
- Air-gapped or strict sovereignty: self-host +2.
- Multi-region SaaS acceptable: managed +1.
- Mixed: consider hybrid.
9. Axis 4 — Scale
Cost shape changes with scale.
- Under 20 users. Managed typically cheaper on fully loaded cost. Free tiers often meaningful.
- 20–60 users. Break-even zone. Score the other axes first; they usually decide.
- 60–500 users. Self-host cost advantage grows. Managed subscription rises linearly; infrastructure rises sublinearly.
- 500+ users. Self-host cost advantage significant; managed cost becomes large line item. Many very large organisations run a mix.
See our Headscale vs managed cost model for worked numbers.
Score.
- Under 20: managed +1.
- Over 500: self-host +1.
- Middle: depends on other axes.
10. Axis 5 — Feature velocity
New features land in the managed product first. Open-source tends to lag — sometimes weeks, sometimes quarters.
- If you want every new feature on release day, managed is the fit.
- If you are willing to wait, self-host works.
- If you need a feature not yet in either, open source lets you build it; managed forces you to wait for the vendor.
For post-quantum specifically, managed QuickZTNA is ahead of the open-source alternatives on default-on hybrid PQ tunnel encryption as of April 2026; this gap may close over time as NetBird, Headscale, and OpenZiti roll out their own PQ support.
Score.
- Feature-velocity priority: managed +1.
- Willing to build features: self-host +1.
- Neutral: neutral.
11. Hybrid patterns that work
Four patterns we have seen succeed.
11.1 Managed primary, self-host failover
Main deployment is managed. A self-hosted instance is maintained for disaster-recovery scenarios or specific regulated workloads. Rarely used but standing by.
11.2 Managed for office, self-host for production
Employees’ daily access goes through managed. Production infrastructure (dev → production server access) goes through self-host with stricter controls.
11.3 Regional split
Managed in jurisdictions where compliance allows. Self-host in sovereign jurisdictions where it does not. Requires careful identity and audit-log federation.
11.4 Managed with open-source client
QuickZTNA Workforce tier self-host + standard WireGuard clients; NetBird managed with custom-fork client for specific platforms. Less common but increasingly available.
12. Anti-patterns that do not
Four patterns that look attractive and fail.
12.1 Self-host “because it is cheaper”
On a fully loaded basis, self-host is rarely cheaper below 60 users. The “cheaper” framing ignores engineering time, which is the largest cost line item.
12.2 Managed “because open source is risky”
Managed products also have risks — vendor lock-in, data-sovereignty concerns, pricing changes. Both options have trade-offs; the framing of “safer” is rarely accurate.
12.3 DIY WireGuard “because it is simple”
Works for 5 peers. Breaks at 25 peers. Breaks harder at 50. You will reinvent the coordination server. Pick a real ZTNA product.
12.4 Mixed deployment without a reason
Running managed and self-host simultaneously, across the same user base, without a specific constraint, doubles operational complexity for no security or compliance gain. Pick one unless a specific axis forces hybrid.
Summary table
| Axis | Open-source self-host | Managed |
|---|---|---|
| Engineering capacity required | High | Low |
| Compliance attestation burden | On you | On vendor |
| Data sovereignty control | Full | Vendor-dependent regions |
| Cost shape | Infrastructure + labour | Per-user subscription |
| Feature velocity | Later | Immediate |
| Customisation | Fork-friendly | Vendor APIs |
| Support | Community | SLA |
| Scale break-even | ~60 users+ | ~20 users− |
Further reading
- OpenZiti documentation
- NetBird self-host docs
- Headscale GitHub
- Tailscale KB
- Cloudflare Zero Trust docs
Related reading on this blog
- Self-Hosting Headscale vs a Managed Coordination Server
- NetBird vs Tailscale vs QuickZTNA
- The Best Tailscale Alternatives in 2026
- Post-Quantum VPN: 6 Questions to Ask Your Vendor
Try QuickZTNA
QuickZTNA is managed primarily with self-host available on the Workforce tier — sized to hit the middle of the decision space for teams that want post-quantum default, SOC 2-bundled compliance, and the option to move to self-host later. Start on Free.