Self-Hosting on the Dark Web
Self-hosting websites as Tor onion services promises strong privacy, no exposed IP or DNS, and easy hosting even behind CGNAT, but comes with trade-offs like high latency, hard-to-share addresses, and fragile naming that can break en masse when protocols change. Commenters explore practical setup tips (Onion-Location headers, port and socket choices, monitoring, backups of private keys), performance strategies (minimizing chattiness, SSR, inline assets), and security concerns including phishing “fronts,” DDoS, and the risks of running exit nodes. Several argue that Tor’s design makes it a cleaner, more user-respecting alternative to today’s surveillance-heavy web, while others stress that its anonymity and infrastructure priorities make onion sites inherently ephemeral and unsuitable as the sole home for long-lived communities.
Practical Benefits & Use Cases
- Hosting an onion site avoids DNS, CAs, and public IP exposure; no port forwarding and works well behind NAT/CGNAT.
- Popular for personal blogs and small services from home, with IP privacy “by design.”
- Some like it partly for the “neatness” of saying they run a dark web site.
Setup, Tooling & Uptime
- Basic Tor hidden services are described as straightforward; main friction is CLI complexity for non-technical users.
- GUI tools like OnionShare and projects that auto-spawn hidden services aim to make “drop a folder, get a site” workflows possible.
- Onion-Location headers are widely recommended so Tor Browser can auto-switch users to the onion copy.
- Uptime should be handled with standard monitoring; otherwise outages go unnoticed for long periods.
- Fresh/restarted onion services can be slow to become reachable; bridges (obfs4, Snowflake) are needed where Tor is blocked.
Security, Anonymity & Trust
- Hidden services do not make you an exit node; you can’t “accidentally” run an exit. Combining exit + hidden service is discouraged.
- Debate over whether governments can reliably deanonymize Tor: some insist only sloppy opsec is usually exploited; others speculate on undisclosed capabilities.
- Site fronting (malicious onion proxies) is a recognized problem; mitigations include off-site address verification, CAPTCHAs that encode parts of the real URL, chains of trust, and vanity onion addresses.
- Backing up the onion private key is critical; losing it forces a new address.
Performance & Architecture Choices
- Latency is high; static or mostly-SSR sites work best.
- Guidance: minimize HTTP requests, keep connections alive, inline CSS, use CSS over JS for UI, avoid chatty frontends.
- Opinions differ on base64-embedded assets: helpful on Tor, less so on modern clearnet where caching and HTTP/2 shine.
- HTTP/2 can improve performance but requires TLS; free certs for .onion are lacking, prompting discussion of treating self-signed certs as trusted for onion.
Limitations, Risks & Ephemerality
- Onion addresses are hard to remember or share verbally, and not human-meaningful.
- Deprecation of v2 onions is cited as proof that “everything on .onion is ephemeral”; some see this as necessary security progress, others as catastrophic link rot unique in scale.
UX, Accessibility & Broader Web Context
- Tor is often slower, especially for chatty sites, though some report acceptable speeds once circuits are established.
- Non-technical users face a steep learning curve, but some argue learning core commands is a reasonable expectation.
- Comparisons with the “clearnet” criticize ad/surveillance-driven design, aggressive anti-bot/CDN frontends, and scraping for AI training; onion sites are praised as lean, text-friendly, and free of tracking.
- Some prefer terms like “free web” over “dark web.”