← Back to blog

First-Class Tailscale Support

James /

Networking is the part of self-hosting that makes people quit.

You get Docker running, you pick your apps, everything works on localhost. Then you need to actually reach the thing from somewhere else. Now you’re dealing with port forwarding, dynamic DNS, firewall rules, and some router admin panel that hasn’t been updated since 2014. If you’re an MSP doing this across a dozen client sites, multiply that pain accordingly.

Self-hosting shouldn’t require a networking certification. With Slipwire, it doesn’t.

Every Slipwire deployment gets Tailscale automatically. No ports, no DNS, no VPN setup. Your client’s server just appears on your tailnet.

How it works

When you create a new site in the Slipwire dashboard, the install command you get is a single command. Run it on the target machine, and the agent handles everything: claiming the deployment, authenticating with Tailscale, and joining your tailnet. No ports to open. No DNS records to manage. No VPN client to install on your laptop.

The agent talks to the Slipwire dashboard over a standard WebSocket connection. Tailscale is for you. It’s how you reach the services running on that machine. File storage, password vaults, whatever you deploy. All accessible over a WireGuard mesh without touching the client’s firewall.

The machine just shows up in your fleet, with a Tailscale IP and hostname, ready to access.

Two ways to set it up

Slipwire supports two models depending on how you want to manage your tailnets.

Per-client keys. If your client already has Tailscale, or you maintain separate tailnets per client, you can paste an auth key when creating the deployment. The agent uses it once during setup, and the key is immediately discarded from the database. Good for MSPs who want strict network isolation between clients.

MSP-managed. If you’d rather manage one tailnet for all your sites, you can add your Tailscale API credentials in Settings. Slipwire will auto-generate a single-use, pre-authorized auth key every time a new site is claimed. The keys are tagged with tag:slipwire so you can write ACL rules to keep client sites isolated within the same tailnet.

You can mix both. Some clients get their own tailnet, others join yours. Per-deployment override always wins.

What you see in the dashboard

Once a site is connected, the deployment detail page shows the Tailscale IP and hostname. If Tailscale drops on a machine, Slipwire detects it in the next heartbeat cycle and flags it in your activity feed.

No need to check Tailscale’s admin console separately. It’s all in one place.

Security stuff

A few things worth mentioning:

  • Auth keys are single-use and short-lived (1 hour expiry). They’re cleared from the database the moment the agent receives them.
  • Tailscale API credentials are encrypted at rest. They never leave the control plane.
  • The agent never persists the auth key to disk. It’s used once for tailscale up and that’s it.
  • If something goes wrong, you can always override with a CLI flag on the agent side.

Why Tailscale

I looked at a lot of networking options. Cloudflare Tunnels, ZeroTier, plain WireGuard, rolling my own. Tailscale won because it’s genuinely zero-config for the end user while still being auditable for the operator. NAT traversal that actually works. An API that does what you’d expect. No weird edge cases at 2am.