docker-zerotier-planet: replacing ZeroTier's root servers with your own
一分钟私有部署zerotier-planet服务
At a glance
- What is it?
- A Shell-based Docker deployment that builds a private ZeroTier PLANET and controller on a public IP, aimed at users whose traffic to the official root servers is slow or unstable. The install path is short, but the project leaves you holding the planet file, the credentials, and the consequences.
- Who is it for?
- Adopt docker-zerotier-planet if you already run ZeroTier across machines you control, you have a Linux host with a public IP, and the official root servers are the bottleneck. Do not adopt it if you need a supported product with a published licence and upgrade path, or if you cannot accept that client planet files are replaced by hand.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 36 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: ZeroTier's root servers are somewhere else
ZeroTier builds a peer-to-peer virtual network. Devices behind NAT use STUN and similar techniques to find each other and connect directly; when that fails, traffic falls back to a relay. Before any of that can happen, a client has to find the network at all, and that job belongs to the PLANET servers: the project's README calls them the core root servers responsible for network discovery and the initial connection. Those servers are operated by ZeroTier, and the README states plainly that they are located overseas, which it identifies as the reason users in mainland China see high latency and unstable access. The project's answer is to stop asking the official roots and run your own. A self-hosted PLANET becomes the root your clients trust, so discovery happens against a machine you chose. The target user is narrow and specific: someone who already runs ZeroTier across several machines, has a Linux host with a public IP, and finds the default root path to be the weak link. It is not a general VPN installer, and it does not replace ZeroTier itself.
What actually gets deployed: a root server plus a controller
Two roles are bundled here. The first is the PLANET itself, the root that clients contact for discovery. The second is a network controller exposed through a web interface, which is what you use to create networks and authorize devices. The README's terminology table separates PLANET, MOON, and LEAF, and the project also supports building a MOON instead, described as a private regional root that helps nearby devices connect faster. The controller UI is a ztncui-style panel served on port 3443. The deploy script produces two artifacts in ./data/zerotier/dist: a planet file and a moon file. That planet file is the pivot of the whole setup. It is what you copy onto every client, replacing the vendor-supplied file, after which the client treats your host as a root. The README also notes that clients can fetch planet and moon configuration over a URL, which matters when you have more than a handful of devices. The data flow is therefore: client loads your planet file, contacts your host on 9994, joins a network you created in the controller, and is authorized from the same panel. Everything after that is ordinary ZeroTier peer-to-peer traffic, which the README says does not pass through the relay once a direct connection is established.
Getting it running: git clone, deploy.sh, and the ports you must open
The README requires a public IP and three open ports: 3443/tcp for the management panel, 9994/tcp and 9994/udp for ZeroTier communication. It notes that these can be adjusted to fit your situation, so treat them as defaults rather than fixed values. Software dependencies are Docker and Git. The documented Docker install is curl -fsSL https://get.docker.com | bash, followed by service docker start, with an optional registry mirror written to /etc/docker/daemon.json. Source retrieval is git clone https://github.com/xubiaolin/docker-zerotier-planet.git, and the README also lists a ghproxy mirror for users who need it. From the project directory you run ./deploy.sh, which presents a numbered menu: install, uninstall, update, view information, or exit. The README estimates one to three minutes for the script to finish, depending on network and machine. Afterwards you visit http://ip:3443, log in with the documented defaults admin and password, create a network under the Networks menu, and use Easy Setup to generate an IP range. The panel issues a network ID, which is the string clients pass to zerotier-cli join. On Windows the planet file goes into C:\ProgramData\ZeroTier\One and the ZeroTier One service must be restarted; on Linux the target is /var/lib/zerotier-one followed by service zerotier-one restart. Verification is zerotier-cli peers, where a PLANET entry with a DIRECT link indicates the client is talking to your root.
Where the project stops short: credentials, licence, and client churn
The default admin password is password, documented without any instruction to change it before exposing the panel. That is a deployment hazard, not a theoretical one: the controller is the component that authorizes devices onto your network. The README does contain a section on configuring SSL for the management panel, which suggests the authors expect it to face something other than a loopback interface, but the default state is plain HTTP on port 3443. The second gap is licensing. The repository metadata supplied here records the licence as unknown, and the README does not state one. For a tool that becomes the root of trust for your network, that is a real question to resolve before adoption, and it is not something this review can answer. The third issue is versioning. The most recent release listed is v2.1.0 from May 2024, while repository pushes continue into 2026, so release tags do not track the current state of the tree. Because the planet file must be distributed to every client and replaced by hand on Windows and Linux, upgrading means touching every device. There is no documented mechanism for rotating the planet file across a fleet.
When a MOON is the better answer than a PLANET
The project supports both, and the distinction decides whether you should use it at all. A MOON is a private root that acts as a regional relay and discovery helper while the official PLANET servers remain in the picture. A PLANET replaces them outright. If your complaint is latency to the official roots but you still want ZeroTier's own infrastructure as a fallback, a MOON is the smaller change: clients keep the vendor planet file and add yours alongside it. Going full PLANET means your host becomes a single point of discovery for every device, and if it goes down, new clients cannot find the network. The README's own framing supports this reading, describing MOON as a regional proxy node that helps nearby devices connect faster, while PLANET is the central hub. For a small number of devices on one continent, MOON is usually the proportionate choice. PLANET is for operators who want the root entirely under their control and accept the availability obligation that comes with it. The README does not discuss failover or running multiple PLANET nodes, so treat single-host operation as the documented model.
Maintenance cost and the upgrade path the README describes
Maintenance here is not a dashboard you check; it is a set of manual operations. The deploy script has an update option in its menu, so the server side has a defined path. The client side does not. Every device that joined your network holds a copy of the planet file, and the README's instructions for Windows, Linux, macOS, Android, and OpenWRT all involve placing that file by hand and restarting the ZeroTier service. The README points Android users at a third-party client, ZerotierFix, which is a dependency the project does not control. There is also a hosted-service section in the README offering a managed container with a three-day trial and a 99 CNY annual fee, which tells you the authors consider the manual path painful enough to sell around. That is a legitimate signal about operating cost. If you self-host, budget for the fact that a planet file change is a fleet-wide manual event, and that the controller panel's credentials and TLS configuration are yours to manage with no defaults changed for you.
Editorial conclusion
Adopt docker-zerotier-planet if you already run ZeroTier across machines you control, you have a Linux host with a public IP, and the official root servers are the bottleneck. Do not adopt it if you need a supported product with a published licence and upgrade path, or if you cannot accept that client planet files are replaced by hand. Verify three things before committing: the repository licence, whether v2.1.0 is compatible with the ZeroTier client version you run, and whether port 3443 is reachable only from where you administer it.
Community notes