# ZeroTier One: a peer-to-peer Ethernet switch for machines that cannot share a LAN

> ZeroTier One builds a virtual Layer 2 network across the internet, with end-to-end encryption and peer-to-peer paths where NAT allows them. It suits people who need a flat network between scattered machines, and it is a poor fit for anyone who wants a simple point-to-point tunnel.

**zerotier/ZeroTierOne** — A Smart Ethernet Switch for Earth

- Repository: https://github.com/zerotier/ZeroTierOne
- Website: https://zerotier.com
- Stars: 17,150 · Forks: 1,974
- Language: C++
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/zerotier-zerotierone

## What problem ZeroTier One solves, and for whom

The README describes it as "a smart programmable Ethernet switch for planet Earth" and says it lets networked devices, VMs, containers and applications communicate as if they all reside in the same physical data center or cloud region. That is the whole pitch, and it is narrower than the word VPN suggests. A conventional VPN gives you a tunnel between two endpoints. ZeroTier One gives you a shared Ethernet segment that many endpoints join, with Layer 2 semantics: broadcast, multicast and arbitrary protocols work without per-protocol configuration.

The audience follows from that. If you are stitching together a home lab, a set of cloud instances and a laptop, and you want them to see each other as if they were on one switch, this is the target case. The README also names enterprise SDN features, specifically fine grained access control rules for network micro-segmentation and security monitoring, so the same mechanism is aimed at operators who need to restrict which members can reach which ports. Mobile clients exist for Android and iOS and the README says they are free in the Google Play and Apple app stores.

It is not for someone who wants a two-host tunnel. Nothing in the repository layout suggests a stripped-down mode for that.

## VL1 and VL2: the two layers behind the virtual switch

The README splits the design into two layers. VL1 is a cryptographically addressed and secure peer-to-peer network. VL2 is an Ethernet emulation layer, described as somewhat similar to VXLAN, that carries the actual frames and provides the SDN features. Keeping them apart is the interesting design decision: addressing and transport live in VL1, while the virtual switch lives in VL2. That is why a member can move between physical networks and keep the same virtual identity, and it is why the access control rules apply to frames rather than to sockets.

The README states that all ZeroTier traffic is encrypted end-to-end using secret keys that only you control, and that most traffic flows peer-to-peer. The qualifier matters. Where peers cannot establish a direct path, the project offers free but slow relaying. So the architecture has a fast path and a fallback path, and the fallback is explicitly described as slow. Whether a given pair of nodes lands on the fast path depends on the networks between them, which is not something the repository promises.

There is also a controller component. The repository contains a nonfree/controller/ directory with its own README, and the top level carries scripts named build_central_controller.sh, cycle_controllers.sh and update_controllers.sh. The README does not explain how a self-hosted controller relates to the hosted service, so treat that as something to read up on separately.

## Installing ZeroTier One and joining a first network

The README points to the ZeroTier documentation as the place to start for downloads, installation and usage, and lists a downloads page on the corporate site. It does not reproduce per-platform install commands, so check those pages for your platform rather than guessing. What the README does give is the build path: build.md holds build instructions and platform requirements, and the top-level Makefile dispatches to per-platform makefiles such as make-linux.mk, make-mac.mk, make-bsd.mk and make-netbsd.mk, with CMakeLists.txt and CMakePresets.json also present for CMake users.

Once the client is installed and running, the operational surface is the zerotier-cli command. The repository ships zerotier-cli-completion.bash, which confirms the CLI is the intended interface. A typical first use is to confirm the service is up and then join a network by its 16-character network ID:

```bash
zerotier-cli info
zerotier-cli join <network-id>
```

The info subcommand reports the node's own identity and status; join adds the node to the network identified by the ID you supply. The README does not document the exact output of either command, so expect to confirm the result in the controller interface. For a self-hosted controller, the repository includes build_central_controller.sh and the nonfree/controller/README.md as the starting points.

If you build from source instead of installing a package, the entry points are the platform makefiles and the CMake presets. The repository also carries packaging material in pkg/, debian/ and zerotier-one.spec, plus Dockerfile.release and README.docker.md for container builds. The README does not state which of these is the supported path for any given distribution.

## Where ZeroTier One is the wrong tool

The relay fallback is the first real limitation. The README says free relaying exists for users who cannot establish peer-to-peer connections and calls it slow. If your workload is latency-sensitive and the peers in question cannot punch through their NATs, you are on the slow path with no documented way to force a direct connection. The README does not describe how to diagnose which path a given pair is using.

The second limitation is the licence split, which is unusual enough to matter at adoption time. The README states that LICENSE-MPL.txt covers all code in node/, osdep/, service/ and everywhere else except ext/ and nonfree/, while nonfree/LICENSE.md covers the non-free, source-available portions. Code in ext/ is external code included for build convenience or backward compatibility and retains its original license. The repository's own licence field is NOASSERTION, which reflects that mixture rather than a single clean identifier. If your organisation requires a single permissive licence across the dependency tree, this layout needs review before you commit.

