Tor Node
I set up a Tor node as part of the infrastructure I want to run myself. It fits the same idea as tarsow.dev: use the systems I care about, understand how they operate, and document what I can verify.
The reason is simple. Tor needs operators willing to contribute machines, bandwidth, and maintenance. Reading about the network is useful, but running a node makes the operational questions concrete: updates, uptime, logs, bandwidth, abuse handling, and monitoring.
The Role Changes The Job
“Tor node” is not one precise role. The Tor Project's relay guide separates guard, middle, exit, and bridge relays because each position has different technical requirements and operational consequences.
A normal circuit can be simplified as:
Tor user -> guard -> middle -> exit -> destinationThe guard is the first relay and the middle carries traffic between circuit positions. The exit is the final relay before the public destination, so the destination sees the exit's address rather than the user's address. That makes exit operation different: abuse reports and legal questions arrive at the exit operator or hosting provider.
A bridge helps users reach Tor when public relay addresses are blocked. Bridges are not listed in the public relay directory in the same way as guard, middle, and exit relays. The official relay-type documentation is the useful starting point before choosing what to operate.
The resource plan changes with the role. The Tor Project's relay requirements say a guard or middle relay should handle at least 7,000 concurrent connections, provide at least 10 Mbit/s in both directions, and allow at least 100 GB of incoming and 100 GB of outgoing traffic each month. For an obfs4 bridge, it recommends at least 1 Mbit/s in both directions. A fast exit at 100 Mbit/s or more can exceed 100,000 concurrent connections, and Tor recommends at least 1.5 GB of RAM per exit instance. Those thresholds tell an operator whether the network connection, router, data cap, and host actually fit the chosen role.
What I Care About Operationally
My goal is to keep the node boring and stable:
- keep the operating system and Tor packages patched
- watch uptime without turning monitoring into unnecessary surveillance
- read Tor Project notices before an update or network change becomes urgent
- understand the configured role, bandwidth limits, and public exposure
- keep only the logs needed to operate the service
- plan for abuse handling before selecting an exit role
The Tor Project maintains a technical setup guide for relay operators. The commands depend on the operating system and role, but the larger lesson is consistent: installation is only the start. A useful node needs maintenance and enough stability for the network to rely on it.
A Relay Is Not An Onion Service
The tarsow.dev front page also links to an onion address. That is a different use of Tor from contributing a relay to the network.
An onion service publishes a service through Tor. The Tor Project's onion-service setup guide uses HiddenServiceDir for the service identity and HiddenServicePort to map an onion port to a local service.
I cover the website deployment in Nginx And This Site. The public repository contains the onion deployment code. Tor forwards the onion service to an nginx listener on loopback, and both the clearnet and onion machines publish the same static www/ tree. The Tor deployment script also verifies that Tor loaded the expected onion hostname before nginx is reloaded.
That onion-service configuration does not prove that the machine participates as a public relay. Keeping those roles separate avoids claiming network capacity that the repository does not document.
Why I Am Running It
Tor is not useful as an idea only. It needs software, protocol design, relay capacity, bridges, onion services, operators, documentation, and long-term maintenance.
For me, running part of that infrastructure is also a way to understand the system at its operational boundary. The useful questions are not only how a circuit works, but what happens when a package changes, a process stops, a key is restored with the wrong permissions, or a public role attracts abuse.
That is the same approach I use for the rest of this site: keep the component minimal, know what role it serves, and write down the failure modes I can actually support with evidence. The blog index is where I will keep those updates connected.