Self-hosting an onion site: the torrc, the keys, and the mistakes that leak identity
Running your own onion site is mechanically simple: a few lines in torrc, a web server bound to localhost, and a 56-character address you can hand out freely. Staying anonymous while doing it is where nearly everyone slips. This guide covers the daemon configuration, key handling, and the operational basics that decide whether a service lasts.
The minimal torrc that works
The Tor Project's own setup guide reduces the whole exercise to two directives: HiddenServiceDir, which points at a directory where the daemon stores its keys, and HiddenServicePort, which maps a virtual port to a local listener such as 127.0.0.1:8080 (community.torproject.org). Restart tor and the hostname file appears. That really is the core of it. Two refinements are worth making on day one. Point HiddenServicePort at a Unix socket instead of a TCP port so nothing else on the box can reach the backend, and set SocksPort 0 on a pure service host so the daemon serves rather than proxies. The tor manual documents both options, along with OnionServiceSingleHopMode, which trades anonymity for latency and should stay off for anything serious (tor(1) manual).Your keys are your identity
In the v3 protocol, the .onion address is not a name registered anywhere; it is the Base32 encoding of the service's ed25519 master identity key. Whoever holds private_key_ed25519 holds the address, full stop. The rendezvous specification spells this out: the master key signs blinded keys, which sign descriptor signing keys, layer by layer (Tor rend-spec). That has one blunt consequence the Tor ecosystem checklist states plainly: if the keys leak, the attacker can impersonate your service indefinitely, and recovery means generating a new address and losing your audience (Onion Services checklist). Keep an encrypted backup off the server, restrict file permissions, and never let CI systems or shared provisioning pipelines touch the main key. Full offline master keys remain on the roadmap rather than in the daemon, so treat the host storing them as the crown jewels.Bind to localhost and audit what the app reveals
Most real-world deanonymizations are application-layer blunders, not crypto breaks. The checklist's hardening table maps each omission to its failure mode: a web server reachable outside Tor, verbose error pages with paths or versions, and logs containing client metadata all feed investigators directly. Configure the backend to answer only on the loopback interface, check the Host header against your onion address, and strip Server and X-Powered-By headers. Reused configurations and identical code across multiple onion services are equally dangerous, because shared fingerprints link otherwise unrelated sites and their operators. The same applies to clearnet mirrors: a shared analytics tag, a matching TLS certificate, or even similar uptime patterns can tie the two together. Diversify deliberately.Guard discovery is the network-level threat
Anyone on the network can force an onion service to build circuits repeatedly until an adversary's relay lands next to its guard, then confirm the match through timing side channels and compromise or surveil that guard. Mike Perry's vanguards addon pins the second and third hops of service circuits to small rotating sets, stretching a guard discovery attack from minutes to weeks or months even for an adversary running five percent of the network (Tor Project blog). For larger deployments, the addon's security documentation recommends OnionBalance with isolated publisher nodes holding the master keys, while backends never touch them, plus continuous monitoring of reachability because downtime itself is a side channel (vanguards README_SECURITY.md). If you are new to the model, our primer on how onion services work explains the rendezvous dance behind all of this.A short list of identity leaks worth checking tonight
- Clearnet exposure: any port on the host reachable from the public internet correlates the onion service with an IP.
- Chatty defaults: directory listings, stack traces, version banners, and default 404 pages all narrow the haystack.
- Careful logs kept carelessly: access logs with timestamps aligning to uptime analysis are a correlation gift.
- Shared infrastructure: reused code, themes, certificates, or hosting patterns across services link them forever.
Before worrying about advanced attacks on the Tor network, make sure your service is not leaking basic information at the application layer. That is the checklist's first principle, and it remains the most commonly violated one.