How to run a Tor relay on a VPS

Learning how to run a Tor relay on a VPS is one of the highest-leverage things a privacy-minded person can do: a single well-configured relay quietly moves traffic for thousands of strangers who need it. The network is not run by a company — it is run by volunteers who donate bandwidth from machines exactly like the one you can deploy in a few minutes. This guide walks through the relay types, a clean install on a fresh server, the settings that make you a good operator rather than just another node, and the one role you should think hard about before enabling.

Everything here is intentionally high-level on the security-sensitive parts. Tor's own operator documentation is the canonical, always-current source, and you should read it alongside this article; the goal here is to give you the shape of the task and the operator etiquette that tutorials usually skip.

Relays, bridges, and exits: what actually differs

The Tor network is built from three flavours of node, and choosing correctly is most of the decision:

• Middle (non-exit) relay. It receives encrypted traffic from one Tor node and passes it to the next. It never talks to the open internet on a user's behalf, so it never appears in anyone's server logs. This is the safest role to run on rented infrastructure and the right default for a first relay.
• Bridge. A special unlisted entry point. Because its address is not in the public relay directory, censors in restrictive networks cannot easily block it, so bridges help users in places where plain Tor is filtered. An obfs4 bridge additionally disguises the traffic so it does not look like Tor at all. Bridges are low-drama to host and enormously useful.
• Exit relay. The last hop, which connects out to the actual destination website or service. Because that outbound traffic carries your server's IP address, any abuse routed through it looks like it came from you. Exits keep the network usable, but they attract complaints and legal attention and should never be run casually on a machine you care about.

For most people the answer is a middle relay or an obfs4 bridge. Both are genuinely valuable, and neither puts your IP on the receiving end of anyone's activity.

What you need before you start

A relay is not resource-hungry in the way a game server is, but it is bandwidth-hungry and it must be online. Aim for:

• Steady bandwidth. Tor suggests a relay be able to sustain a meaningful, continuous rate in both directions. A relay that pushes real traffic is worth far more to the network than ten that barely move data, so an unmetered or generously-metered link matters more than raw CPU.
• Modest RAM and CPU. A small instance handles a middle relay comfortably; encryption is the main load and only becomes noticeable at high throughput. Our entry Phantom plan is enough to begin, and you can scale up if your relay earns a large consensus weight.
• Uptime and a stable IP. Relays build reputation slowly over weeks. Frequent restarts or address changes reset that progress, so pick a host you intend to leave running.
• A provider that permits it. Plenty of hosts quietly forbid Tor. Deploying a relay on infrastructure that allows it — see our VPS built for Tor relay operators — saves you from a surprise suspension.

Installing Tor on a fresh server

Do not install the version of Tor that ships in your distribution's default archive — it is often months behind, and relay software is exactly where you want current code. Instead, add the official Tor Project package repository for your distribution and install from there, then let unattended upgrades keep it current. The Tor Project maintains step-by-step instructions per operating system in its relay operator documentation; follow that for the exact repository lines and signing keys.

At a high level the flow is the same everywhere: harden the box first (a non-root user, key-only SSH, a firewall that allows your chosen ORPort), add the Tor repo, install the tor package, then edit a single configuration file, /etc/tor/torrc. Everything that defines your relay lives in that file.

Configuring a middle relay

A functional non-exit relay needs only a handful of lines in torrc. Conceptually you set a nickname, the ports Tor listens on, your bandwidth ceiling, contact details, and — critically — a policy that refuses to act as an exit:

Nickname        myrelaynick
ORPort          9001
ContactInfo     [email protected]          # a real, monitored address (alias or PGP-fingerprinted)
RelayBandwidthRate   10 MBytes           # your chosen sustained rate
RelayBandwidthBurst  20 MBytes           # a higher short-term ceiling
ExitRelay       0
SocksPort       0

Restart Tor and watch the log. Within a few minutes you should see it perform reachability self-tests; once those pass, your relay is published to the directory authorities and begins appearing on the public relay list. The first day or two carry little traffic while the network measures and trusts you — this ramp is normal, so resist the urge to keep tweaking.

Running an obfs4 bridge instead

If your goal is to help people behind censorship, a bridge is the higher-impact choice. You install the same tor package plus the obfs4proxy pluggable transport, then set your relay to bridge mode with the obfs4 transport enabled and a separate transport port. Because bridges are unlisted, you distribute your bridge line privately or hand it to Tor's BridgeDB rather than publishing it. The operator docs cover the exact torrc stanza and the obfs4 setup; the key mental model is that a bridge is a private front door whose value depends on not being widely advertised.

Good-operator settings that actually matter

These are the lines that separate a helpful relay from a nuisance:

• ContactInfo. Set a real, monitored address. When a directory authority or a fellow operator needs to reach you about a misconfiguration or a security update, this is how. Anonymous-but-reachable is fine; unreachable is not.
• MyFamily. If you run more than one relay, list every relay's identity fingerprint in each one's MyFamily line. This tells clients not to build a circuit that passes through two of your relays, which would undermine anonymity. Declaring your family honestly is basic network hygiene.
• Bandwidth limits. Use RelayBandwidthRate and RelayBandwidthBurst to donate generously without saturating your link or blowing through a metered cap. Setting a sane ceiling keeps your relay stable, and a stable relay earns more consensus weight than a fast one that keeps falling over.
• Keep it patched. Enable automatic security updates for the Tor package. Relays are long-lived, and an unattended, outdated relay is a liability to everyone routing through it.

A serious word on exit relays

Exit relays are the network's scarcest and most exposed resource. Every request a Tor user makes to the open web leaves through some exit's IP, which means abuse complaints, blocklistings, and occasionally law-enforcement inquiries land on the exit operator. The Electronic Frontier Foundation and the Tor Project both strongly advise running exits from dedicated infrastructure with a clear abuse-handling process and, ideally, institutional backing — not from a personal server, and not without understanding your local legal exposure. If you are new, run a middle relay or a bridge; leave exits to operators who have set up the paperwork and the reverse-DNS and the abuse mailbox to handle them properly.

On HushVPS specifically: middle relays and obfs4 bridges are explicitly welcome, and running one fits squarely within our acceptable-use posture. Exit relays are a heavier commitment on shared network space, so check our current exit-relay policy with us through the contact page before running one. Confirm before you flip ExitRelay to 1.

Keeping your relay healthy

Once it is live, a relay mostly runs itself, but check in periodically. Tor's Relay Search lets you look up your relay by nickname or fingerprint to confirm it is flagged Running and Stable and to watch its bandwidth history. Monitor the log after each software update, keep the clock synchronised, and make sure your firewall still exposes the ORPort. If you ever migrate the relay to a new server, copy the relay's identity keys so it keeps its hard-won reputation instead of starting from zero.

If a relay is your first step into running privacy infrastructure, it pairs naturally with other services you can self-host anonymously — for example, publishing a service as an onion site with no public IP so it is reachable only over Tor. Same ethos, different corner of the same network.

The short version

Pick a middle relay or an obfs4 bridge for your first node. Install Tor from the official repository, not the distro default. Set a real ContactInfo, declare MyFamily if you run more than one, cap your bandwidth sensibly, and keep the package patched. Leave exit relays for later and for infrastructure built to absorb the complaints. Do that, and you have added a genuinely useful, well-behaved node to a network that runs entirely on people willing to do exactly this.