Dedicated Servers for Tor Exit & Middle Relays

Tor relays are a distinctive workload. A middle relay at modest bandwidth (say 50-100 Mbps) processes millions of short-lived TCP connections per day, stressing the kernel's connection-tracking tables far more than most workloads. Exit relays additionally generate outbound traffic to arbitrary IPs, which upstream ISPs often flag as abuse even when the underlying traffic is benign. The infrastructure requirements are therefore: a host that tolerates high connection counts, a network that does not flag Tor egress as hostile, and an abuse process that can actually handle Tor-related complaints without knee-jerk suspensions.

Middle relays are the easy case. The Tor network needs many more middle relays than exits, they do not generate outbound traffic to third parties, and the abuse profile is near-zero. Almost any hosting provider will permit a middle relay. AnubizHost permits them without question and will pre-tune the kernel for the connection-count profile.

Exit relays are the hard case. Tor exit traffic includes everything Tor users do — web browsing, email, occasional abuse — and ends up in abuse reports the exit operator must handle. AnubizHost permits exits on specific networks with advance coordination so we can align on abuse-handling protocols, and we will work with operators who understand the responsibilities. We will not allow exits on networks where the upstream will not tolerate them.

Tor relay hardware priorities are unusual: you want many CPU cores (Tor is multi-threaded and scales with cores), enough RAM to hold large connection-tracking tables (32-64 GB is plenty), fast network processing (NIC with good driver support), and decent sustained bandwidth (1 Gbps unmetered is ideal, 10 Gbps is overkill but available for high-capacity exit relays).

Our Tor-optimized configurations default to Intel Xeon E-2388G (8 cores, 16 threads — excellent for Tor's threading model), 64 GB ECC RAM, 2x 1 TB NVMe, and 1 Gbps unmetered. For high-capacity exit relays targeting 500+ Mbps sustained, we offer AMD EPYC 7313P with 128 GB RAM and 10 Gbps unmetered — the same hardware as our Performance tier but with kernel tuning specific to Tor workloads.

Kernel tuning includes expanded nf_conntrack tables (we default to 2M entries for Tor servers), higher fs.file-max, raised somaxconn and tcp_max_syn_backlog, BBR congestion control, and sysctl hardening appropriate for a public-facing relay. We also apply Tor-specific optimizations from the Tor Project's recommended setup guide.

Tor relay pricing follows our standard dedicated tiers because the hardware requirements overlap significantly with general-purpose workloads. The Tor Starter at $89/mo — Intel Xeon E-2388G, 64 GB RAM, 1 Gbps unmetered — is sufficient for a middle relay sustaining 200-500 Mbps or an exit relay in a jurisdiction where exits are permitted on that network. The Tor Performance tier at $129/mo upgrades to AMD EPYC 7313P with 128 GB RAM for exit relays pushing 500 Mbps-1 Gbps sustained. The Tor Pro tier at $199/mo adds 10 Gbps unmetered for operators running high-capacity exits.

Tor relay operators get a 10% discount across all tiers with annual billing and a handshake: we ask that you email abuse@ with your contact info and exit policy so our abuse team knows who to reach when complaints arrive. Bitcoin, Monero, and Litecoin accepted; no KYC required.

For exit relay operators, the right process matters as much as the right hardware. On signup, indicate that the server will run a Tor exit and which networks you intend to allow (the ReducedExitPolicy is an excellent starting point). We will allocate the server on a network where our upstream tolerates exit traffic, and we will provide you with an abuse contact (you) that we route complaints to before taking any action.

When abuse complaints arrive, we forward them to you with a Tor-standard template response (the Tor Project maintains reference response templates) so you can reply to the complainant with the standard Tor exit disclaimer. We will not preemptively suspend your relay based on a single complaint, and we will work with you to handle edge cases reasonably.

Middle relay operators do not need this coordination — middle relays rarely generate abuse complaints, and we permit them by default on any of our networks. If you are new to running relays, we recommend starting with a middle relay for a month to get comfortable with the operational profile before applying for an exit allocation.

The Tor network depends on operators who can run relays reliably for years, and that depends on hosting providers who understand the workload and will not panic the first time a complaint arrives. AnubizHost has been running our own internal Tor services for years and permits community Tor relays on specific networks where our upstream relationships support them.

Our offshore jurisdictions (Netherlands, Finland, Romania) do not recognize US DMCA takedowns, which filters out the most common category of frivolous complaints that force exit operators off other networks. Our abuse team responds to legitimate complaints with care but does not suspend relays based on bot-generated reports or speculative claims.

Billing is crypto-first (Bitcoin, Monero, Litecoin) and requires no KYC, so relay operators can preserve pseudonymity. Combined with our kernel tuning for Tor workloads and our willingness to coordinate on exit policies, AnubizHost is among the small number of hosting providers where a Tor relay — especially a Tor exit — can realistically operate long-term. For operators donating bandwidth to the network, that longevity is what actually matters.