Plan and maintain a Tor relay on a VPS
Choose a non-exit relay or bridge, budget bandwidth, install maintained Tor packages and operate the node responsibly.
At a glance
Running a Tor relay requires a suitable provider, adequate transfer capacity, correct ports and regular maintenance. A middle relay or bridge differs from an exit node in its network role and responsibilities. Use the Tor Project's setup checks and monitor resource use after deployment.
Choose the role before renting resources
A public non-exit relay passes encrypted traffic between Tor nodes rather than making the user's final connection to an internet service. It can later receive guard status as the network evaluates it. A bridge provides an entry point that is not listed like a normal public relay, helping users whose networks block known Tor addresses.
An exit relay makes the final outbound connection and therefore exposes its own IP to destinations. That brings different operational and abuse-handling requirements. For a first node, a non-exit relay or bridge is usually the more manageable choice. Confirm the provider permits the precise role before deploying it.
Budget for continuity and traffic
A relay benefits from a stable address, dependable uptime and sustained capacity in both directions. Small VPS resources can support a starting relay, but throughput depends on encryption performance, shared CPU behaviour and network limits. RAM requirements rise with connection count; monitor real use rather than treating the smallest instance as a universal fit.
Monthly transfer matters as much as the port speed. A high rate maintained around the clock can exhaust a metered plan quickly, especially where incoming and outgoing traffic both count. Match bandwidth shaping and accounting to the actual allowance, and leave headroom for system maintenance.
Install maintained software on a hardened system
Start with an updated operating system, key-based administrative access and a firewall that permits the selected relay port. Use the Tor Project's current installation instructions for your distribution and supported package source. Repository keys, package names and service units should come from those instructions rather than an old copied installer.
On many Linux systems the configuration is /etc/tor/torrc. Set a distinctive nickname and a monitored project contact address, then configure the relay role explicitly. Keep the management path separate from the relay's public listener.
Use an explicit non-exit configuration
The following is an illustrative non-exit outline, not a complete setup script. Replace the contact with an address you monitor and select rate values that fit the subscription. The .invalid address shown is a placeholder and cannot receive operator messages.
Validate the configuration and review startup diagnostics. Confirm that the relay port is reachable and that the node eventually appears in the public directory. A new relay may initially carry little traffic while its capacity and reliability are evaluated; avoid repeatedly changing its identity just to force activity.
Nickname SilentNode
ORPort 9001
ContactInfo [email protected]
RelayBandwidthRate 1 MBytes
RelayBandwidthBurst 2 MBytes
ExitRelay 0
SocksPort 0A bridge needs a transport and careful distribution
An obfs4 bridge disguises its traffic pattern to help users bypass filtering. Follow the current distribution-specific bridge guide for its pluggable transport package; the obfs4 implementation project is now named lyrebird. Configure the transport listener, test reachability and obtain the bridge connection information.
Do not publish a private bridge line indiscriminately. Use the documented distribution mechanism or share it with the intended users. Converting a publicly known relay into a bridge without changing identifying details can make the bridge easier to discover and block.
Declare common ownership and maintain contact
If you run several relays, disclose their shared control through the current Tor family mechanism so clients can avoid selecting your nodes in multiple circuit positions. Current guidance uses FamilyID; older MyFamily examples should not be treated as current configuration instructions.
A monitored ContactInfo address lets other operators report problems without needing your civil identity. Keep security updates current, but understand how service restarts and package changes affect the node. Use bandwidth and accounting settings deliberately rather than allowing a relay to consume the whole plan unexpectedly.
- Check the current family configuration for multi-relay operation.
- Monitor the dedicated contact mailbox.
- Review updates and reachability after a restart.
- Keep private monitoring details appropriately restricted.
- Choose transfer accounting that matches the provider's billing.
Treat exits as a separate deployment decision
Exit traffic can generate complaints and destination-side blocklisting. Before enabling an exit, establish explicit provider permission, a monitored abuse process, suitable dedicated infrastructure and an informed understanding of applicable obligations. Do not switch an existing node into exit mode merely to increase its usefulness.
A non-exit relay or bridge already contributes useful capacity. Its lower exposure to destination complaints does not remove the need for maintenance or permission. The public SilentVPS website cannot substitute for a confirmed operational policy when production infrastructure becomes available.
Preserve a healthy relay over time
Check directory status, throughput, clock synchronisation, memory and the chosen listener after changes. A private monitoring system helps detect outages without publishing sensitive fine-grained traffic patterns. Keep configuration and identity-key backups in a secure place.
If you migrate, preserve the appropriate identity material so the node need not rebuild all of its history; verify the current migration guidance before copying files. Never run unintended duplicate instances of the same identity. Stable, well-maintained capacity benefits the network more than frequent experimentation on a live node.