$ pwd
[$ ] use-case: tor-relay
// NAME
tor-relay — tor relay & bridge hosting.
// SYNOPSIS
xmrhost-cli playbook describe --workload=tor-relay
xmrhost-cli provision --workload=tor-relay --region=<is|ro>// TL;DR
$ head -n1 README
// operate a tor middle/exit relay or obfs4 bridge with bgp-stable uplinks and a sane abuse posture.
// DESCRIPTION
$ man playbook(tor-relay)
// BGP-stable uplink + AUP that doesn't churn the relay
A useful Tor relay needs three things the average shared-host VPS does not provide: a stable IPv4 with no churn against the consensus, a peering posture that does not drop CIDRs into RPKI invalid every other quarter, and an abuse desk that knows the difference between a §512(c) takedown and an exit-relay complaint. Iceland and Romania both sit on RIPE-managed PA space served from operator-controlled AS resources — relay-fingerprint stability is the default, not a feature you negotiate.
Exit operators specifically need cooperation on the §512-equivalent surface. Iceland processes copyright complaints under Höfundalög nr. 73/1972, with no DMCA-style first-strike termination machinery. Romania applies the EU DSA notice-and-action procedure, which requires a substantiated complaint with specific URLs before any takedown obligation arises. Neither chain auto-suspends on a generic abuse email. Middle relays and obfs4 bridges are uncontroversial on every plan and generate no abuse traffic worth mentioning.
Bandwidth is the practical scaling axis. A non-exit middle relay on a 1c/2GB tor-1 carries 30–50 Mbps sustained without saturating the vCPU; tor-2 (2c/4GB) hits ~100 Mbps; vps-4 saturates the 1 Gbps port if the network capacity is there. Tor scales poorly past ~1 GB resident memory due to circuit-state churn, so heavy middle-relay deployments benefit from vps-4 or larger rather than CPU-padded tor-* tiers.
// see also
- Tor Project — Relay Operations Guide (community.torproject.org/relay)
- RFC 7686 — The .onion Special-Use Domain Name (IETF, 2015)
- EFF — Tor Exit-Node Operator FAQ
- Tor Project — Reduced Exit Policy (gitweb.torproject.org)
// RECOMMENDED NODES
$ xmrhost-cli list --workload=tor-relay
// 6 plans flagged for this workload. all xmr-billed.
// RECOMMENDED REGIONS
$ xmrhost-cli regions list --workload=tor-relay
-
is — iceland : RIPE-managed PA space, FARICE-1 / DANICE submarine cables. Höfundalög nr. 73/1972 contains no §512 first-strike machinery — exit relays are not summarily terminated on a stock abuse email.
-
ro — romania : EU DSA notice-and-action requires a substantiated complaint; Romanian courts prefer narrow, evidence-backed takedowns. Voxility / Bitdefender DDoS-mitigation talent base in Bucharest.
// THREAT MODEL + AUP BOUNDARY
$ xmrhost-cli scope --workload=tor-relay
// the hosting layer is one component of the threat model. what we cover, and what we explicitly don't:
// scope: in
- BGP-level uplink stability — no IP churn against the consensus, RPKI-valid origin
- Abuse-handling that recognises tor-exit registration and the Reduced Exit Policy
- Non-DMCA notice-and-action procedure (Höfundalög nr. 73/1972 in IS, EU DSA in RO)
- Monero-only billing — no card descriptor, no on-chain BTC analytics correlation
// scope: out
- tor.conf hardening past the operator's shipped baseline (custom ContactInfo, MyFamily, etc.)
- Publishing a polite abuse-response policy on the relay's PTR or torproject directory
- Being a Tor Project sponsor — relay registration is the operator-customer's task
- Anything happening over the Tor circuit itself — exit-node liability scope is the operator-customer's
// AUP boundary
Exit-relay operators must register the exit with the Tor Project, publish a reasonable exit policy, and respond to abuse complaints within five business days. Persistent failure to address legitimate complaints results in termination without refund. Middle relays and bridges have no such obligation.
// SEE ALSO
// playbook — full workload list, node — full catalog, location — region posture, why-monero — billing rationale.