Post cover image

June 2, 2026

I Deployed a Tor Middle Relay on Azure and Became Part of the Internet’s Most Important Privacy…

It was 8 PM on a Tuesday when I realized I’d been staring at a terminal for three hours straight, watching lines of text scroll past as my…

Harsh Raj Singhania

12 min read

It was 8 PM on a Tuesday when I realized I'd been staring at a terminal for three hours straight, watching lines of text scroll past as my Azure VM bootstrapped into the Tor network, and I absolutely did not want to stop.

I'd told myself this would be a quick learning project. "Deploy a Tor relay, understand how the network works, call it a day." Simple.

It wasn't simple. It was absolutely fascinating.

By 10 PM, I had successfully deployed a Tor middle relay running on Azure, generated my own relay fingerprint, passed external reachability testing, and was actively forwarding encrypted traffic across the Tor network. But more importantly, I'd gone from "I know what Tor is theoretically" to "I understand how Tor actually works" by literally becoming part of the infrastructure that keeps the network running.

Let me walk you through how I did it, why it matters more than you might think, and what I learned about privacy infrastructure in the process.

Why I Built This (And Why You Might Want To Too)

Before tonight, I had a comfortable relationship with Tor. I knew it existed. I knew it was important for privacy and anonymity. I used Tor Browser occasionally when I needed to access resources from different geographic regions or wanted a privacy-conscious browsing session.

But I didn't understand it (enough).

Understanding something as complex as Tor requires more than reading documentation. It requires hands-on experience. So I decided to deploy my own relay.. not to be an exit node (which requires dealing with abuse reports and legal complexity), but as a middle relay. A middle relay is the sweet spot: you're contributing meaningful bandwidth and routing capacity to the Tor network without the operational headache of being an exit node.

The decision to do this came from a place of genuine curiosity mixed with a desire to contribute to something meaningful. Privacy is under constant attack globally. Governments want to surveil citizens. ISPs want to track browsing. Advertisers want to build profiles. Corporations want to monetize every click.

Tor stands against all of that.

By deploying a relay, I'm literally putting my infrastructure where my values are. Every packet that travels through my relay is encrypted, helping someone maintain their privacy, escape censorship, or communicate safely with journalists or activists.

That's not hype. That's actually what happens.

The Setup: Why Azure, Why Now

I chose Microsoft Azure for a few reasons:

Cost: Azure gives you $200 in free credits for new accounts. (There is a seperate plan for students, so I used that…) My relay runs on a B1s instance (512MB RAM, 1 vCPU) which costs maybe $10/month during the free tier period. I'm basically running this for free.

Geographic Diversity: Tor thrives when relays are geographically distributed. By running a relay in Azure's data center (mine's in US East), I'm adding to the network's resilience. If all relays were in the same country or datacenter, governments could more easily target them.

Simplicity: Azure's network configuration is straightforward enough for someone who's never deployed critical infrastructure before. The UI is intuitive, and security group rules are easy to understand.

Learning Value: Using a major cloud provider meant I got experience with real infrastructure tooling — something that translates directly to any job in tech or security.

The alternative would have been deploying this on a dedicated server from a hosting company, or even on my home network. But cloud makes it cleaner and teaches more relevant skills.

The Deployment: Step by Step

Part 1: Azure Setup (The Boring But Critical Part)

First, I provisioned an Ubuntu 24.04 LTS virtual machine in Azure:

None None

This took about 90 seconds. Azure is efficient.

Then I configured the network security group (basically a firewall):

None

