When someone documents a year of running a Tor relay on a residential network, the exercise functions less as endorsement than as field report. The Tor Project’s documentation advises against exit relays on home connections but remains notably quieter about middle relays. The gap between what is documented and what operators encounter produces recurring patterns.
In this article
The Documented Position
The Tor Project’s abuse FAQ states plainly that in general, it is advisable not to use your home internet connection to provide a Tor relay. The relay guide is more specific: because of the legal exposure that comes with running an exit relay, you should not run a Tor exit relay from your home. Ideal exit relay operators are affiliated with some institution, like a university, a library, a hackerspace or a privacy related organization.
This guidance addresses exit relays explicitly. Guard and middle relays usually do not receive abuse complaints. The implication is that non-exit relays on residential connections occupy a different risk category. Many operators interpret this as tacit permission.
A non-exit relay should be able to handle at least 7,000 concurrent connections, and if you run it behind a consumer-level router at home you will have to try and see if your home router can handle it or if it starts failing. The phrase “try and see” appears in official documentation. That is the documented position: attempt it, observe the failure mode, adjust.
Consumer Hardware Meets Network Load
The 7,000 concurrent connection threshold is not arbitrary. Fast exit relays (greater than or equal to 100 Mbit/s) usually have to handle a lot more concurrent connections (greater than 100k). A middle relay operating at residential speeds pushes fewer connections, but consumer routers are not engineered for sustained connection-table churn.
Operators running relays at home report a recurring pattern: the relay stabilizes, begins to gain the Guard flag after weeks of uptime, and then the home router begins dropping connections intermittently. To become a guard relay, the relay has to be stable and fast (at least 2 MByte/s of upstream and downstream bandwidth) otherwise it will remain a middle relay. Once the Guard flag is assigned, connection load increases. Residential routers, especially models bundled with ISP contracts, do not handle this gracefully.
The result is not dramatic failure but degraded performance across the entire home network. Streaming stalls, VPN tunnels drop, SSH sessions time out. The relay itself continues to function, but the household experiences the relay as infrastructure burden. This is the point at which most home operators either throttle the relay’s bandwidth significantly or move it to dedicated hosting.
ISP Terms of Service and the Silence
Since non-exits do not attract complaints, it should be fine to run them without contacting the hoster first. This guidance applies to data center hosting. Home ISPs present a different surface. Residential terms of service frequently prohibit “servers” without defining the term. A Tor relay is server software; whether it constitutes a prohibited server depends on interpretation and enforcement appetite.
Operators running middle relays on residential connections report that most ISPs do not act unless bandwidth consumption becomes anomalous or unless a complaint arrives. Make sure you understand their policies regarding bandwidth, especially on “unlimited” (fair use) contracts. Unlimited consumer broadband is unlimited until it is not. Fair-use clauses are enforced selectively, often after the ISP notices sustained upload saturation.
The documented advice to contact your ISP proactively applies primarily to exit relays. For middle relays, many operators adopt a different strategy: run the relay at conservative bandwidth limits, monitor for ISP contact, and respond with explanation if questioned. This approach trades proactive transparency for operational simplicity. It works until it does not.
What the Year Reveals
As of July 2025, the Tor network runs around 8,000 active relays. Relay operators tend to plateau; many new relays appear, but retire quickly due to cost or maintenance burden. The pattern is visible in Tor Metrics data: a long tail of small relays that contribute briefly and then disappear, and a smaller set of institutional and dedicated hosting operators that provide the majority of stable capacity.
Home operators who run relays for a full year learn that the Tor network is sustained not by enthusiastic individuals on residential connections, but by operators who have moved to environments purpose-built for the load. The residential relay functions as onboarding: it teaches the operator what is required, and most operators then decide whether to commit resources to proper hosting or to step back.
Tor has no hard uptime requirement but if your relay is not running for more than 2 hours a day its usefulness is limited. Ideally the relay runs on a server which runs 24/7. A home relay on residential infrastructure competes with every other device on the network, with power interruptions, with router firmware updates that reboot the gateway without warning. Uptime becomes the forcing function. Operators who sustain a year of operation do so by treating the relay as production infrastructure, which makes the home environment legible as the wrong place for it.
The Architecture That Fits
The Tor network’s design assumes diversity: many operators, many jurisdictions, many network paths. Most of the Tor network runs on Linux, so we emphasize OS-level diversity and encourage people who can to run BSD-based OSes. Diversity is a defense against enumeration and targeted attacks. Residential relays contribute to geographic and network diversity, even if their operational lifespan is short.
For an email service operating over Tor, the relay operator’s experience is adjacent but distinct. Onion Mail routes traffic through circuits built from these relays. The reliability of those circuits depends on stable relays, which means relays hosted in environments that can sustain the load. When a user sends mail through Onion Mail, the message traverses three relays. If one of those relays is a home relay subject to residential router limitations, the circuit may rebuild mid-transmission. The user experiences this as latency or timeout.
Open-source post-quantum cryptography infrastructure such as PQCServer, released under AGPL-3.0, is designed for deployment in environments where the operator controls the full stack. A home network is not that environment. The lesson from running a Tor relay at home applies: infrastructure that must be reliable should be hosted where reliability is architecturally supported, not where it is aspirational.
What Remains After a Year
The operators who document a year of running a Tor relay at home consistently report the same conclusion: it is possible, it is educational, and it is not the optimal deployment model. The documentation that advises against home relays does so for reasons that become clear only through operation. Consumer hardware fails in specific ways under this load. ISPs tolerate middle relays until usage patterns trigger automated warnings. Household network quality degrades in proportion to relay traffic.
The Tor network does not forbid home relays. It documents the constraints and allows operators to choose. A year of operation converts the abstract constraints into operational knowledge. Most operators, having gained that knowledge, move the relay or shut it down. The small percentage who continue running home relays do so with bandwidth throttled low enough that the relay contributes marginally. That is the structural answer the network provides: if you want to run a relay that matters, host it properly.