Do multiple instances from the same operator count separately in consensus?

Yes. Each instance has its own key pair and appears as a separate relay with its own fingerprint in the consensus. The directory authorities do not combine instances from the same operator.

Is there a limit to how many instances I can run on one server?

Practical limits are CPU cores and network port capacity. Running more instances than CPU cores available provides diminishing returns. Network port capacity (1 Gbps, 10 Gbps) sets the absolute ceiling for aggregate throughput.

Can multiple instances share the same IP?

Yes, as long as each uses a different ORPort. Multiple Tor relays with different ORPorts can operate from the same IP address. However, if the IP has only one /32 allocation, all relays share that IP's reputation.

Do separate instances need separate bandwidth settings?

Set RelayBandwidthRate on each instance to the target share of total bandwidth. For two instances sharing a 1 Gbps port, set each to 400 MB/s to leave headroom. The instances compete for the same physical port so their combined rate limit should be below port capacity.

What happens if one instance crashes while others are running?

Other instances continue operating normally. Systemd's Restart=always setting restarts the crashed instance automatically. Users connected through circuits on the crashed instance lose those connections and rebuild through surviving instances or other relays.

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.

Start a Brief

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

Privacy & anti-censorship guides

Tor in Russia 2026 Tor obfs4 Bridges Guide

Why Anubiz Host

100% async — no calls, no meetings

Delivered in days, not weeks

Full documentation included

Production-grade from day one

Security-first approach

Post-delivery support included

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.

Start a Brief High-CPU VPS for Multi-Instance Tor