Tailscale Sidecar Pattern: Private Self-Hosting with ScaleTail

I use the Tailscale sidecar pattern to privately self-host every service I build. It gives me zero-trust networking and automatic HTTPS without exposing a single public port. ScaleTail packages this pattern into reusable Docker Compose stacks, so I deploy apps in minutes instead of hours.

The Tailscale Sidecar Pattern with Docker Compose

A sidecar container handles cross-cutting concerns. In Kubernetes, that might be logging or service mesh proxying. In ScaleTail, it's Tailscale.

I configure the application to listen on a local port. The Tailscale container provides secure network access and gives the service a Tailnet URL with HTTPS, like https://application.tail-net.ts.net.

Most self-hosted apps assume trusted local networks or have weak admin defaults. Putting them behind a private mesh network is the correct default.

Here's a minimal Docker Compose example:

services:
  app:
    image: your-app:latest
    depends_on:
      - tailscale
    network_mode: "service:tailscale"
  tailscale:
    image: tailscale/tailscale:latest
    environment:
      TS_OAUTH_CLIENT_ID: ${TS_OAUTH_CLIENT_ID}
      TS_OAUTH_SECRET: ${TS_OAUTH_SECRET}
      TS_STATE_DIR: /var/lib/tailscale
      TS_HOSTNAME: my-app
    volumes:
      - tailscale-state:/var/lib/tailscale
    restart: unless-stopped
volumes:
  tailscale-state:

The key line is network_mode: "service:tailscale". It makes the app container share the Tailscale sidecar's network stack. The app becomes reachable only via the Tailnet, with no open host ports.

Security, ACLs, and Monitoring

The old home lab model was "open ports carefully." The newer model is "open almost nothing." Tailscale makes that friendly. ScaleTail turns it into repeatable templates.

I spin up services like Immich, Paperless-ngx, or Gitea without designing a public edge architecture. The first deployment is no longer a weekend networking project.

Internal tools often die because deployment overhead exceeds their value. If a private dashboard or admin utility can drop into a Tailnet with HTTPS quickly, more internal software becomes worth building.

Tailscale doesn't fix every app bug. If the app has broken auth or unsafe file uploads, those remain issues. The win is exposure reduction.

A service available only inside a Tailnet has a smaller attack surface than one on a public IP. I share access deliberately; the default posture is private.

I control who accesses each service with Tailscale ACLs. I restrict by identity, tag, or port. For example, I tag a sidecar with tag:media-server and enforce ACL policies only for family members.

Need public access? Use Tailscale Serve and Funnel. Funnel exposes a service to the internet via Tailscale's infrastructure—still zero-trust, but accessible without a Tailscale client. Great for a public blog or a customer-facing dashboard.

I monitor sidecar health with docker logs tailscale. Tailscale's admin console shows each node's activity. For deeper insight, use the sidecar's metrics endpoint and integrate with your observability stack. Tailscale's logging and monitoring guide covers best practices.

Operational Practices and Tradeoffs

Even with a sidecar, you need discipline. Understand Tailscale auth keys and rotation. Keep containers updated. Maintain backups. Read each service's .env file.

• Performance Overhead: The sidecar adds minimal overhead. Tailscale uses WireGuard, which is efficient. For most workloads, CPU and memory impact is negligible. But on resource-constrained devices, monitor usage.
• Key Management: Handle auth keys securely. Use one-time keys with short expiration for ephemeral deployments. For permanent services, reuse keys with appropriate ACLs. Never commit keys to a public repository.
• Network Isolation: Sharing the network stack means the app container has no network isolation from Tailscale. This simplifies setup, but any compromise of the app could affect the Tailscale container. I consider deploying untrusted services with additional isolation, such as separate Docker networks or VMs.
• Debugging: Check connection status with docker logs tailscale. Tailscale's admin console shows each node's activity. For deeper insight, use the sidecar's metrics endpoint if exposed.

Also refer to the official Tailscale Docker documentation for more advanced configurations.

Getting Started with ScaleTail

Getting started takes less than five minutes:

1. Clone the repository.
2. Choose a service from the available configurations.
3. Set up your Tailscale auth key.
4. Run docker compose up -d.

Your service will appear in your Tailnet with HTTPS. No open ports, no reverse proxy setup.

Ship Privately First

ScaleTail is part of a trend: boring, composable infrastructure for personal and small-team software. Not everything needs Kubernetes or a public SaaS control plane. A lot of useful software just needs a private URL, automatic HTTPS, and sane network boundaries.

For builders, that unlocks a healthier loop: build the tool, put it behind the Tailnet, use it, improve it. If it becomes valuable, then harden and expose it properly.

Ship privately first. Prove usefulness. Then decide whether the world needs access.