# Published the site as a Tor onion mirror on a readable address beginning engineer, with the key generated off the host so it never reached this repository or a laptop, and left it the one front door of four that is never counted.

September 2026

**Situation.** The site already answered on three protocols from one build. A reader who needed to reach it without revealing that they had reached it was still making an exit‑node round trip to an ordinary address, which is a weaker thing than a front door of its own. The obvious objection to a fourth door is the firewall, and it does not apply: the anonymity daemon reaches the network by making outbound circuits, so nothing dials in, no port opens, and neither firewall layer has anything to synchronise.

**Task.** The mirror had to serve the same pages as the ordinary address, be published wherever the other mirrors are published, carry an address a person can read aloud rather than a random string, and never let the private key that is the address touch this repository or a laptop.

**Action.** The role installs the daemon from the distribution's own package, writes a configuration with the outbound proxy port switched off, and declines to overwrite an identity it did not generate -- so a key placed by hand is simply used. A readable address cannot be chosen, only found: the address is the public key in base32, so a prefix is bought by generating keypairs until one of them happens to encode the letters wanted, and each character costs thirty‑two times the one before it. The prefix that was bought reads as the company's own name. The address is a declared value in the inventory and every converge asserts the host's real identity file matches it, so a swapped key with a stale declaration fails the run rather than going quiet. The key is caught by both secret guards, after it was measured that the obvious pattern for a key file matches a deploy key and misses this one. Retiring the random address the mirror had shipped with was a staged cutover rather than a switch, so the published address kept working while the readable one was being published. The step that looked like the last one was not: the key landed correctly and the converge reported no change, because nothing yet named the new directory, so the new address was never published at all -- the role now fails on an identity on disk that no service names.

**Result.** The site has four front doors onto one build, and this is the only one that is never counted. Gemini requests and Gopher connections are tallied per day with no address and no path; the onion has no counter and no flag to add one, because counting a reader there is the single thing that protocol exists to prevent, and the blindness is the price of the posture rather than a gap in the reporting. The mirror also paid for itself as a second opinion: its first readers were on a different browser engine, which does not implement the scroll‑driven animation the footer relied on, so every one of them got the colophon painted across the front page. That was a real defect on the ordinary site, found by the audience that had no other way to report it.

---

- Role: Network and DNS Engineer
- Categories: [Web Development](https://engineer.company/categories/web-development/), [Infrastructure](https://engineer.company/categories/infrastructure/), [Linux & Servers](https://engineer.company/categories/linux/), [Security](https://engineer.company/categories/security/), [System Administration](https://engineer.company/categories/system-administration/)
- Services: [Website Development & CMS](https://engineer.company/services/web-development/), [Infrastructure as Code](https://engineer.company/services/infrastructure-as-code/), [System Administration](https://engineer.company/services/system-administration/), [Security & Access Management](https://engineer.company/services/security-access/)

<https://engineer.company/portfolio/published-the-site-as-a-tor-onion-mirror-on-a-readable-168/>
