Running Multiple Tor Instances on One Server for Maximum Throughput
A single Tor process has throughput constraints from its threading model. For operators with high-bandwidth VPS who want to contribute maximum capacity to the Tor network, running multiple tor processes on the same server distributes the cryptographic work across multiple CPU cores and achieves aggregate throughput well beyond single-process limits. This guide covers the configuration, management, and monitoring of a multi-instance Tor deployment.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
When Multiple Instances Make Sense
Single-instance throughput on modern hardware with AES-NI saturates at approximately 200 to 400 Mbps depending on CPU speed, memory bandwidth, and kernel parameters. For VPS with 1 Gbps or faster ports and multiple vCPU cores, the single-process limit is reached long before the network port is saturated. Multiple instances are warranted when a single instance's CPU usage consistently exceeds 70 to 80% while the network interface has remaining capacity.
Monitor with nyx and system tools: if nyx shows consistent high circuit counts and the relay's tor process consumes one full CPU core (100% of one vCPU in top), a second instance would double achievable throughput by utilizing a second CPU core. The threshold for adding a third instance follows the same logic: when two instances together consume close to two full vCPU cores.
Note: the Tor Project requests that operators who run many instances or contribute a large fraction of total network bandwidth be mindful of network diversity. Running 10 instances from a single operator concentrates a significant fraction of Tor capacity in one entity, which has trust implications for the network. Consider the network health impact when planning multi-instance deployments.
Configuration Files for Multiple Instances
Each tor instance needs a separate configuration file, data directory, ORPort, and DirPort. Create instance-specific configurations:
# /etc/tor/torrc-instance1 ORPort 9001 DirPort 9030 DataDirectory /var/lib/tor/instance1 Nickname HighCapacityRelay1 ContactInfo your-contact@pseudonym.example RelayBandwidthRate 200 MB RelayBandwidthBurst 400 MB # /etc/tor/torrc-instance2 ORPort 9002 DirPort 9031 DataDirectory /var/lib/tor/instance2 Nickname HighCapacityRelay2 ContactInfo your-contact@pseudonym.example RelayBandwidthRate 200 MB RelayBandwidthBurst 400 MB
Each instance must have a different ORPort and DataDirectory. The DataDirectory contains the relay's key pair (fingerprint), so different directories mean different relay identities. Create the data directories with correct permissions: mkdir -p /var/lib/tor/instance{1,2} && chown debian-tor:debian-tor /var/lib/tor/instance{1,2} && chmod 700 /var/lib/tor/instance{1,2}
Systemd Service Management
Create separate systemd service units for each instance. Tor's packaged systemd unit in Debian supports instance management through @ notation:
systemctl start tor@instance1 systemctl start tor@instance2 systemctl enable tor@instance1 systemctl enable tor@instance2
Verify that each instance starts correctly with: journalctl -u tor@instance1 -f and journalctl -u tor@instance2 -f. Each should show separate fingerprints, separate ORPort bindings, and eventually separate initial directory consensus downloads. After a few minutes both should show "Self-testing indicates your ORPort is reachable from the outside" in the log.
Monitoring all instances together requires watching multiple control ports. Configure separate control ports for each instance:
# Add to each instance's torrc ControlPort 9051 # instance1 ControlPort 9052 # instance2
Run separate nyx sessions for each instance: sudo -u debian-tor nyx --socket /var/lib/tor/instance1/control
Related Services
Why Anubiz Host
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.