Secure private remote access to OpenClaw with Tailscale

Problem statement: you need to access OpenClaw from outside your local network without exposing it to the public internet. Opening ports creates security risk. VPN solutions are complex to configure. Browser-based solutions require third-party relay services that may route your traffic through unknown infrastructure. You want private, encrypted access that works through NAT and firewalls without permanent public endpoints. Tailscale provides exactly this: a secure WireGuard-based mesh network that makes your hosted OpenClaw instance appear as a local device on your tailnet.

Why Tailscale for OpenClaw remote access

Traditional remote access approaches force unacceptable tradeoffs. Opening public ports exposes your OpenClaw instance to scanning and attack. Cloud VPN solutions require complex networking configuration. Browser-based relays introduce third-party infrastructure between you and your agent. Tailscale solves these problems by creating a private, encrypted mesh network that works through existing internet connections without configuration.

• No public endpoints: your instance gets a private IP on your tailnet, accessible only to authorized devices.
• NAT traversal: works through home routers, office firewalls, and mobile networks without port forwarding.
• End-to-end encryption: WireGuard encryption protects all traffic between your devices and your OpenClaw instance.
• Identity-based access: authorization is tied to user identities, not IP addresses, making access control robust and portable.

How Tailscale integration works with OpenClaw

The managed OpenClaw hosting platform deploys Tailscale as an optional sidecar container alongside your instance. This architectural choice has important security implications:

• Privilege isolation: the Tailscale sidecar runs with elevated network privileges required for tunnel creation, but the main OpenClaw container remains non-root with minimal capabilities.
• PVC-backed state: Tailscale state persists across pod restarts using a persistent volume claim, so your instance maintains its tailnet identity and configuration.
• Encrypted credential storage: your Tailscale auth key is stored encrypted in the instance database, not in plaintext environment variables or configuration files.
• Stable hostname assignment: the sidecar defaults to your instance resource name as the Tailscale hostname, avoiding MagicDNS names that change on every redeployment.

Enabling Tailscale for your OpenClaw instance

Step 1: Generate a Tailscale auth key

Start in the Tailscale admin console:

• Log into your Tailscale admin panel at https://login.tailscale.com/admin/machines.
• Navigate to Settings > Keys and generate a new auth key.
• Choose reusable or one-time based on your security preference. Reusable keys simplify recovery but require careful protection.
• Copy the generated key—you will need it during OpenClaw configuration.

Step 2: Configure Tailscale in the Addons tab

Enable Tailscale from your OpenClaw instance dashboard:

• Open your instance in the OpenClaw dashboard and navigate to the Addons tab.
• Locate the Tailscale configuration section and enable the addon.
• Paste your auth key into the encrypted storage field.
• Optionally specify a hostname. If left blank, the system uses your instance resource name for stable identity.
• Choose your DNS preference: MagicDNS for hostname.tailnet.ts addresses or raw IP usage.
• Save the configuration. The platform will restart your instance with the Tailscale sidecar injected.

Step 3: Verify connectivity and status

The Addons UI displays live Tailscale status after activation:

• Connection state: shows whether the sidecar is connected to your tailnet or disconnected.
• Assigned IP: displays the Tailscale IP address assigned to your instance.
• UDP availability: indicates whether UDP is working for direct peer connections or if traffic is falling back to relays.
• Relay risk: shows whether your connection is using DERP relays, which may introduce latency compared to direct peer-to-peer connections.

Accessing OpenClaw through your tailnet

Once Tailscale is enabled and connected, your OpenClaw instance appears as a device on your tailnet. Access methods depend on how you normally interact with OpenClaw:

Control UI access

If you use the web-based Control UI, access it through your tailnet:

• Use the Tailscale-assigned IP address directly: http://100.x.y.z:8080.
• Or use MagicDNS if enabled: http://your-instance-name.tailnet.ts:8080.
• The connection remains entirely within your encrypted tailnet, never traversing the public internet.

CLI and API access

Command-line tools and API clients can reach OpenClaw through tailnet addresses:

• Configure your OpenClaw CLI to use the tailnet endpoint instead of localhost or public IP.
• API calls use the same tailnet address, with the benefit that authentication credentials never traverse public networks.
• For development workflows, this means your local machine can treat a hosted instance as if it were running locally.

Browser relay through Tailscale

For browser automation workflows, Tailscale provides a secure path to your instance before you even enable relay functionality:

• Pre-relay connectivity: establish Tailscale connectivity first, then enable the Chrome Extension relay for tab control.
• Private relay path: your browser extension connects through your tailnet to the instance, then initiates relay sessions for browser control—all within your private network.
• No public relay exposure: unlike cloud relay services, traffic stays between your devices and your instance on your tailnet.

This combination is particularly powerful for teams that need browser automation but want to avoid exposing relay endpoints to the public internet. See Chrome Extension relay architecture for details on how the relay system works.

Troubleshooting Tailscale connectivity

UDP showing false or relay usage high

If UDP availability shows as false or relay risk is elevated, direct peer-to-peer connections are not working:

• Verify that your local machine has Tailscale installed and connected.
• Check firewall rules on both ends—UDP port 41641 must be available for WireGuard.
• Confirm that the label-scoped UDP egress NetworkPolicy is applied in your cluster.
• Some networks (especially restrictive corporate firewalls) block UDP entirely, forcing relay usage. This is secure but may increase latency.

