How to run a Tor relay on a VPS

Every Tor relay forwards encrypted traffic, but the role you pick determines your exposure. There are three to understand:

• Middle relay — passes traffic only between other Tor nodes. It never connects to the open internet on a user's behalf, so it almost never generates complaints. This is the safe default and the right choice for a first relay. A well-established middle relay may also be picked by the network to serve as a guard, the first hop in a circuit, but that is a role the directory authorities assign over time, not a separate thing you configure.
• Bridge — an unlisted entry point that helps people in censored networks reach Tor. Bridges are not published in the public consensus, draw essentially no abuse, and are genuinely useful where Tor is blocked.
• Exit relay — the final hop that sends traffic to ordinary websites under your server's IP. Because the destination sees your address, exits attract abuse notices, blocklisting, and occasional law-enforcement inquiries.

If you want maximum benefit with minimum hassle, run a middle relay or a bridge. Only consider an exit once you understand the operational and legal weight that comes with it.

We will not sugar-coat this. An exit relay routes other people's traffic to the wider internet under your IP, which means automated abuse systems, copyright agents, and occasionally investigators will see your address as the apparent source. Expect to receive abuse reports. Many hosting providers forbid exits outright for exactly this reason, and exit IPs frequently end up on blocklists that affect mail and signups.

None of this makes running an exit wrong — exits are vital to Tor and are run lawfully every day by experienced operators and organizations. But it is real work: you need a published abuse contact, a reduced exit policy, and a willingness to respond to notices. If that sounds like more than you signed up for, a middle relay gives the network most of the value with almost none of the friction.

Middle and bridge relays are welcome on every tier; they pass only intra-network traffic and are a clean use of bandwidth we are glad to support. Exit relays are permitted in select locations, but they come with conditions: you must publish a working ContactInfo, run a reduced exit policy, and respond to abuse correspondence that reaches you through the control panel.

The hard floor is absolute and applies to Tor traffic like everything else: no CSAM, no weapons trafficking, no terrorism content, no exceptions. We treat routine copyright notices as an operational matter rather than automatic takedowns, and we act on valid court orders in the server's jurisdiction. We are private, not a promise of immunity; review our acceptable-use policy and how we handle abuse reports before you run an exit. If you are unsure whether your plan fits, ask through the panel first.

A relay is light on disk and RAM but rewards CPU and bandwidth. Tor is largely single-threaded for crypto work, so a couple of dedicated vCPUs let you push real throughput. Because every tier here includes unlimited traffic, you never pay an overage for the bandwidth you donate, which is exactly what a relay needs.

For a personal middle relay, the Cub (1 vCPU / 2 GB) or Scout (2 vCPU / 4 GB) tier is plenty. If you want a relay that pushes meaningful capacity into the network, Scout and up are the sweet spot, and the all-NVMe offshore VPS base means the small descriptor and consensus files stay snappy. Pick a location with good peering; our Amsterdam node sits on AMS-IX and is an excellent home for a relay.

A few configuration values matter for every relay regardless of role. The Nickname is a public label of up to 19 alphanumeric characters. ContactInfo should be a way the network and the Tor Project can reach you about your relay — publish a non-personal abuse handle or an abuse URL rather than anything that ties back to you; never expose a personal address you care about.

The ORPort is the TCP port other relays connect to (443 and 9001 are common choices). Bandwidth is governed by RelayBandwidthRate and RelayBandwidthBurst: the rate is your sustained ceiling and the burst absorbs short spikes. Setting an explicit cap keeps a relay predictable even though traffic is unlimited. The numbered steps below put all of this together into a working file.

Treat a relay as a single-purpose machine. Do not mix your personal browsing, your website, or any service that ties back to you onto the same VPS — a relay's IP is public and, for an exit, is the apparent source of strangers' traffic. Keeping it dedicated protects both you and the relay's reputation.

• Run nothing else of consequence on the box; keep the OS minimal and patched.
• Set a real ContactInfo and, for exits, host a short Tor exit notice page so anyone investigating your IP understands what it is.
• Monitor health with nyx and watch the systemd journal for warnings.
• For an exit, route abuse correspondence through a handle you actually monitor, and respond promptly. Fast, polite replies prevent most escalations.

If you are layering this with personal Tor use, our VPS-for-Tor guide covers running a private bridge or onion service alongside good network hygiene.

For a middle relay or bridge, jurisdiction barely matters — pick a location with strong peering and low latency to the relays you will talk to. The Netherlands flagship is hard to beat on connectivity.

For an exit, jurisdiction matters a great deal, because the server's local law governs how copyright notices and orders are handled and how comfortable the surrounding environment is for exit traffic. Free-speech and free-press jurisdictions such as Sweden and Iceland are popular homes for exits, and a privacy-forward base of NL, RO, or BG keeps things straightforward. Whatever you choose, your relay remains bound by the hard floor and by valid court orders where the server sits — running it on a no-KYC VPS changes how you sign up and pay, not which laws apply to the traffic.