Relay, bridge or Snowflake: what you can run here
The Tor network needs three kinds of volunteer capacity. Middle (and eventually guard) relays carry traffic between other Tor nodes and are listed publicly. Bridges are unlisted entry points with an obfs4 pluggable transport that disguises the traffic, handed out to people in censored countries. Snowflake proxies are the lightest option: a WebRTC proxy that needs no open ports and helps the same users. All three are welcome on BitVPS.
Exit relays are not. Exits are the final hop whose IP address appears on the destination website, and they draw abuse complaints and legal notices to the operator and the hosting provider. The BitVPS acceptable use policy does not permit Tor exit nodes; the configurations below set ExitRelay 0 and an explicit reject-all exit policy, and you should keep it that way. A middle relay or bridge almost never generates a complaint.
A VPS is the right place for a relay: a non-exit relay should handle at least 7,000 concurrent connections, which consumer routers struggle with, and the Tor Project asks for 16 Mbit/s each way and a stable IPv4 address. A datacenter uplink gives you all of that. Paying in Bitcoin without an account keeps your name out of the hosting record; the relay’s fingerprint and IP are public by design, so decide what ContactInfo you are comfortable publishing.
Sizing and the bandwidth budget
Tor itself is undemanding: the relay requirements page asks for 512 MB of RAM below 40 Mbit/s and 1 GB above, 200 MB of disk, and the ability to move at least 100 GB a month. The number that matters on a VPS is the monthly traffic allowance. Every BitVPS plan includes 20 TB of outbound traffic a month with inbound free, and a relay sends roughly as much as it receives.
- 20 TB in a 30-day month is about 7.7 MB/s (62 Mbit/s) sustained. RelayBandwidthRate 6 MBytes caps outbound at about 15.5 TB a month and leaves room for the OS and your own use.
- AccountingMax 18 TBytes with a monthly AccountingStart is the hard stop: Tor hibernates when the limit is reached and wakes up at the start of the next period. The Tor Project prefers a fast relay for part of the month to a slow one all month.
- A bridge sees far less traffic, typically tens to a few hundred GB a month. The same caps do no harm.
- CPU: Tor’s cell crypto is largely single-threaded, so two shared vCPUs carry a 50 Mbit/s relay comfortably; a faster core helps more than extra cores.
BVX11 (2 vCPU, 2 GB RAM, 40 GB NVMe, from $10/mo in Europe) or BVCX23 (2 vCPU, 4 GB, 40 GB, $11/mo) is all a relay or bridge needs. The Tor Project repository publishes amd64 and arm64 packages, so BVA11 ($12/mo) works too. A large share of relay capacity already sits in Germany; a relay in Helsinki, Ashburn, Hillsboro or Singapore adds geographic diversity, which the network values more than another one in Falkenstein.
Prepare the server
Everything below assumes a fresh Ubuntu 24.04 image and a root shell (prefix sudo if you created a user). Patch first, then lock down SSH and the firewall before anything else is listening.
apt update && apt full-upgrade -y
apt install -y ufw unattended-upgrades curl gnupg
# SSH: keys only. Put your public key in /root/.ssh/authorized_keys first and
# confirm you can log in with it before disabling passwords.
cat > /etc/ssh/sshd_config.d/00-keys-only.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
sshd -t && systemctl restart ssh
# Firewall: deny everything inbound except SSH for now.
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw --force enableInstall Tor from the Tor Project repository
The Tor Project explicitly asks relay operators not to use Ubuntu’s universe package, which has not been reliably updated; use their repository, which carries the current stable release for noble on amd64 and arm64. The signing key fingerprint is A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89; check it against the support page on torproject.org before trusting it. obfs4proxy (the project is now called lyrebird; the Debian package keeps the old name) and nyx come from Ubuntu.
apt install -y apt-transport-https gnupg
curl -fsSL https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
| gpg --dearmor -o /usr/share/keyrings/tor-archive-keyring.gpg
gpg --show-keys /usr/share/keyrings/tor-archive-keyring.gpg
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 noble main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org noble main
EOF
apt update
apt install -y tor deb.torproject.org-keyring obfs4proxy nyx
tor --versionThe deb.torproject.org-keyring package keeps the repository key updated through apt from here on. The package runs Tor as the debian-tor user with /var/lib/tor as its data directory and starts it on boot; you only edit /etc/tor/torrc and restart. Decide now whether this server is a relay or a bridge: a bridge on the same IP as a listed relay is trivially discoverable, so run one or the other per server.
Middle relay: torrc with bandwidth caps
Replace the stock torrc with the one below. Nickname and ContactInfo are published in the relay descriptor; the Tor Project uses ContactInfo to reach you about problems, and relays without one are treated with suspicion by the network health team. ORPort 9001 is the conventional choice; 443 is also common and the packaged service has the capability to bind it. Add the IPv6 line with your server’s real address once you have confirmed IPv6 works.
cat > /etc/tor/torrc <<'EOF'
Nickname PickANickname
ContactInfo [email protected]
ORPort 9001
# ORPort [YOUR_IPV6_ADDRESS]:9001
SocksPort 0
# This is a middle relay. Exits are not permitted on BitVPS.
ExitRelay 0
ExitPolicy reject *:*
# Stay inside the 20 TB monthly allowance (values are bytes, not bits).
RelayBandwidthRate 6 MBytes
RelayBandwidthBurst 12 MBytes
AccountingStart month 1 00:00
AccountingMax 18 TBytes
# For nyx and your own inspection only.
ControlPort 9051
CookieAuthentication 1
Log notice file /var/log/tor/notices.log
EOF
ufw allow 9001/tcp
systemctl restart tor@default
sleep 20 && tail -n 20 /var/log/tor/notices.logWithin a few minutes the log should show "Self-testing indicates your ORPort is reachable from the outside" and then "Performing bandwidth self-test". Your fingerprint is in /var/lib/tor/fingerprint. Expect very little traffic in the first week; new relays are measured and ramped up gradually, and the Guard flag takes weeks of stable uptime.
obfs4 bridge: torrc and the bridge line
A bridge runs the same Tor daemon with BridgeRelay 1 and the obfs4 transport in front of it. Pick two unused high ports, one for the ORPort and one for obfs4, and avoid 9001 because censors scan for it. BridgeDistribution any lets the Tor Project hand the bridge out through whichever channel needs it. The bandwidth block from the relay config applies unchanged.
cat > /etc/tor/torrc <<'EOF'
BridgeRelay 1
BridgeDistribution any
Nickname PickANickname
ContactInfo [email protected]
ORPort 34521
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:48213
ExtORPort auto
SocksPort 0
ExitRelay 0
ExitPolicy reject *:*
RelayBandwidthRate 6 MBytes
RelayBandwidthBurst 12 MBytes
AccountingStart month 1 00:00
AccountingMax 18 TBytes
ControlPort 9051
CookieAuthentication 1
Log notice file /var/log/tor/notices.log
EOF
ufw allow 34521/tcp && ufw allow 48213/tcp
systemctl restart tor@default
sleep 20 && grep -E 'obfs4|reachable|fingerprint' /var/log/tor/notices.log
cat /var/lib/tor/pt_state/obfs4_bridgeline.txt # the line you give to users
cat /var/lib/tor/hashed-fingerprint # look it up at bridges.torproject.org/statusThe log should say "Registered server transport ‘obfs4’" and that both ports are reachable. The bridge line contains a certificate value that users paste into Tor Browser; keep it private if you intend to hand it to specific people, or leave distribution to the Tor Project. Both ports must stay reachable, so leave the ufw rules in place. If you ever want the obfs4 port below 1024, follow the setcap and NoNewPrivileges steps in the Tor Project’s Debian bridge guide.
Snowflake standalone proxy, the low-effort alternative
If you want to help censored users without publishing an ORPort or managing a bridge, run a standalone Snowflake proxy. It makes outbound WebRTC connections only, needs no inbound firewall rules, and uses whatever bandwidth clients send through it. Ubuntu 24.04 packages it with a systemd unit.
apt install -y snowflake-proxy
systemctl enable --now snowflake-proxy
journalctl -u snowflake-proxy -f # "Proxy starting" and then periodic connection countsA Snowflake proxy can run alongside a relay or bridge on the same server since it exposes nothing. It is also the right answer when a relay is more commitment than you want: it can be switched off at any time without hurting anyone’s circuits for long.
Operate: relay search, families, keys, updates
Search your nickname or fingerprint on the Tor Metrics relay search page to see flags, measured bandwidth and uptime as the directory authorities see them. nyx on the server shows live bandwidth and circuits. Back up /var/lib/tor/keys: the ed25519 master identity key is what makes a relay the same relay after a reinstall, and losing it means starting the reputation ramp over.
cat /var/lib/tor/fingerprint
sudo -u debian-tor nyx
tar czf /root/tor-keys-$(date +%F).tgz -C /var/lib/tor keys fingerprint # copy this off the server
apt update && apt upgrade -y # the Tor repository delivers new releases through aptIf you run more than one relay, declare the family so clients never use two of yours in one circuit. Tor 0.4.9 introduced Happy Families: generate one family key with tor --keygen-family, copy the .secret_family_key file into the keys directory of every relay, and add the printed FamilyId line to each torrc. Until the Tor Project announces that clients no longer need it, also keep the legacy MyFamily line listing every fingerprint, on every relay. Bandwidth accounting means a relay that hits AccountingMax goes quiet until the next period; that is expected behaviour, not a fault. Extend the prepaid term before it lapses, because a relay that vanishes is worse for the network than one that was never there.
Which plan to pick
BVX11 (2 vCPU, 2 GB RAM, 40 GB NVMe, from $10/mo) in Helsinki, or BVCX23 (2 vCPU, 4 GB, 40 GB, $11/mo) in Germany, runs a relay or bridge at the full bandwidth cap described above. For a US or Singapore relay the BVX11 price is higher in those locations, but the network needs them more. Configure a server, pay in Bitcoin or another supported coin, keep exits off, and your relay will be in the consensus within a day.