Private Access with Tailscale
Tailscale can give authorised devices and services private addresses and identity-aware access across networks, reducing the need for public inbound ports. Access controls, device ownership, credential expiry, and recovery still need deliberate management.
What You Will Be Able to Decide
- Explain the role of private access with tailscale in a self-hosted system.
- Apply the procedure to a real open-source deployment.
- Recognise unsafe defaults and verify the resulting control.
- Record enough evidence for another operator to repeat or recover the work.
Not every self-hosted application belongs on a public hostname. Dashboards, databases, staging systems, and internal tools can often remain private.
Tailscale builds an encrypted network between enrolled devices and services. It commonly works through outbound connections without requiring a new public inbound firewall rule, while direct peer connections can improve performance when the network permits them.
Private connectivity is not the same as unrestricted trust. A tailnet needs access-control policy, device lifecycle management, and a way to remove lost or departed identities.
Technical term
Tailnet
The private Tailscale network containing authorised users, devices, services, identities, and access-control policy.
It is a private company road system: entry still depends on identity and policy even though the roads do not appear on the public map.
The Working Model
Install Tailscale on the VPS for host-level administration or use its container image or sidecar pattern for a specific service. Choose one path intentionally so operators know whether access targets the host or only the application.
Use tags and access-control grants to express service identities rather than sharing one person's long-lived login. Tailscale OAuth clients and auth keys should be scoped, stored as secrets, and rotated; ephemeral credentials are useful for disposable containers.
Tailscale Serve can expose a service privately inside the tailnet. Funnel is a different feature that deliberately makes a service public and only supports designated TLS ports. Do not use Funnel when the requirement is private access.
Implementation Procedure
- Decide whether the service is public, private to the tailnet, or public only through a separate reverse proxy.
- Create a scoped device or service identity and store its enrolment credential outside Git.
- Install Tailscale on the host or define the documented container pattern.
- Write an access policy granting only the intended users or tagged services access to the required port.
- Test from an authorised device and an unauthorised identity, then document offboarding and recovery.
# Host-level status and assigned addresses
tailscale status
tailscale ip
# Confirm the private service responds over its tailnet name
curl -I http://internal-app:8080Controlled Practice and Fragile Practice
Verification and Recovery Evidence
- The private application is reachable from an authorised tailnet device.
- It is not reachable on the VPS public address or by an unauthorised identity.
- Lost devices, departed users, and expired service credentials can be removed without rebuilding the application.
Warning Signs
- The access policy grants every user every port.
- A long-lived enrolment key appears in repository history.
- Operators cannot distinguish Serve, Funnel, and a public reverse proxy.
Questions to Ask a Consultant
- Which surfaces should never have a public route?
- Are access grants based on service roles or on one person's account?
- How quickly can a lost device or leaked enrolment credential be revoked?
Key takeaway
Key Takeaway
Tailscale is a strong private-access layer when services stay off the public interface and identity, policy, credential lifecycle, and offboarding are managed explicitly.