Tailscale with Docker: Host-Level Tailnet or Per-Container Sidecar?

I choose the networking boundary before I add Tailscale to a Docker stack, because the two patterns create different operational models.

For most of my home-server services, the host is already a trusted tailnet node. That means a container can often stay on ordinary Docker networking while the host and reverse proxy decide which service is reachable from the tailnet.

The setup I use

The alternative is a Tailscale sidecar or Tailscale-aware container that gets its own tailnet identity. That can be excellent when the service needs a distinct identity or policy boundary. It is unnecessary complexity when I only need private admin access to a port already owned by the host.

Commands and configuration

docker ps
tailscale status

# For a host-level pattern, inspect which local port the service exposes:
ss -lntup

Where this usually fails

Putting every container directly on the tailnet can create an inventory problem: more nodes, more policy objects and more state to manage. Putting everything only behind the host can make per-service authorization too coarse. The right boundary depends on whether the service needs its own identity.

The rule I keep

Give a container its own tailnet identity only when that identity provides a real security or routing benefit.

That rule is more useful to me than memorising one command because it identifies which layer owns the decision. Tailscale is excellent at creating a private, authenticated IP network between machines, but I still keep application state, Reticulum state, SSH authorization and public ingress as explicit layers.

References

• https://tailscale.com/docs/how-to/docker
• https://tailscale.com/docs/quick-guides