Run a Tor relay on a private VPS

Why run a Tor relay

Tor is run by volunteers. Every circuit a user builds passes through three relays, and each of those is a server someone chose to operate. The more relays there are — and the more geographically and organisationally diverse they are — the harder the network is to observe or degrade. Running a relay on a VPS you rent anonymously is a direct, measurable contribution: it adds capacity for everyone, not just for you.

A relay is not a client and not a bridge. It advertises itself in the public consensus, so anyone can see it exists — that is the point of a relay, to be a known hop. If you want something unlisted for censorship circumvention, that is a bridge, a different configuration; this page is about public relays.

Non-exit by default

A relay can hold three positions in a circuit: guard (entry), middle, and exit. Guard and middle relays only ever forward traffic to other Tor relays — encrypted, and never out to the open internet. From the outside world’s point of view, a middle relay only ever talks to other Tor nodes. That means no third-party traffic leaves your IP address, and you will essentially never receive an abuse complaint for running one.

New relays start life as middle relays automatically. After a few days of stable uptime, the directory authorities may promote yours to the guard position based on measured reliability — you don’t configure that, you earn it by staying online. Run a non-exit relay unless you have a specific reason and the standing to run an exit. It is the safe, useful default, and the network needs guard/middle capacity constantly.

Exit relays carry real exposure

An exit relay is the last hop before traffic reaches its destination, so the destination sees the exit’s IP — not the user’s. That is what makes exits valuable and what makes them risky: complaints, takedown notices, and law-enforcement contact about traffic you did not generate land on the exit operator. Exits are best run by organisations with legal footing, a separate IP range, and a documented relationship with their host — not casually on a personal box.

If you are considering an exit, clear it against our Acceptable Use Policy and talk to our abuse desk before you flip ExitRelay on. Whether exit relays are permitted is governed by our AUP — check it before enabling one. We are a privacy host with a published AUP and a real abuse process — not a “no questions asked” host — and exit traffic changes what that desk has to field on your behalf.

Set up a middle relay

The steps below stand up a non-exit relay on Ubuntu/Debian. Install tor from the Tor Project’s own repository rather than the distro package, which is often several versions behind — relays should run current tor.

# add the official Tor Project repository (Ubuntu/Debian)
sudo apt install -y apt-transport-https
# follow the current keyring + sources steps at:
# https://support.torproject.org/apt/
sudo apt update && sudo apt install -y tor deb.torproject.org-keyring

Then edit /etc/tor/torrc:

sudo nano /etc/tor/torrc

A minimal, explicit non-exit relay:

Nickname             tldbunkerRelay01
ORPort               9001
ContactInfo          [email protected]
RelayBandwidthRate   10 MBytes
RelayBandwidthBurst  20 MBytes
ExitRelay            0
SocksPort            0

• Nickname — any 1–19 character name, letters and digits only.
• ContactInfo — a real address you monitor. It is not for spam; directory authorities and researchers use it to reach operators about problems. Use a role alias if you would rather not publish a personal address.
• RelayBandwidthRate / Burst — cap sustained and peak throughput so the relay lives within your plan’s monthly transfer allowance (shown on the pricing page).
• ExitRelay 0 and SocksPort 0 make it unambiguous that this box forwards Tor traffic only and is not an exit or a client proxy.

Open the ORPort in your firewall and restart tor:

sudo ufw allow 9001/tcp
sudo systemctl restart tor@default
sudo journalctl -u tor@default -f

Verify it’s live

Watch the log for the line that confirms your ORPort is reachable:

Self-testing indicates your ORPort is reachable from the outside. Excellent.

Your relay’s fingerprint is written to /var/lib/tor/fingerprint. A few hours after it joins the consensus, search for that fingerprint (or your nickname) on the Tor Project’s public Relay Search / metrics. Once it shows up there with rising bandwidth, you are carrying real traffic.

Bandwidth matters more than CPU

A relay’s job is to move bytes, not to compute. Modern tor offloads the heavy crypto to AES-NI, so even a nano box rarely runs out of CPU before it runs out of network. What actually limits you is throughput and, more importantly, your monthly transfer allowance — a relay pushing traffic around the clock can consume a large volume every month. Set RelayBandwidthRate deliberately so a busy relay doesn’t blow past your quota. If you want to donate more capacity, scale the box up rather than uncapping bandwidth blindly.

Good-operator etiquette

• Keep it online. Churn hurts the network; a relay that appears and vanishes is worth little. Commit to running it for the long term.
• Keep tor updated. Security fixes matter for infrastructure the whole network relies on.
• Set honest ContactInfo and answer messages about your relay.
• Use MyFamily if you run more than one relay, listing every fingerprint, so clients never pick two of yours in a single circuit.
• Don’t become an exit by accident — leave ExitRelay 0 unless you have deliberately, and with our sign-off, decided otherwise.
• Pay privately. The server itself is no-KYC and payable in Monero, so operating a relay doesn’t tie the box to your identity.

Running a middle or guard relay is one of the cleanest ways to give back to a network you may already rely on: low risk, low maintenance, and genuinely useful the moment it comes online.