The third case is simpler: if you need one encrypted tunnel between two machines and nothing else, the Ethernet emulation layer and the controller machinery are overhead you will never use.

## How ZeroTier One differs from WireGuard and Tailscale

WireGuard is a Layer 3 tunnel. It moves IP packets between configured peers, and each peer relationship is defined by keys and allowed IPs that you distribute yourself. There is no virtual switch, no broadcast domain and no controller. ZeroTier One sits a layer lower in the stack: the README describes an Ethernet emulation layer similar to VXLAN, so frames rather than packets are what the network carries. That is the actual difference. Protocols that depend on broadcast or on non-IP traffic work over ZeroTier One without extra configuration, and they do not work over a plain WireGuard tunnel without help.

Tailscale is closer in shape, since it also handles key distribution and NAT traversal for you, but the comparison is one the README does not make. What can be said from this repository is that ZeroTier One exposes an Ethernet segment plus SDN access control rules, and that a portion of the controller code is source-available rather than open source. Anyone weighing the two should compare those two properties directly rather than the marketing pages.

The older comparison people search for, ZeroTier One versus Hamachi, is a different generation of tool. Hamachi popularised the hosted virtual LAN idea, but this repository says nothing about it, so there is no basis here for a technical comparison.

## Maintenance, releases and what an upgrade costs

The last push to the repository was on 2026-09-03, and the most recent release listed is 1.16.2 from 2026-05-28, with 1.16.1 published the same day and 1.16.0 on 2025-09-11. The default branch is dev, so the stable line and the development line are separate; anyone building from a clone should check out a tagged release rather than tracking dev unless they intend to.

Upgrade cost is mostly operational rather than code. The client is one binary per machine, and the version is recorded in version.h, so a fleet upgrade is a matter of replacing that binary across nodes. The repository carries packaging for several formats (pkg/, debian/, zerotier-one.spec) and release Dockerfiles, so automated distribution is plausible, but the README does not document a rollback procedure or a compatibility matrix between client versions and controller versions. That gap is worth closing before you upgrade a large fleet.

The licence position deserves a second look at upgrade time as well, because the split between LICENSE-MPL.txt and nonfree/LICENSE.md is part of the repository rather than a footnote, and the non-free directory is where the controller lives. This article is not legal advice; read both licence files and get your own review if the distinction affects your distribution plans.

## Conclusion

Adopt ZeroTier One when you need a flat Ethernet segment between machines on different networks and you accept that the controller and root infrastructure sit outside your control. Do not adopt it when a single point-to-point tunnel between two hosts is all you need; WireGuard covers that with far less machinery. Before rolling it out, verify the licence boundary between node/ and service/ under LICENSE-MPL.txt and nonfree/ under nonfree/LICENSE.md, confirm which version the release notes describe, and check whether the peers you care about actually establish direct paths or fall back to relaying.

## FAQ

### What is ZeroTier One used for?

It connects devices, VMs, containers and applications so they communicate as if they were in the same data center or cloud region, by combining a peer-to-peer network with an Ethernet emulation layer. The README also lists fine grained access control rules for network micro-segmentation and security monitoring.

### Is ZeroTier One a VPN?

The README does not call it a VPN. It describes a smart programmable Ethernet switch that emulates a Layer 2 network similar to VXLAN, which is a broader capability than a point-to-point tunnel.

### How do I install ZeroTier One?

The README directs readers to the ZeroTier documentation for downloads and installation, and to the downloads page on the corporate site. Building from source is documented in build.md, with per-platform makefiles and CMake presets in the repository.

### How do I use ZeroTier One on Linux?

The repository ships make-linux.mk for source builds and a zerotier-cli-completion.bash script for the CLI. Once the client runs, zerotier-cli info reports the node status and zerotier-cli join <network-id> adds it to a network.

### How does ZeroTier One compare with WireGuard?

WireGuard moves IP packets between peers you configure yourself. ZeroTier One adds an Ethernet emulation layer similar to VXLAN on top of a peer-to-peer network, so broadcast and non-IP traffic work without per-protocol setup.

### Is ZeroTier One still free?

The README says free relaying is offered for users who cannot establish peer-to-peer connections, and that the Android and iOS apps are free in the Google Play and Apple app stores. It does not describe pricing for the hosted controller service.

## Sources

- [Issues](https://github.com/zerotier/ZeroTierOne/issues)
- [Project website](https://zerotier.com)
- [README](https://github.com/zerotier/ZeroTierOne/blob/dev/README.md)
- [Releases](https://github.com/zerotier/ZeroTierOne/releases)
- [zerotier/ZeroTierOne on GitHub](https://github.com/zerotier/ZeroTierOne)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zerotier-zerotierone
