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.

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.
Auth keys are the easiest way to add many nodes without human interaction:
sudo tailscale up --auth-key=tskey-auth-kEYmPLdExampleKeys 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.
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:
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.
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.
Monitor fleet health from a single place:
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.
Instead of setting auto-update on every node, enforce it through the ACL:
{
"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.
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.
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.
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:
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.
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.
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:
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.