Tor Hidden Services

The source material this section replaces covers setting up Tor hidden services (.onion addresses) for many of the self-hosted services in the series: the web server, mail server, XMPP server, and others. It is a thoughtful treatment of a legitimate use case.

This series excludes Tor entirely. That decision has been consistent throughout: every page that referenced Tor in the source material has had it removed. This page explains the reasoning so it does not look like an oversight.

What Tor hidden services provide

A Tor hidden service creates an .onion address for a service: an address reachable only through the Tor network, which anonymises both the client’s location and the server’s location. The server’s IP address is never revealed to the client, and the client’s IP address is never revealed to the server.

This is genuinely valuable in specific contexts: a whistleblowing platform, a service operated in a jurisdiction with surveillance concerns, a communications tool for people in high-risk environments. SecureDrop, the platform used by journalists to receive leaked documents, runs as a Tor hidden service. That is the right use case.

Why it is not in this series

This network’s threat model does not require hidden services. The goal is self-hosted infrastructure: data on hardware you own, services accessible to you and the people you trust, without dependency on third-party platforms. Anonymising the server’s location from its own users is not a requirement of that goal.

WireGuard already solves the remote access problem. The primary reason the source material uses Tor for some services is to make them accessible from outside the home network without exposing them to the public internet. The WireGuard VPN in this series does this more reliably, with lower latency, and without the complexity of Tor. A phone with WireGuard active appears to be on the internal network. It can reach every internal service via hostname without those services having public-facing ports or .onion addresses.

Tor adds complexity and attack surface. The Tor daemon is another service to maintain, update, and monitor. Hidden service configuration requires careful management to avoid accidentally leaking the server’s real IP address. The Tor network itself introduces latency that makes some services (video streaming, large file sync) impractical.

The source material’s Tor integration is not consistent. Not every service in the source gets a hidden service: the Tor configuration appears on some pages and not others, making it hard to reason about which services are actually accessible via Tor and which are not. A partial Tor deployment provides weaker anonymity guarantees than a complete one.

If you want Tor

The Tor Project’s documentation covers hidden service configuration in detail:

https://community.torproject.org/onion-services/setup/

The configuration is straightforward for a single service. Adding it to any container in this series requires installing tor, creating a hidden service directory in /etc/tor/torrc, and noting the generated .onion address. The Tor Project’s documentation is current and well-maintained.

If the use case genuinely requires hidden services, a dedicated Tor container following the base template approach used throughout this series is cleaner than distributing the Tor daemon across multiple containers.

The absence of Tor from this series is not a statement about Tor’s value. It is a statement about scope. For the threat model this network addresses, WireGuard provides the remote access security that matters. For networks where server location anonymity is a genuine requirement, Tor is the right tool and the Tor Project’s documentation is the right place to start.