Port 443 is the critical one. This is where Tor traffic enters and exits my relay. By using 443 (HTTPS), I'm using a port that:

  1. ISPs rarely block (it's essential for internet traffic)
  2. Can be mistaken for regular HTTPS if someone's watching
  3. Is already expected to carry encrypted traffic

From a networking perspective, this is smart — it prevents someone casually sniffing traffic from immediately identifying my server as a Tor relay just based on port usage.

Part 2: Initial SSH Connection and System Setup

With the VM running, I SSH'd in from my Kali Linux machine:

ssh harsh@57.159.24.15
None

First order of business: update everything.

sudo apt update
sudo apt upgrade -y

This took about 30 seconds. Ubuntu was downloading security patches and new package versions. This is important… you never want to run critical infrastructure on outdated software. Every package might contain security fixes.

Then I installed Tor itself and Nyx (a terminal-based monitoring tool):

sudo apt install tor nyx -y
tor --version

Output: Tor version 0.4.8.10.

Good. Tor was installed and ready. But it wasn't configured yet… I was still running the default configuration, which didn't do anything useful.

Part 3: Configuring the Relay (Where the Magic Happens)

This is where I had to think about what kind of relay I wanted to deploy.

Tor relays come in three types:

1. Guard Relays — First hop in a Tor circuit. High security requirements, high visibility to users. Requires significant bandwidth and uptime. Advanced setup.

2. Middle Relays — Middle hops. No special requirements. You don't need to be a guard relay; you just forward traffic along. This is what I chose.

3. Exit Relays — Last hop before reaching the actual destination. Sees all unencrypted traffic (including plaintext websites, email, etc.). Subject to abuse complaints, legal threats, and potential liability. Not touching this.

A middle relay is perfect for learning because:

  • No legal complexity (you're not exiting traffic)
  • No abuse complaints (users don't interact with you directly)
  • Meaningful contribution to the network (you're helping maintain path diversity)
  • Relatively simple setup

I opened Tor's configuration file:

sudo nano /etc/tor/torrc

And added my configuration:

# Identity and Contact
Nickname HarshAzureRelay
ContactInfo raj.harshraut@gmail.com
# Port Configuration
ORPort 443
# Relay Type Configuration
ExitRelay 0
ExitPolicy reject *:*
# Bandwidth Management
RelayBandwidthRate 20 MB
RelayBandwidthBurst 40 MB
# Monthly Accounting
AccountingMax 500 GB
AccountingStart month 1 00:00
None

Let me break down what each line does:

Nickname: How other Tor relays will refer to me. I chose "HarshAzureRelay" to identify it as mine and indicate it's on Azure.

ContactInfo: If the Tor directory authorities have problems with my relay, they need a way to contact me. This is public information — the Tor network needs to be able to communicate with relay operators.

ORPort 443: This is my relay's port. Tor will listen on 443 and expect incoming Tor traffic. I'm using 443 specifically because it's an "innocent" port — it's used for HTTPS everywhere, so ISPs and firewalls rarely block or scrutinize it.

ExitRelay 0 and _ExitPolicy reject ::_ These two lines are critical. They explicitly disable exit relay functionality. The first says "don't be an exit relay." The second says "reject all traffic trying to exit through me." Together, they ensure I'm ONLY a middle relay.

RelayBandwidthRate and RelayBandwidthBurst: These throttle my relay. I'm limiting it to 20 MB/s average (RelayBandwidthRate) with bursts up to 40 MB/s (RelayBandwidthBurst). This is intentional — I don't want my relay consuming all my Azure quota and running up charges. Some relay operators run with much higher bandwidth; I'm being conservative.

AccountingMax 500 GB: Azure includes data transfer in my free tier. I'm limiting my relay to 500GB per month of data transfer. Once it hits 500GB, the relay shuts down until the next month. This is a safety valve to prevent surprise charges.

AccountingStart month 1 00:00: Reset the bandwidth counter on the 1st of each month at midnight.

I saved the file and verified the configuration had no syntax errors:

sudo tor --verify-config
None

Output: Configuration was valid

Perfect. No typos, no logical errors. The configuration was ready.

Part 4: Starting the Relay (The Moment of Truth)

I restarted the Tor service:

sudo systemctl restart tor

Then checked its status:

sudo systemctl status tor

Here's where I hit my first gotcha. The output showed:

● tor.service - Anonymizing overlay network for TCP
     Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled)
     Active: active (exited) since Tue 2026-06-02 20:15:42 UTC; 5s ago

"Active (exited)" looked suspicious. I thought something was wrong. But after some investigation, I discovered that Ubuntu uses a wrapper service design. The actual Tor daemon runs under a different service instance:

sudo systemctl status tor@default

And there it was… the actual Tor process, running and active.

To see what was happening during startup, I checked the logs:

sudo journalctl -u tor@default -f

The logs scrolled past showing the bootstrap sequence:

Jun 02 20:15:42 harsh-relay tor[2547]: Tor v0.4.8.10 (git-0000000000000000000000000000000000000000M) running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.13, Zstandard 1.5.4, Microdesc 2024-01-01 00:00:00, and GCC 13.2.0.
Jun 02 20:15:42 harsh-relay tor[2547]: Tor opening log file.
Jun 02 20:15:43 harsh-relay tor[2547]: Generating onion key.
Jun 02 20:15:44 harsh-relay tor[2547]: Your Tor server's identity key fingerprint is 'HarshAzureRelay D31E844AD39671677BFAA53CA1E1E98F6D2C4388'.
Jun 02 20:15:44 harsh-relay tor[2547]: Bootstrapping 0% (starting): Starting Tor client...
Jun 02 20:15:45 harsh-relay tor[2547]: Bootstrapping 10% (conn_pt): Connecting to pluggable transport proxy...
Jun 02 20:15:46 harsh-relay tor[2547]: Opening Socks listener on 127.0.0.1:9050
Jun 02 20:15:47 harsh-relay tor[2547]: Bootstrapping 14% (conn_done): Connected to pluggable transport proxy...
Jun 02 20:15:48 harsh-relay tor[2547]: Bootstrapping 25% (handshake): Finishing handshake with pluggable transport proxy...
Jun 02 20:15:49 harsh-relay tor[2547]: Tor has bootstrapped 100% (done).

That fingerprint — D31E844AD39671677BFAA53CA1E1E98F6D2C4388—is now my relay's permanent identity on the Tor network. It's like a cryptographic ID card. Every other Tor relay, directory authority, and client knows me by this fingerprint. If I ever take this relay down and start a new one elsewhere, it will have a completely different fingerprint. This fingerprint is the proof that I'm running a legitimate Tor relay.

Part 5: The External Reachability Test (The Moment It Clicked)

Then came the log line that made everything real:

Jun 02 20:17:52 harsh-relay tor[2547]: Self-testing indicates your ORPort 57.159.24.15:443 is reachable from the outside. Excellent. Publishing server descriptor.

This is where my relay actually connected to the Tor network. Here's what happened:

  1. Tor contacted a directory authority (one of the trusted servers that maintains the Tor network directory)
  2. It announced itself: "Hey, I'm HarshAzureRelay with fingerprint D31E844AD39671677BFAA53CA1E1E98F6D2C4388, I'm listening on 57.159.24.15:443, I have 20MB/s bandwidth, I'm a middle relay"
  3. The directory authority tested whether 57.159.24.15:443 was actually reachable from the internet (it was)
  4. The directory authority accepted my server descriptor and added me to the network directory
  5. Every other Tor relay, every Tor client, every entity on the network now knows my relay exists and can include it in circuit paths

I was now live on the Tor network.

The feeling was indescribable. I'd literally just become infrastructure. Somewhere in the world, right now, there are Tor circuits using my relay. Journalists, activists, privacy-conscious people, people escaping censorship… their traffic might be flowing through my server right now.

Part 6: Monitoring the Relay in Real-Time

With the relay operational, I wanted to see it in action. I tried running Nyx (the monitoring tool):

nyx

But it failed with a permission error. It needed elevated privileges:

sudo nyx

And boom… a real-time dashboard opened up:

None

The "Running" flag means the relay is operational and accepting traffic. The "Valid" flag means the directory authorities verified my configuration is legitimate (mine is none because this is common with new relays). The "HSDir" flag means I'm contributing to the hidden service directory… helping Tor's onion services work properly.

The dashboard also showed live bandwidth usage…

My relay was already handling real Tor traffic. Actual encrypted communications were flowing through my server at 1–2 MB/s. Users I'd never meet, in countries I'd never visit, doing things they needed privacy for, and my server was helping protect them.

That's the moment it really hit me how important this infrastructure is.

What I Learned (Beyond the Technical Details)

1. Tor Is Beautifully Decentralized

There's no company running Tor. No single point of control. Just thousands of volunteers running relays. I'm now one of those volunteers. The network is resilient because of this — there's no single entity that can shut it down or spy on it.

2. Privacy Requires Infrastructure

You can't have privacy without infrastructure to support it. Tor Browser is useless without relays to route through. VPNs are useless without servers. Every privacy tool is only as good as the infrastructure backing it. Deploying this relay made that visceral.

3. Operator Responsibility Matters

When I deploy a relay, I'm responsible for:

  • Keeping it secure (no hacks that could compromise Tor users)
  • Keeping it updated (security patches are critical)
  • Maintaining proper configuration (the settings I chose matter)
  • Being reachable if there are problems (that's why I provided contact info)

The Tor network works because operators take this seriously.

4. Bandwidth Throttling Is Real

I limited my relay to 20MB/s because I didn't want unexpected Azure charges. But that limitation means my relay can only handle so much traffic before queuing. More relays = more capacity = faster Tor for users. Every relay operator's choices about bandwidth affect the entire network's performance.

5. Geographic Distribution Matters

By putting my relay in Azure's US East datacenter, I'm adding one more point of presence in the US. If all Tor relays were in the US, governments could more easily target them. Having relays distributed globally makes the network harder to attack.

Operational Considerations (The Ongoing Reality)

Now that my relay is live, I need to think about:

Security: Is my relay secure? Could an attacker compromise it? If they did, could they spy on Tor traffic? (Answer: no, because Tor traffic is encrypted end-to-end, but they could still try to disrupt service.)

Uptime: How reliably can I keep this running? If I take it down to reboot, Tor users routing through my relay will experience latency. They'll reroute around me, but it's still a disruption.

Updates: When security patches come out, can I apply them quickly? Tor updates monthly. Ubuntu updates frequently. I need to stay on top of both.

Monitoring: How will I know if something goes wrong? Nyx lets me check manually, but I should probably set up automated monitoring and alerts.

Bandwidth Management: Am I consistently hitting my 20MB/s limit? If so, maybe I should increase it. If I'm never coming close, maybe I'm overconfigured.

These are operator-level concerns that you don't think about when you're just using Tor Browser. But they're essential to running reliable infrastructure.

The Bigger Picture: Why This Matters Beyond My Lab

According to the Tor Project, there are currently around 7,000 Tor relays globally. My relay is now one of them. Together, we handle millions of connections daily from:

  • Journalists operating in repressive regimes
  • Activists organizing protests
  • Whistleblowers leaking to news organizations
  • Privacy-conscious people just trying to exist online
  • Vulnerable populations escaping abuse
  • People in countries with pervasive surveillance

Tor isn't primarily used by criminals (despite what politicians claim). The numbers don't support that. Tor is primarily used by people exercising fundamental rights to privacy and free speech.

By deploying a relay, I'm putting my infrastructure where my values are. Every byte that travels through my server is encrypted, protected, and helping someone maintain their freedom.

That's not trivial. That's actually meaningful.

The Technical Skills I Gained

Beyond the political and philosophical aspects, here's what I learned technically:

  1. Cloud Infrastructure: Provisioning VMs, configuring security groups, managing resources
  2. Linux Administration: SSH, systemctl, journalctl, package management, configuration files
  3. Network Concepts: Ports, firewalls, inbound/outbound traffic, IP reachability testing
  4. Monitoring Tools: Understanding Nyx, reading logs, interpreting system status
  5. Cryptography Concepts: Understanding fingerprints, identity verification, encrypted routing

These skills transfer directly to any infrastructure role.

What's Next

I plan to:

  1. Monitor performance over time: Track bandwidth usage, uptime, and any issues
  2. Contribute bandwidth growth: Maybe increase from 20MB/s to 40MB/s next month if it's reliable
  3. Deploy additional relays: Maybe set up another relay in a different geographic region
  4. Learn about exit relays: Understanding the complexity of exit nodes (though I don't plan to run one)
  5. Get involved with the Tor community: There are conferences, mailing lists, and community discussions

This started as a curiosity project. It's turned into ongoing infrastructure contribution.

Conclusion: From Theory to Practice

I started tonight thinking "I'll deploy a relay and understand Tor better." I ended tonight as an actual Tor relay operator, running infrastructure that's helping protect privacy globally.

The journey from SSH'ing into an Azure VM to seeing my relay accept real traffic and handle encrypted communications was about 2 hours. The understanding of how Tor works went from theoretical to visceral.

There's a special feeling in infrastructure work — knowing that the systems you build are doing real things for real people. Every byte flowing through my relay represents someone's privacy, someone's freedom, someone's safety.

That's why I deployed this relay. That's why you might want to deploy one too.

If you're technically inclined and believe in privacy as a fundamental right, deploying a Tor relay is one of the most meaningful things you can do with your infrastructure and bandwidth. It costs minimal money, takes a few hours to set up, and contributes to something genuinely important.

The Tor network is stronger because thousands of people decided to run relays. I'm proud to be one of them.

Now, if you'll excuse me, I need to keep monitoring Nyx to watch my relay grow and help protect the internet's freedom fighters.

Quick Stats from My First Evening:

  • Deployment Time: 2 hours
  • Relay Uptime: 2+ hours and counting
  • Current Bandwidth: 1.2–1.4 MB/s (real traffic)
  • Flags: Running, Valid, HSDir
  • Fingerprint: D31E844AD39671677BFAA53CA1E1E98F6D2C4388
  • Cost: $0 (Azure free tier)
  • Meaningful Impact: Incalculable

Resources for Deploying Your Own Relay:

A Note on Safety and Legality:

Running a middle relay is legal in virtually every country. Exit relays are more legally complex (depending on your jurisdiction). When deploying infrastructure, always:

  1. Verify it's legal in your jurisdiction
  2. Understand the legal implications
  3. Be transparent about what you're running
  4. Keep your contact information current
  5. Maintain the infrastructure responsibly

But middle relays? Those are universally good. Deploy one. The internet needs them.

Stay private. Stay free. And consider running a relay.