Tor hidden service walkthrough shows a website with no DNS, no CAs and no exposed IP

David Alvarez Rosa has made his personal site reachable as a Tor hidden service and published a step-by-step account of how he did it — a post that surfaced on the Hacker News front page. The result is a website that needs none of the infrastructure most sites treat as mandatory: no DNS lookups, no certificate authority, and no server IP address visible to visitors.

What the onion address replaces

According to the post, a hidden service's .onion name is generated from the service's own public key, which makes the address self-authenticating: a client reaching it can confirm it landed on the right host without consulting a third-party certificate authority. The Tor network encrypts the connection end to end, so no TLS certificate is involved either. Because the name exists only inside the Tor network, the machine hosting the site never has to reveal a publicly routable IP address.

Tor itself, built by the nonprofit Tor Project, routes traffic through thousands of volunteer-operated relays so that no single participant in the network can tie a user's identity to their activity. A hidden service extends that same protection to the server side, hiding where the site physically runs.

The Tor configuration

The setup starts in /etc/tor/torrc with two directives: HiddenServiceDir pointing at a path such as /var/lib/tor/blog/, and HiddenServicePort mapping the onion's port 80 to a local listener on 127.0.0.1:8080. One detail the author stresses: that directory must be dedicated to Tor and owned by the Tor service user (debian-tor, with mode 700), because Tor stores the service's private key and hostname file there. Pointing the directive at your web root instead will stop Tor from starting at all.

After restarting the service with systemctl restart tor@default, the generated address can be read from the hostname file inside that directory — in his case a 56-character string ending in .onion, resolvable only by Tor clients such as the Tor Browser.

A plain nginx listener on loopback

From the web server's perspective, nothing exotic is happening. Tor forwards connections made to the onion's port 80 onto the local loopback, so nginx simply binds to 127.0.0.1:8080 and serves files from a separate root. The server block sets server_name to the onion address and routes 404s to a static error page, but deliberately omits TLS, HTTP/2 and QUIC. As Alvarez Rosa explains, traffic rides plain TCP inside Tor's already-encrypted circuits, so a local TLS layer would add nothing.

Building the site twice

The last wrinkle comes from the static site generator. Hugo embeds the base URL into generated pages as absolute links, so a single build cannot correctly serve both the ordinary domain and the onion address — links in the Tor copy would shunt visitors back to the clearnet site. His fix is to run Hugo twice per deploy: once with the regular domain, and once passing the onion address via the --baseURL flag. The pipeline, driven by GitHub Actions, builds both targets on every push and uses rsync to drop each version into its own web root. The server-side configuration lives in his homelab repository.

Why it matters

The walkthrough is a tidy demonstration that DNS, certificate authorities and exposed host addresses are one solution to naming, authenticity and privacy — not the only possible one. A key-derived address removes whole categories of operational risk: there is no domain registration to lose or seize, no certificate lifecycle to manage, and no IP that can be blocked or geolocated. For publishers operating under censorship pressure, or anyone whose host would rather not know what it is serving, this is a way to stay reachable while the server's location stays hidden. It also comes with the network's built-in caveat: the Tor Project's anonymity guarantees rest on volunteer participation, and the author closes by encouraging readers to run a relay or otherwise support the network that makes .onion sites possible.