Tor Relay Bandwidth Capacity Planning: 2026 Guide

Tor relays report their bandwidth in three metrics: AdvertisedBandwidth (what the relay claims), MeasuredBandwidth (what the bandwidth authorities have measured), and consensus weight (how much traffic the relay gets assigned). Bandwidth authorities (bwauth) actively measure each relay's capacity by sending test traffic and measuring throughput. The lower of the relay's self-reported rate and the bwauth measurement is used for traffic assignment. New relays get reduced traffic initially (guard probability starts at zero until the relay has 68 days of uptime). This ramp-up period affects capacity planning: a relay will not immediately receive traffic proportional to its stated bandwidth.

Key torrc bandwidth settings: RelayBandwidthRate (sustained bandwidth per second - the average rate), RelayBandwidthBurst (burst rate - maximum instantaneous bandwidth), and AccountingMax (total monthly traffic cap). Relationship: RelayBandwidthBurst should be 2-5x RelayBandwidthRate. Example for a relay on a 100 Mbps server with a 10 TB monthly transfer limit: RelayBandwidthRate 10 MB (80 Mbps of real throughput), RelayBandwidthBurst 40 MB (320 Mbps burst), AccountingMax 8 TB (leaves 2 TB buffer for other services). Note: torrc bandwidth in Tor is specified in bytes per second (B, KB, MB, GB) not bits per second (bps). 1 MB/s = 8 Mbps.

Calculating monthly traffic for budget planning: a relay running at RelayBandwidthRate 10 MB/s continuously would use: 10 MB/s * 60 s/min * 60 min/hr * 24 hr/day * 30 days = 25,920 GB = ~25 TB. This is the maximum possible at full utilization. Actual utilization is typically 30-70% of the configured rate (Tor does not always have enough traffic to saturate all relays). Conservative estimate: plan for 50% utilization of the configured rate for initial deployment. Monitor actual usage for the first month and adjust. For a hosting plan with 10 TB transfer: configure RelayBandwidthRate such that 50% utilization * 30 days = 10 TB. Solving: 10 TB / (50% * 30 * 24 * 3600) = approximately 7.7 MB/s. Set RelayBandwidthRate 7 MB and monitor.

CPU: Tor's encryption is CPU-intensive. AES-NI hardware acceleration (supported by all modern CPUs) dramatically improves Tor performance. At 100 Mbps, a single modern CPU core can handle Tor's encryption. At 1 Gbps, 2-4 CPU cores are needed. For very high speed relays (10+ Gbps), multiple cores and careful Tor thread configuration. RAM: Tor uses RAM for circuit state (each active circuit uses a few KB). At high concurrency (10,000+ simultaneous circuits), RAM usage scales. 2 GB RAM is sufficient for most relays up to 1 Gbps. Network: the relay's network port must support the configured bandwidth. On a shared VPS, other tenants sharing the same physical network port may affect your available bandwidth. Dedicated servers or high-quality VPS providers with dedicated bandwidth allocation provide more consistent performance.

After deployment, monitoring actual bandwidth usage is essential for accurate planning. Tools: nyx (command-line Tor relay monitor, shows real-time bandwidth, circuit counts, and events), Prometheus node_exporter + tor_exporter (exports Tor metrics to Prometheus for graphing), and Tor Metrics portal (shows historical relay bandwidth for registered relays). Key metrics to track: average bandwidth over 24h, peak bandwidth during busy hours (evenings UTC when US and EU users are most active), and AccountingMax consumption rate. Adjustment: if bandwidth consistently hits RelayBandwidthRate limits for hours at a time, increase the rate if budget allows. If actual bandwidth is <20% of the configured rate after 3 months, the relay may be in an overprovisioned deployment - the bandwidth configuration is correct but the relay is not getting its bandwidth used by the network (may need more uptime to build reputation).