INFRA Signal 148
Build with Tailscale. Build on Tailscale.
↗
Tailscale now lets developers embed per-application Tailscale identities via the tsnet Go library and programmatically create isolated tailnets through its Tailnets API.
Embedding networking removes the need to open ports, stand up reverse proxies, and manage certificates manually, cutting on-call effort. Programmatic tailnet provisioning enables per-customer or per-environment isolation without hand-editing the admin console. Together they let teams treat secure networking as code rather than an after-thought.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The tsnet library lets a Go application join a tailnet as its own node with a unique identity, MagicDNS name, and automatic TLS certificates.
The Tailnets API lets you create, share, and tear down whole tailnets on demand, supporting isolated networks for customers, environments, or short-lived tests.
Both features keep admin-console control while eliminating host-level daemons, public ports, and manual certificate handling.
THE READ
What the cluster adds up to.
Tailscale has expanded from a configuration-only tool to a platform that can be built with and on. The tsnet Go library embeds a Tailscale client inside an application, giving the app its own identity and network endpoint. The Tailnets API lets external systems provision entire tailnets via HTTP calls, automating creation, sharing, and teardown. These two primitives let developers treat secure connectivity as part of their codebase rather than a post-deployment step.
Adopting tsnet requires adding the Go library, supplying an auth key, client ID, and secret, and configuring a tsnet.Server struct before calling Up and ListenTLS. Non-Go languages are only supported through the experimental tailscale-rs bindings, which are pre-alpha and not yet production-ready. Using the Tailnets API adds the need for an API token and scripting of HTTP requests to create and manage tailnets, which must be integrated into provisioning pipelines.
The new capabilities stop working outside their supported runtimes: tsnet is a Go library, so applications in other languages must rely on the experimental bindings or a separate approach. The Tailnets API requires an existing Tailscale organization and appropriate permissions; it cannot replace the host-level Tailscale daemon for full OS networking. Additionally, automatic TLS certificates are only minted if HTTPS is enabled for the tailnet, so environments without that setting will not get certificates automatically.
The blog frames the changes as two complementary approaches: "build with Tailscale" (per-application identity via tsnet) and "build on Tailscale" (network-level automation via the Tailnets API). The former focuses on giving each service its own scoped access, while the latter emphasizes on-demand isolation of whole networks for customers or tests. Understanding the distinction helps engineers choose the right tool for app-level security versus environment-level segregation.
For engineering teams, these additions shift networking from a manual, error-prone step to code that can be versioned and tested. The reduction in port-opening, proxy configuration, and certificate renewal lowers operational overhead and on-call load. However, teams must still manage authentication material and ensure their tailnet settings (like HTTPS) are correctly configured to reap the full benefits.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER