Learn Tailscale - Production-Ready Deployment
Episode 21 of 23

Learn Tailscale - Production-Ready Deployment

This episode covers production-ready Tailscale deployment: mass provisioning with auth keys and OAuth, fleet management via MDM for macOS and Windows, device monitoring, centralized update policies, plus a production checklist like strict ACLs, Tailnet Lock, audit logs, config backups, and runbooks.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Introduction

Up to episode 20, you connected devices one by one. In production, that approach won't survive: dozens of new nodes, hundreds of users, and no time for manual logins.

Episode 21 covers production-ready deployment: mass provisioning with auth keys and OAuth, fleet management via MDM, device monitoring, centralized update policies, plus a production checklist like strict ACLs, Tailnet Lock, audit logs, config backups, and runbooks.

The end goal is one thing: a tailnet a small team can maintain without drama.

Mass Provisioning

One-Shot and Ephemeral Auth Keys

Auth keys are the easiest way to add many nodes without human interaction:

Provision a node with an auth key
sudo tailscale up --auth-key=tskey-auth-kEYmPLdExample

Keys generated in the admin console can be one-shot or ephemeral. Ephemeral nodes are automatically removed from the tailnet when tailscale down runs — ideal for CI runners and containers that are born and die constantly. Make sure keys have a validity period, and never put them in a repository.

OAuth for Secure Provisioning

A static auth key is a leak risk. A safer alternative is an OAuth client: a client ID and secret are exchanged for short-lived tokens:

Provisioning with an OAuth token
sudo tailscale up \
  --auth-key="$(curl -s -X POST \
    https://api.tailscale.com/api/v2/oauth/token \
    -d client_id=oauthexample -d client_secret=secret)"

You learned the full scheme in episode 17. The point: tokens are exchanged at provisioning time rather than committed to configuration — so a leak in one place doesn't open the whole fleet.

Fleet Management

MDM for macOS and Windows

For work devices, distribute Tailscale configuration via MDM: Configuration Profiles on macOS, ADMX and registry on Windows. This way packages are installed and basic policies are applied before the user even logs in.

Combining OAuth device provisioning with MDM produces a smooth experience: new devices register into the tailnet without ever asking the user to type in an auth key manually.

Device Monitoring

Monitor fleet health from a single place:

Fetch fleet status via the API
curl -s https://api.tailscale.com/api/v2/tailnet/example.com/devices \
  -H "Authorization: Bearer tskey-api-xxxxx"

Data from tailscale status --json on each node or the API endpoint above can be used to display online/offline status, client versions, and advertised routes on a team dashboard.

Centralized Update Policy

Instead of setting auto-update on every node, enforce it through the ACL:

ACL for the auto-update policy
{
  "tagOwners": {
    "tag:prod": ["group:platform"]
  },
  "nodeAttrs": [
    {
      "target": ["tag:prod"],
      "attr": ["auto-update"]
    }
  ],
  "acls": [
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": ["tag:prod:*"]
    }
  ]
}

The auto-update attribute in nodeAttrs makes every node tagged tag:prod update itself to the latest stable release automatically — a policy that lives in one place and applies to the entire fleet.

Production Checklist

Strict ACLs

Start from deny-by-default. Every access must be explicit: users may only reach the nodes and ports they need. Use tags to separate dev, staging, and prod environments, then restrict who can own those tags via tagOwners.

Tailnet Lock and Audit Logs

Enable Tailnet Lock (episode 13) so major changes require signature approval, and use the audit log to record who did what. In the admin console, make reviewing the audit log a habit — not something done only after an incident.

Configuration Backups

Tailnet configuration — especially the ACL file — must be under version control. Use the Terraform Provider or the Tailscale API to pull and push configuration declaratively:

Back up configuration with Terraform
resource "tailscale_acl" "tailnet" {
  acl = file("acl.json")
}

The Terraform block above makes acl.json the source of truth. ACL changes only go through pull requests, and there's always history to revert to.

Troubleshooting Runbook

Document steps for the most frequent scenarios: nodes that can't do direct connections, DNS not resolving, devices not appearing in the admin console, and key expiry. Include the diagnostic commands from episode 18. A good runbook keeps on-call from depending on a single person.

Closing

Episode 21 turned the tailnet from a collection of devices into a managed system: automated provisioning, centralized policies, and an audit-ready checklist.

Key takeaways:

  • One-shot and ephemeral auth keys for mass provisioning.
  • OAuth is safer than static auth keys.
  • MDM distributes policies before the user logs in.
  • Auto-update policy can be enforced via nodeAttrs.
  • Strict ACLs with tags and tagOwners are the foundation.
  • Terraform or the API keep configuration backed up.

In episode 22, the final episode of the series, we'll cover the alternative ecosystem and final reflections — an honest comparison between Tailscale, ZeroTier, Nebula, Netmaker, and manual WireGuard, a recap of the journey from episode 0 to 21, and a production-grade tailnet architecture checklist for the future of secure networking.

Learn Tailscale - Production-Ready Deployment | Learn Tailscale