Self-Hosting on the Dark Web
A short tutorial details how to self-host a static blog as a Tor hidden service using Nginx and automated deployment pipelines.
summary is enough The post provides a clean, concise configuration blueprint, though the comment thread contains the most valuable security and performance hardening tips.
summary
This guide outlines the step-by-step process of exposing a personal static blog as a Tor hidden service using a local server, Nginx, and Hugo. The setup avoids traditional DNS and certificate authorities by relying directly on a cryptographic public key generated by Tor. An automated deployment pipeline builds dual copies of the site to keep clearnet and onion absolute links properly scoped. Discussion participants expand on this by recommending the Onion-Location header for automatic redirection and discussing performance optimizations for high-latency onion networks.
key points
- Tor hidden services use cryptographic public keys instead of traditional DNS and CAs, requiring no TLS certificate because Tor handles end-to-end encryption natively.
- A static site generator must build a separate copy with the .onion address as the base URL to prevent absolute links from leaking visitors back to the clearnet.
- Participants note that optimizing onion sites requires minimizing HTTP requests and inlining assets since multi-request overhead degrades performance over Tor.
who should read it
Self-hosters and privacy-conscious engineers interested in deploying services outside traditional DNS and cloud infrastructure.
discussion warm
consensus
Most participants praise the minimalist setup while offering practical hardening advice, such as adding the Onion-Location header and binding services to specific local IP addresses.
pushback
Some critics highlight that Tor's lack of CA-issued certificates blocks HTTP/2 support, while others warn about the risk of sudden network-wide deprecations like the past removal of v2 onion services.
What I really love about Onion sites is that if they are big enough, performance engineering really becomes Tor-specific. A few examples:
- Making assets embedded as base64 (img src the header logo as base64, all CSS should be inline, etc.).
- Leveraging CSS as much as possible (if you use animations and transitions, use CSS as much as possible for these, avoid JS for them).
- Make sure your website is mostly rendered on the backend. If you're to have JS, your website should work without it.
- Security becomes REALLY fun, as in, avoid XSS, CSRF, SQL Injection attacks and any other …
It details concrete performance engineering strategies specifically tailored to overcome the high-latency constraints of the Tor network.
Generated by an LLM from the article and thread. Check the sources before relying on it.