How to run a Tor relay on a VPS

Every Tor relay falls into one of three roles, and the role determines both your risk profile and how much abuse mail you will see.

• Middle relay — relays encrypted traffic between other relays. It never talks to the open internet or to clients directly, so its IP never appears as the source of anything. This is the lowest-risk, highest-value way to contribute: zero abuse complaints, no special policy needed. Start here if you are new.
• Guard (entry) relay — the first hop in a circuit. A relay is promoted to Guard automatically by the directory authorities once it has been stable and fast for long enough; you do not opt in. Guards see client IPs but not destinations, and like middle relays they generate essentially no abuse mail.
• Exit relay — the last hop, which connects out to the destination on the user's behalf. Because the exit's IP is what the destination sees, the exit's IP catches the abuse reports, scanning alerts, and occasional legal notices for everything that flows through it. Exits are the scarcest and most valuable relays, and the most operationally demanding.

NoKycVPS allows all three. Tor relays and exits are named explicitly in our acceptable use as permitted, alongside I2P, mixnets, VPN exits, and crypto nodes. We do no proactive content monitoring and act only on a binding judicial order from a court with jurisdiction over our operating entity in Saint Kitts and Nevis, with customer notification first and a monthly warrant canary. The one hard line is CSAM. If you want to run an exit without becoming the abuse desk, see our dedicated Tor exit node hosting page and pick a jurisdiction deliberately.

A Tor relay is not CPU-hungry in the way a build server is, but it does want steady CPU for the AES and circuit-handshake crypto, and above all it wants bandwidth and a stable IP. Tor weights relays by observed throughput, so a relay that can move more traffic carries proportionally more of the network. RAM and disk are almost irrelevant — a relay barely touches disk and uses a few hundred MB of RAM.

• Small middle relay / learning — the S1 (2 vCPU / 4 GB DDR5 / 80 GB NVMe, from $5/mo) is plenty. Cap it with RelayBandwidthRate 5 MBytes and you have a useful, no-maintenance relay.
• Serious relay or exit — the S2 Pro (4 vCPU / 16 GB / 320 GB, from $15/mo) is the sweet spot. With 10 Gbps unmetered uplink it can push a fast relay without the CPU becoming the bottleneck. This is the plan most operators want.
• High-capacity / multiple exits — the S3 Power (8 vCPU / 32 GB / 640 GB, from $30/mo) or a dedicated R1/R2 for operators running several relays under one MyFamily.

All NoKycVPS plans include a /64 IPv6 block, AMD EPYC cores, and up to 10 Gbps unmetered network. Network is unmetered, so you will not get a surprise bandwidth bill — but you should still set RelayBandwidthRate so your relay advertises a capacity it can sustain rather than burst to and then choke. Order from /order/?product=vps and pay in Monero (XMR); the balance credits in about 30 seconds.

Do not use the distro's stock tor package — it lags upstream by months. Add the official Tor Project repository so you get current builds and security fixes promptly. On Debian 13 / Ubuntu 24.04:

# become root
apt update && apt install -y apt-transport-https curl gpg

# add the Tor Project signing key
curl -fsSL https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor -o /usr/share/keyrings/tor-archive-keyring.gpg

# add the repo (replace 'bookworm' with your codename if needed)
cat > /etc/apt/sources.list.d/tor.list <<'EOF'
deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org bookworm main
EOF

apt update
apt install -y tor deb.torproject.org-keyring nyx

This installs tor as a systemd service running under its own unprivileged debian-tor user, plus Nyx, the terminal monitor we use later. Confirm the binary is current with tor --version. Keep the box patched (unattended-upgrades) so the keyring and tor stay fresh.

The relay's entire behaviour lives in /etc/tor/torrc. A minimal, correct non-exit (middle/guard) relay looks like this:

# /etc/tor/torrc
Nickname        examplerelay          # 1-19 alphanumerics, your label on the network
ORPort          9001                  # the port other relays connect to
ORPort          [::]:9001             # also listen on IPv6
ContactInfo     tor-admin <at> example <dot> com   # obfuscated; abuse handlers use this

