Running a Tor Relay or Hidden Service on a Raspberry Pi

This site already covers plenty of ways to run privacy and networking infrastructure on a Raspberry Pi — Pi-hole, AdGuard Home, Unbound for recursive DNS, WireGuard and Headscale for VPN access. A Tor relay is a different kind of contribution: instead of protecting your own traffic, a relay helps carry other people's Tor traffic, strengthening the network's overall capacity and anonymity set. A low-power, always-on Pi is a genuinely good host for this, and it's also one of the simpler ways to get real exposure to how onion routing and onion services actually work under the hood.

Relay types, and which one to actually run

Relay typeWhat it doesRisk/complexity for a home operator Guard/middle relayForwards encrypted traffic between other relays; never touches the public internet on behalf of Tor usersLow — recommended starting point Exit relayThe last hop before traffic reaches the open internet, appearing to destination sites as the traffic's sourceHigh — can generate abuse complaints and ISP/legal attention tied to your home IP; not recommended for a first relay or a residential connection Bridge relayAn unlisted relay that helps users in censored regions reach the Tor network at allLow-moderate — good second step once comfortable running a basic relay

For a home setup, a non-exit guard/middle relay is the right default: it contributes real capacity to the network without your home connection ever being the apparent origin of someone else's traffic to an arbitrary website.

Installing Tor

1. Use the Tor Project's own repository rather than whatever version ships in your distribution's default package list, since Tor ships frequent security updates and distro packages lag behind.
2. Add the Tor Project's package repository and signing key for your Raspberry Pi OS release, then install the tor package through apt as normal.
3. Confirm the service is running and check its logs before touching configuration, so you know what a healthy baseline looks like.

Configuring a relay in torrc

The relay's behavior lives almost entirely in /etc/tor/torrc. A minimal non-exit relay configuration needs:

• ORPort — the port other relays connect to; pick a port and make sure it's forwarded through your router if the Pi is behind NAT.
• Nickname — a short identifier for your relay on the public Tor network (relay nicknames and bandwidth stats are public by design, which is part of how the network verifies capacity).
• ContactInfo — an email or contact method; this isn't strictly required but is good practice so the Tor community can reach you if your relay misbehaves or needs attention.
• ExitPolicy reject *:* — the single most important line for a non-exit relay; this explicitly tells Tor never to act as the final hop to the open internet.
• RelayBandwidthRate / RelayBandwidthBurst — caps on how much of your connection the relay can use, worth setting deliberately on a home connection shared with everything else in the house.

Running a hidden (onion) service

An onion service lets you host something — a web server, SSH, anything TCP-based — reachable only through a self-certifying .onion address, with no port forwarding or public IP required at all, since the connection is built entirely through the Tor network rather than a direct route to your Pi.

1. Add a HiddenServiceDir pointing to a directory Tor will manage, and a HiddenServicePort line mapping the public onion port to whatever local service you're exposing (a local web server on port 80, for instance).
2. Restart Tor; on first start it generates a new key pair and writes the resulting v3 onion address to a hostname file inside that hidden service directory.
3. Back up that directory's keys somewhere safe — losing them means losing that onion address permanently and having to generate (and redistribute) a new one.
4. Because the onion address is itself a self-certifying public key, there's no DNS, no certificate authority, and no dynamic-DNS service to maintain, unlike a conventional self-hosted service reachable over the open internet.

Monitoring and keeping the SD card happy

A relay logs connection and bandwidth activity continuously, which adds up to meaningfully more disk writes than a typical idle Pi project. nyx (a terminal-based relay monitor) gives a live view of bandwidth, connections, and relay health without digging through raw logs. If you're running this as a long-term relay rather than a quick experiment, moving the OS or at least the Tor data directory to a small SSD over USB, rather than leaving everything on a microSD card, meaningfully extends the hardware's working life. You can confirm your relay is actually visible and participating on the public network through Tor Metrics' relay search once it's been running for a few hours.

Legal considerations

Running a non-exit guard or middle relay is legal in the overwhelming majority of jurisdictions and is explicitly encouraged by the Tor Project and by digital rights organizations like the EFF, which maintains legal guidance for relay operators. The legal and practical exposure most people worry about — abuse complaints, law enforcement inquiries tied to specific destination traffic — is almost entirely a function of running an exit relay, where your IP is the last hop before the open internet and can appear to be the source of whatever traffic passed through it. That's precisely why this guide steers toward a non-exit relay as the sensible default for a home connection. If you ever do want to run an exit relay, do it from a dedicated hosting provider that explicitly allows it, with your ISP's acceptable use policy checked first, not from a residential line.

A single Pi running quietly in a closet, forwarding encrypted traffic for strangers it will never identify, is a small but concrete contribution to a network a lot of people depend on for basic safety and access — and it's a far more hands-on way to understand onion routing than reading the protocol spec alone.