Tailscale — Dependencies#

Module info#

• Module: tailscale.com
• Go version: 1.26.1
• Direct dependencies: 145
• Indirect dependencies: 344 (total in go.mod: 489)
• go.sum entries: 1794 (≈ 897 unique module versions, each listed twice for mod + zip hashes)

Dependency categories#

Core infrastructure#

Networking / WireGuard / NAT traversal#

Security / Cryptography#

Data / Storage / Routing#

Observability#

Kubernetes (k8s-operator)#

Cloud / Platform integration#

SSH / File sharing (Tailscale SSH / Drive)#

Testing#

Build toolchain (in go.mod as direct deps)#

UI / Desktop#

gVisor (userspace networking)#

Stdlib reliance#

Tailscale is deeply stdlib-first. Counting import occurrences across all non-vendor .go files:

Key stdlib choices:

• net/netip (274 usages): Tailscale was an early and major adopter of net/netip (the new Go 1.18 IP address types). Brad Fitzpatrick, who designed net/netip, works at Tailscale, and the package was motivated in part by Tailscale’s needs. The codebase uses netip.Addr, netip.Prefix, and netip.AddrPort pervasively rather than net.IP.
• slices: Heavy use of the Go 1.21 slices package (149 occurrences) indicates a modern Go mindset.
• Stdlib crypto: crypto/ed25519, crypto/sha256, crypto/tls, and crypto/rand appear throughout — third-party crypto is only used where stdlib doesn’t reach (Noise protocol, BLAKE2s, CBOR).
• No third-party logging at the core: The core types/logger package wraps a simple func(string, ...any) type, not any third-party logging framework. zap appears only in Kubernetes operator code where controller-runtime mandates logr.

Shared dependencies#

Dependencies that Tailscale shares with many other projects in the 50-project set — these are cross-cutting connection points:

Vendoring#

No vendor directory. Tailscale relies on the Go module proxy and go.sum checksums. Despite the large dependency count (489 in go.mod, ~897 module versions in go.sum), they chose not to vendor, likely because:

1. The depaware.txt snapshot files in each binary’s directory already provide a human-readable record of what’s included and serves as a canary for unexpected dependency additions (enforced via deps_test.go).
2. Vendoring 897 modules would balloon the repository size significantly.
3. Tailscale controls its most critical dependencies by maintaining its own forks (wireguard-go, golang-x-crypto, netlink, go-winio), reducing the risk of upstream supply-chain surprises.

Notable dependency decisions#

1. Fork-critical, module-proxy the rest. Tailscale maintains 8+ forks of upstream packages (wireguard-go, golang-x-crypto, netlink, go-winio, peercred, xnet, etc.). For packages where correctness is security-critical or where Tailscale needs to move faster than upstream, they fork. For everything else, they use the module proxy. This is a deliberate middle ground between full vendoring and pure upstream dependency.

2. go-json-experiment/json as a bet on the future. Brad Fitzpatrick co-designed this package as the proposed replacement for encoding/json in a future Go version (tracking issue golang/go#71497). Tailscale adopting it in production with 40+ usages is both a dogfooding exercise and a signal of their confidence in the design.

3. net/netip everywhere. The netipx package extends net/netip with IPRange, IPSet, and set algebra operations not in stdlib. Tailscale holds go4.org/netipx as a direct dep and uses it pervasively alongside net/netip. This pairing represents the “full Tailscale IP algebra” that predates (and influenced) the stdlib addition.

4. Toolchain deps in go.mod. golangci-lint, staticcheck (honnef.co/go/tools), nfpm, esbuild, and several other build tools are listed as direct go.mod dependencies with no // indirect. This means developers run go run github.com/golangci/golangci-lint/cmd/golangci-lint at a pinned version rather than installing tools separately — a clean reproducibility approach but one that inflates the go.sum significantly.

5. gVisor as a userspace networking library. Importing gvisor.dev/gvisor pulls in Google’s entire OS kernel sandbox as a library for its TCP/IP stack. This is architecturally extraordinary: Tailscale’s “netstack” mode runs a complete layer-3/4 stack in user space, enabling operation in environments without kernel TUN support. The dependency exists because no lighter-weight, production-quality Go userspace TCP/IP stack existed at the time Tailscale adopted it.

6. CBOR for TKA. The choice of CBOR over JSON/protobuf for TKA (Authority Update Messages) is deliberate: CBOR is both compact and has a canonical encoding form (CBOR Deterministic Encoding) required for cryptographic signing. Protobuf’s canonical encoding is more complex; JSON’s is not standardized. CBOR gives a well-specified byte sequence to sign.

7. Minimal logging framework. The core daemon avoids structured logging frameworks. tailscale.com/types/logger is simply type Logf func(format string, args ...any) — a function type that can be composed, wrapped, and injected. This design means every subsystem can receive a contextual logger without depending on a third-party logging package.