A developer named David Alvarez Rosa has turned his entire website into a Tor hidden service, posting the exact steps needed to do it yourself. The result is a fully working onion site — one that can only be reached through the Tor network — and he has documented every command, configuration file, and deployment detail along the way.
What follows is a walkthrough of how he did it, followed by what we think it means for anyone curious about privacy online.
How the Onion Works
Tor is a privacy tool that routes traffic through a chain of volunteer servers, each stripping out information about who is sending data. The final step is a hidden service, where the server itself gets a .onion address derived from a public key rather than a traditional DNS name.
There is no certificate authority, no DNS, and no exposed IP address. The connection is end-to-end encrypted by Tor itself, and the address resolves only inside the Tor network. That means the site exists in a parallel namespace — a visitor typing in the .onion address sees the same content, but the request never touches the open Internet.
Alvarez Rosa describes the system as built by the nonprofit Tor Project, which advances human rights and freedoms through free software and open networks. He also notes that the network only works because people use it, encouraging readers to support the project or run a relay themselves.
Setting Up the Hidden Service
The setup begins with editing the Tor configuration file. On a standard Linux system, that file is /etc/tor/torrc. The two lines needed are simple:
HiddenServiceDir /var/lib/tor/blog/
HiddenServicePort 80 127.0.0.1:8080
The first line tells Tor where to store the service’s private key and hostname file. The second maps port 80 on the onion address to port 8080 on the local machine.
The directory must be a dedicated, Tor-owned path, not the web root. It is given strict permissions — chmod 700 — and owned by the debian-tor user. If you try to point the service at your actual web files, Tor refuses to start.
After restarting Tor, the system generates the address. The command looks like this:
sh
sudo systemctl restart tor@default
sudo cat /var/lib/tor/blog/hostname
The output is a long string of letters and numbers ending in .onion. In Alvarez Rosa’s case, the address is dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion.
Serving the Site Over Tor
The web server does not need to know it is running on the Dark Web. Tor handles the encryption and routing, so the server simply listens on the localhost address and port the configuration specifies.
For the server block, Alvarez Rosa uses nginx, though the example applies to any HTTP server. The configuration is minimal:
server {
listen 127.0.0.1:8080;
server_name dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion;
root /srv/tor.david.alvarezrosa.com;
index index.html;
error_page 404 /404/index.html;
location / {
try_files $uri $uri/ =404;
}
}
There is no TLS, no HTTP/2, no QUIC. Tor speaks plain TCP and provides its own encryption, so those features are unnecessary. The server just needs to respond to requests on the specified port.
Reload nginx and the site is live on Tor.
Building for the Onion
Here is where things get interesting. A static site typically bakes its base URL into every link, so a clearnet build would point visitors back to the clearnet domain even when served over Tor. The fix is to build a second copy with the onion as its base URL.
Alvarez Rosa uses Hugo as his static site generator, and the command to build the Tor version is straightforward:
sh
hugo --minify --baseURL="http://dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion/"
The deploy pipeline handles the rest. Every push builds the site once per target — clearnet and Tor — and rsyncs each to its own web root. The two copies stay in sync without any manual work.
The full configuration lives in his homelab repository, and the site’s own repository holds the GitHub Actions workflow that builds and deploys the Tor copy.
What This Means
The practical takeaway is that running a Tor hidden service is not some arcane trick. It is a series of configuration changes and a single build command away from being live. The barriers are administrative, not technical.
The broader context is the ongoing fight over online privacy. Tor protects against tracking, surveillance, and censorship, and Alvarez Rosa has made it accessible by showing exactly how it works.
“The network only works because people use it.”
That line from the source captures the core argument: the infrastructure depends on participation. Running a relay, hosting a hidden service, or simply using the browser are all contributions, and Alvarez Rosa’s example shows that hosting one’s own site on Tor is a viable option for anyone with a static site and a little patience.
The onion address is live now. Anyone with the Tor Browser can visit it, and the site reads the same as the clearnet version — except that the request never touches the open Internet.
It is a small act, but it demonstrates what is possible when the tools are laid bare.
Source material: “Self-Hosting on the Dark Web,” alvarezrosa.com.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.