# bandwidth: sustained rate, with a higher short burst
RelayBandwidthRate   8 MBytes
RelayBandwidthBurst  12 MBytes

# OPTIONAL hard monthly cap (uncomment to limit total transfer)
# AccountingMax       8 TBytes
# AccountingStart     month 1 00:00

# group all relays you run so clients never use two in one circuit
MyFamily        $FINGERPRINT1,$FINGERPRINT2

# this node is NOT an exit
ExitRelay 0

Key fields, plainly:

• ORPort — the public port for relay-to-relay traffic. 9001 is conventional; any open port works. Open it in your firewall.
• Nickname — a human label, not unique, purely cosmetic on metrics sites.
• ContactInfo — set this. It lets abuse desks and the Tor Project reach you, and unreachable operators get deprioritised. Obfuscate the address against scrapers but keep it reachable.
• RelayBandwidthRate / Burst — the sustained rate Tor advertises and the short ceiling it will burst to. Set the rate to what your link genuinely sustains.
• MyFamily — fingerprints of every relay you operate (find yours in /var/lib/tor/fingerprint after first start). This prevents a single operator from being two hops in one circuit. On modern Tor you can use a shared FamilyId file instead; MyFamily still works and is widely understood.

Validate before restarting: tor --verify-config -f /etc/tor/torrc. Then systemctl restart tor@default && systemctl enable tor@default. Watch the log with journalctl -u tor@default -f — within a few minutes you want to see "Self-testing indicates your ORPort is reachable from the outside. Excellent."

To turn the relay into an exit, set ExitRelay 1 and define an ExitPolicy. Do not open everything. The single most useful and abuse-light option is the reduced exit policy, which blocks the ports that generate the overwhelming majority of complaints (SMTP/spam, common scanning targets, BitTorrent-heavy ranges) while still allowing web and most useful traffic:

ExitRelay 1
IPv6Exit 1

# Tor ships a curated 'reduced' policy — reference it directly:
# https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy
# or hand-roll a conservative one, e.g. web-only:
ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:25       # block outbound SMTP to kill spam complaints
ExitPolicy reject *:*

Abuse expectations, honestly: a middle relay produces essentially zero complaints. A reduced-policy exit on a busy IP typically draws a handful to a few dozen automated reports per day — DMCA notices, brute-force/scanning alerts from honeypots, and the occasional fraud-team email. A wide-open exit can draw hundreds and will get the IP listed on blocklists fast. Mitigations that work:

• Run the exit on a dedicated IP that hosts nothing else, and publish a DNS/web exit notice on port 80 so operators recognise it as a Tor exit.
• Pick the jurisdiction deliberately — see our offshore hosting regions; Iceland (no mandatory data retention) and Switzerland (FADP, outside 14-Eyes) are popular for exits.
• Set a real ContactInfo and answer abuse mail promptly; engaged operators rarely have problems.

NoKycVPS does not forward, monitor, or act on these complaints itself — we have no content monitoring and respond only to a properly served judicial order from a Saint Kitts and Nevis court, notifying you first. But the upstream network abuse desks will still email the ContactInfo on record, so run exits where you can handle that. The one absolute prohibition is CSAM; for that and other network-abuse rules see the acceptable use summary.

Once the relay is up, watch it live with Nyx (the successor to arm), which we installed earlier. Run it as the tor user so it can read the control socket:

sudo -u debian-tor nyx

Nyx shows real-time upload/download against your RelayBandwidthRate, current connections, circuit roles, log tail, and your relay flags (Running, Stable, Fast, Guard, Exit). If bandwidth flatlines at exactly your configured rate, you are saturated and could raise the cap; if it never climbs, the relay may still be ramping (new relays earn trust and traffic over the first 1-2 weeks).

For an outside view, look up your fingerprint on Tor Metrics (metrics.torproject.org/rs.html) — it confirms your relay is published in the consensus, shows the flags the directory authorities assigned, and graphs your advertised bandwidth. A healthy middle relay reaches Stable and Fast within days; Guard takes longer. Set up basic host monitoring too (a simple systemctl is-active tor@default check) so you know if the daemon dies. For deeper hardening of the underlying box, see our VPS hardening guide.