Instance not appearing in Tailscale machine list

If your OpenClaw instance does not show up in your Tailscale admin console:

• Check the Addons UI for error messages or connection failures.
• Verify that the auth key was valid and not expired or revoked.
• Confirm that the instance restarted successfully after enabling Tailscale.
• Review the instance logs for sidecar startup errors or authentication failures.

Netcheck JSON preamble warnings

The tailscale netcheck --format=json command may emit a warning line before the JSON body on newer container builds. The platform status parser strips this preamble automatically, but if you see parsing errors, it may indicate a version mismatch in the netcheck output format.

Security considerations for Tailscale-enabled OpenClaw

Access control boundaries

Tailscale shifts your security boundary from network-level to identity-level:

• Audit who is on your tailnet: anyone with access to your tailnet can reach your OpenClaw instance by default.
• Use ACLs to restrict access: configure Tailscale ACLs to limit which users and devices can connect to your instance.
• Maintain instance authentication: Tailscale provides network access, but your instance still has its own authentication for Control UI and API access.
• Monitor tailnet membership: regular audits of who has Tailscale access are as important as auditing who has SSH access.

Privilege isolation details

The Tailscale sidecar architecture deliberately isolates capabilities:

• The main OpenClaw container runs as a non-root user with dropped Linux capabilities.
• Only the Tailscale sidecar has CAP_NET_ADMIN and network device access required for tunnel creation.
• Communication between OpenClaw and the sidecar happens through localhost, not exposing elevated privileges externally.
• If you disable Tailscale, the sidecar is removed entirely and your instance reverts to standard networking without privileged containers.

When to use Tailscale vs other access methods

Tailscale is ideal for specific access scenarios:

• Remote laptop access: you travel with a laptop and need secure access to your agent from coffee shops, hotels, or client sites.
• Multi-site teams: team members across different locations need shared access to a central OpenClaw instance without VPN infrastructure.
• Mobile device access: phones and tablets with Tailscale can reach OpenClaw for mobile-first workflows.
• Development environments: local development machines can interact with hosted instances as if they were running locally.

Alternatives like Chrome Extension relay may be preferable for pure browser automation workflows where tailnet connectivity is not required. Evaluate based on whether you need general network access or specifically browser control capabilities.

Limitations and edge cases

• Cluster egress requirements: the cluster hosting your OpenClaw instance must allow outbound connectivity to Tailscale coordination servers and DERP relay servers.
• Network policy interactions: some Kubernetes network policies may interfere with Tailscale UDP traffic. The platform includes a label-scoped UDP egress policy to handle this.
• Tailnet size considerations: very large tailnets with hundreds of devices may experience discovery delays as the mesh network stabilizes.
• Resource overhead: the Tailscale sidecar consumes additional memory and CPU, though the overhead is minimal for typical workloads.

Typical mistakes to avoid

• Assuming Tailscale replaces all security measures—you still need strong authentication on your OpenClaw instance itself.
• Forgetting to lock down tailnet ACLs, allowing any tailnet member to access your instance by default.
• Ignoring UDP availability warnings, which can lead to unnecessary relay latency when direct connections are possible.
• Revoking auth keys without regenerating them, causing the sidecar to lose authentication after restart.
• Assuming Tailscale solves all connectivity issues—some network environments actively block VPN protocols regardless of implementation.

FAQ

Does Tailscale slow down OpenClaw performance?

WireGuard (the protocol Tailscale uses) adds minimal overhead—typically less than 1-2ms for encryption. Direct peer-to-peer connections over UDP provide near-native speeds. Relay connections add latency proportional to the relay location, but the platform shows relay-risk status so you can diagnose when this is occurring.

Can I use Tailscale with multiple OpenClaw instances?

Yes. Each instance gets its own Tailscale sidecar with a unique hostname and IP address on your tailnet. You can have multiple instances accessible as different devices, which is useful for multi-agent deployments or separating production and development environments.

What happens if I disable Tailscale after enabling it?

The platform removes the Tailscale sidecar container from your instance deployment. Your OpenClaw instance reverts to standard networking and will no longer be accessible through your tailnet. Your instance data and configuration remain intact—only the networking overlay is removed.

Is my auth key stored securely?

Yes. Auth keys are stored encrypted in the instance database, not as plaintext environment variables. The sidecar retrieves and decrypts the key at startup to authenticate with your tailnet. This prevents credential leakage through logs, configuration dumps, or environment inspection.

Do I need Tailscale installed on every device that accesses OpenClaw?

To access OpenClaw through your tailnet, yes—each device must have Tailscale installed and connected to the same tailnet. This is the security model that ensures private, encrypted access. For devices where Tailscale is not feasible, consider alternative access methods or hosting options that match your constraints.

Sources

• Tailscale: secure, private WireGuard-based mesh networking
• OpenClaw Setup repository: per-instance Tailscale sidecar implementation (commits ae88655, 676e355, 7f06285, afbee31, 7a54dd5 from 2026-04-03)
• Chrome Extension relay architecture: secure browser control with Tailscale backend
• OpenClaw cloud hosting: managed platform with Tailscale support
• Worklog entry 2026-04-03-tailscale-sidecar.md: complete implementation notes including PVC-backed state, netcheck handling, and stable hostname defaults