Self-Hosting on the Dark Web
- ID
- 29248
- Status
- summarized
- Published
- 28 Sep 2026, 4:03 AM
- Fetched
- 28 Sep 2026, 6:28 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://david.alvarezrosa.com/posts/self-hosting-on-the-dark-web/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 5.0
- Created
- 28 Sep 2026, 6:28 PM
- Tags
- Audience
- developersvibe_coders
What happened
David Álvarez Rosa documented turning his Hugo static site into a Tor hidden service, publishing the exact /etc/tor/torrc config (HiddenServiceDir /var/lib/tor/blog/, HiddenServicePort 80 127.0.0.1:8080), the chmod 700 / debian-tor ownership requirement that makes Tor refuse to start if pointed at your web root, and the resulting .onion address. The nginx server block listens on 127.0.0.1:8080 with no TLS, HTTP/2 or QUIC, since Tor speaks plain TCP and encrypts on its own. The interesting engineering bit is the build: because a static site bakes its base URL into absolute links, every push runs a second Hugo build with --baseURL set to the .onion and rsyncs each output to its own web root via GitHub Actions.
Why it matters
The reusable takeaway is not Tor itself, it's the dual-target build pattern: if your site or app hardcodes a base URL at build time, serving it from a second address (onion, staging domain, IPFS, internal mirror) silently sends visitors back to the primary domain. Copy the one-build-per-target + separate web root approach if you ever need to serve the same artifact from two origins. For everyone else, this is a homelab curiosity with no Malaysia or AI angle, and no action required.
Discussion angle
Base URLs baked in at build time break any second-origin deploy — how are you handling multi-target builds (onion, staging, regional mirrors) in your own pipeline, and is a rebuild-per-target better than runtime link rewriting?