Privacy · no KYC
Host Tor Relay on an Offshore VPS
Run a non-exit Tor relay on unmetered offshore bandwidth and strengthen the network that millions rely on for private, uncensored access.
What it is
A Tor relay is a volunteer-run node that forwards encrypted traffic across the Tor network, adding capacity and diversity so the privacy system stays fast and resilient. A middle/guard (non-exit) relay never connects to destination websites on your behalf, so your IP is never the visible source of anyone's traffic.
Why host it offshore
Tor relays live or die on bandwidth, and metered hosts throttle or bill you into oblivion the moment a relay gets busy. ChainVPS gives you truly unmetered transfer, DDoS filtering, and crypto/no-KYC signup, so you can run a high-consensus-weight relay in a privacy-friendly jurisdiction without a billing surprise or an identity trail.
The deploy
A working reference setup
Copy this onto a fresh ChainVPS instance. Replace the placeholders, then bring it up.
#!/usr/bin/env bash
# Non-exit Tor relay on Ubuntu 24.04 (Noble). Run as root or with sudo.
set -euo pipefail
# 1) Install Tor from the official Tor Project apt repo (newer than Ubuntu's)
apt-get update
apt-get install -y apt-transport-https gpg curl lsb-release
curl -fsSL https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
| gpg --dearmor -o /usr/share/keyrings/tor-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org $(lsb_release -cs) main" \
> /etc/apt/sources.list.d/tor.list
apt-get update
apt-get install -y tor deb.torproject.org-keyring nyx
# 2) Configure a NON-EXIT relay (safe default: never terminates traffic)
cat > /etc/tor/torrc <<'EOF'
Nickname chainvpsrelay
# ORPort 443 improves reachability for clients behind restrictive firewalls.
ORPort 443
ORPort [::]:443
# Non-exit relay: do NOT exit traffic to the clearnet.
ExitRelay 0
IPv6Exit 0
ExitPolicy reject *:*
# ContactInfo lets the Tor project reach you about issues. Use a role address.
ContactInfo tor-relay-ops <[email protected]>
# Optional throughput cap (bytes). Comment out to donate full unmetered link.
# RelayBandwidthRate 20 MBytes
# RelayBandwidthBurst 40 MBytes
Log notice syslog
User debian-tor
EOF
# 3) Open the firewall for the ORPort (adjust if you changed it above)
if command -v ufw >/dev/null 2>&1; then
ufw allow 443/tcp comment 'Tor ORPort'
fi
# 4) Enable and start
systemctl enable --now tor@default
sleep 5
systemctl status tor@default --no-pager || true
echo "Relay starting. Watch bootstrap + fingerprint: journalctl -u tor@default -f"
echo "Live console: nyx"
echo "Your relay fingerprint: cat /var/lib/tor/fingerprint"
Firewall
Ports to open
| Port | Protocol | Purpose |
|---|---|---|
| 443 | TCP | ORPort — inbound relay traffic (use 9001 if 443 is taken by a web server). Must be reachable from the internet. |
| 9001 | TCP | Conventional default ORPort alternative if you prefer not to use 443. |
| 9051 | TCP | Tor control port (localhost only) — used by nyx monitoring; never expose publicly. |
Right-sizing
Which plan you need
VPS Nano/Small (1 vCPU, 1-2 GB RAM)
Fine for a starter middle relay pushing up to ~20-50 Mbit/s. Tor is single-threaded per relay, so a modest core is enough at low load.
VPS Pro (2-4 vCPU, 4-8 GB RAM)
Handles a well-connected guard relay saturating a few hundred Mbit/s; extra cores let you run 2 tor instances (2 per IPv4 max) to use more bandwidth.
Dedicated (multi-core + 1 Gbit unmetered)
For a high-consensus-weight fast guard/exit-class node or multiple relay instances pushing 1 Gbit+. TLS crypto is CPU-bound, so favor higher clock speed over core count.
Best locations: Privacy-tier locations suit relays best: the Netherlands, Romania, Iceland, and Switzerland are relay-friendly jurisdictions with strong network capacity and a track record of tolerating Tor traffic. Iceland and Switzerland add strong data-protection law, while NL/RO give you the fattest, cheapest unmetered pipes for maximum consensus weight. Spread relays across different locations/ASes to improve network diversity — the Tor network deliberately avoids routing a circuit through two relays in the same /16 or family.
Lock it down
Hardening checklist
- Start as a NON-EXIT relay (ExitRelay 0, ExitPolicy reject *:*). Exit relays generate abuse complaints and legal exposure — only run one deliberately, with provider consent and a dedicated IP.
- Set an honest ContactInfo and, if you run multiple relays, declare them with the MyFamily option (list every relay's fingerprint) so Tor never chains two of your nodes in one circuit.
- Bind the control port to localhost only (ControlPort 9051 + CookieAuthentication 1) and never open 9051/9030 to the internet; only the ORPort should be publicly reachable.
- Keep tor patched from the official Tor Project apt repo (not Ubuntu's older package) and enable unattended-upgrades — relay security fixes matter for the whole network.
- Run tor under its own unprivileged user (debian-tor, the package default), enable a firewall allowing only the ORPort, and monitor health with nyx and the Tor Metrics/Relay Search page using your fingerprint.
- If you cap throughput, use RelayBandwidthRate/Burst rather than the accounting quota so the relay stays up 24/7 — uptime is what earns the Guard flag and real consensus weight.
Deploy it on
The right ChainVPS product
Questions
Hosting Tor Relay — FAQ
Is running a Tor relay legal, and will it get me in trouble?
Running a non-exit (middle/guard) relay is legal in most jurisdictions and is very low-risk: your server only forwards encrypted traffic between other Tor nodes and never connects to destination websites, so your IP never appears as the source of anyone's browsing. Abuse complaints almost always target exit relays, which this setup explicitly disables.
What's the difference between a relay, a bridge, and an exit?
A middle/guard relay forwards traffic inside the network. A bridge is an unlisted entry point that helps users in censored regions connect (run the thetorproject/obfs4-bridge image for that). An exit relay is the final hop to the clearnet — the highest-risk role that draws abuse notices. This guide deploys a safe non-exit relay by default.
How much bandwidth will it actually use?
A busy guard relay can push hundreds of Mbit/s continuously once it earns network trust, which is exactly why unmetered transfer matters — a metered host would bill or throttle you. You can cap it with RelayBandwidthRate, but leaving it uncapped on ChainVPS's unmetered link maximizes your contribution.
How long until my relay is actually used?
New relays ramp up slowly. Tor measures your stability and speed over days; expect meaningful traffic after roughly a week and the Guard flag after about 8 days of solid uptime. Keep it running 24/7 — restarts and downtime reset your reputation.
Can I run more than one relay on the same server?
Yes — up to two relay instances per public IPv4 address. Give each its own ORPort and DataDirectory, and list all their fingerprints under MyFamily so the network never routes a single circuit through two of your nodes. A dedicated server with a 1 Gbit unmetered link is ideal for this.
More to self-host
Other one-click stacks
Spin up Tor Relay
in the next 60 seconds.
Unmetered bandwidth · DDoS included · 21 cryptocurrencies · no KYC.