How to Run a Tor Exit Relay on a No-KYC VPS — Requirements and Reality

Run a Tor exit relay without KYC: which host allows exits, what specs and abuse handling you need, and the honest operational reality. BitCloudVPS allows exits on request.

Published 2026-08-30 · Updated 2026-10-21 · BitCloudVPS Editorial

Exits are a special workload

A middle relay is easy: traffic in, traffic out, few complaints. An exit sends third-party traffic to the internet under your IP — abuse mail follows within days. Most hosts terminate on the first letter. We allow exits on request with an abuse contact, because the AUP judges the operator, not the protocol.

Sizing and policy table

The setup, briefly

1. Provision the VPS (exits: Amsterdam or Bucharest are the classic flags).
2. Install Tor from the Tor Project repo; set ORPort, ContactInfo, a public ExitPolicy (the reduced exit policy limits complaints).
3. Request exit enablement via panel ticket with your abuse contact.
4. Answer abuse mail with the standard Tor templates — boring, effective.
5. Monitor relay health; budget unmetered traffic honestly.

Exit vs non-exit - policy before packages

Tor exits attract abuse mail; bridges and middle relays attract far less. BitCloudVPS allows Tor with exits on request - start as a non-exit on Plus or Business, then request exit after you understand the abuse desk load. Business ($30, 6 vCPU / 16 GB / 5 Gbps unmetered) fits a busy relay; Amsterdam offers AMS-IX throughput. Read Tor Project relay docs before enabling exit policy.

Reduced exit policies that limit ports lower complaint volume. Keep a dedicated box so exit reputation never shares an IPv4 with your mail or personal VPN. Exits are public infrastructure with public complaints. No-KYC helps your identity file; it does not make abuse mail vanish.

Legal content and AUP still apply. Running an exit is a community service with operational cost - budget time for tickets, not only for bandwidth.

Before enabling ExitPolicy, read Tor Project relay documentation and decide your reduced exit policy ports. Register abuse contact mail that you actually read. Keep metrics exporters bound to localhost. Budget emotional bandwidth for complaint templates. Middle relays and bridges remain valuable if exits are not for you. BitCloudVPS no-KYC plus crypto billing removes identity theater from the host file; operational maturity still decides whether an exit is a gift to the network or a gift to your insomnia.

Operational footnote: start non-exit, read Tor Project docs, request exit only when ready for abuse mail, and keep personal services off that IPv4. Business at $30 with unmetered 5 Gbps is the practical exit floor; Amsterdam for throughput. No-KYC helps the identity file; maturity handles the mailbox.

Final note: policy before packages - non-exit first, Tor Project docs, exit on request, dedicated IPv4, Business $24, Amsterdam throughput, abuse mailbox you read. No-KYC removes identity theater; exits still generate mail. Bridges and middles remain honorable if exits are not your season.

Reduced exit policies lower pain. Keep personal VPN and mail elsewhere. Measure uptime and complaint volume monthly. Community service with eyes open beats heroic exits you abandon in week two.

Exit reality check

If you are not ready for abuse mail, run a middle relay or bridge first. That is still useful to the network and kinder to your week.

Abuse-desk readiness before ExitPolicy

Run a middle relay or bridge on Plus/Business first. Read Tor Project relay docs. Decide a reduced exit policy. Stand up abuse mail you actually read. Only then request exit. Business ($24) with 5 Gbps unmetered in Amsterdam is the practical exit floor; keep personal VPN and mail off that IPv4. No-KYC helps the identity file; maturity handles the complaint templates.

Abuse desk reality before you enable ExitPolicy

Exits generate mail; reduced exit policies cut volume but do not zero it. Keep the relay on its own IPv4 — never share with personal mail. Business ($24) or dedicated ($79.50) for busy exits; start as a bridge on Starter if you are learning. Read Tor Project relay docs, set ContactInfo, and answer templates promptly. No-KYC protects your identity file; it does not delete abuse tickets.

Recommended setup

Plan: Business — 6 vCPU, 16 GB DDR5, unmetered 5 Gbps, $24/mo. Location: Amsterdam — AMS-IX throughput for a busy exit. Start as a bridge today; scale to exit after the request.

More rankings and guides

• VPS for a privacy tools stack
• Best VPS outside the 14 Eyes
• Best no-KYC VPS with DDoS
• Best privacy jurisdictions 2026
• Limits of no-KYC anonymity
• Full opsec checklist

Port capacity, disk and the plan floor in numbers

An exit is mostly a bandwidth job, and the port is where BitCloudVPS differs from oversold relay hosts: every VPS plan ships on an unmetered 1–10 Gbps port with NVMe storage and ECC memory, so consensus-bandwidth traffic is not throttled at the rack. As a floor for planning: Starter ($8.50/mo list, 2 vCPU EPYC 7443P, 4 GB ECC, 60 GB NVMe) carries a bridge or middle relay without breaking a sweat; a full exit belongs on Business ($30/mo list) or above, where the extra cores absorb TLS handshakes for third-party traffic and the abuse load that follows it. Tor Project's reduced exit policy (accepting most ports, rejecting mail and peer-to-peer ranges) is what keeps the complaint count tolerable — pair it with a ContactInfo address you actually read. Relay operators who want the exit to matter long-term usually pay by the year: the yearly term is 20% off list, the quarterly one 10% off, settled in crypto with no card on file.

Pick an exit when…; run a middle relay when…

Run an exit when you have read your rack's jurisdiction, set a narrow ExitPolicy (reject the ports that generate the worst abuse: 25, 465, 587 for mail; keep 80 and 443), and can tolerate the IP accumulating a blocked reputation within days. An exit burns IPv4 addresses — that is the deal — so it belongs on a plan where the monthly cost of a burned IP is low and the port capacity is high. Business ($30/mo list, 6 vCPU, 16 GB ECC) or Pro ($45) is the realistic floor for an exit that stays responsive under load; Starter can carry a middle relay comfortably.

Run a middle or guard relay instead when you want to contribute capacity without wearing the exit's abuse load: middles never touch destination traffic, need no ExitPolicy drama, and are welcome on Starter ($8.50, 2 vCPU, 4 GB ECC, 60 GB NVMe) or even Nano for a low-bandwidth node. Run a Snowflake or obfs4 bridge when you want the smallest footprint of all — bridges see modest traffic and rarely attract complaints. The rule of thumb: match the relay role to the abuse you are willing to answer for. An exit with a sloppy policy generates mail to the abuse desk within hours; a middle with the same hardware generates none, ever.

Paying for a long-lived relay: terms, coins and renewals

Relays only build reputation when they stay up, so the billing term is an operational decision, not just a discount. Month to month is the right choice for the first one or two months while you tune the ExitPolicy and watch the complaint volume. Once the relay has settled, the annual term takes 20% off — a Business relay drops from $30/mo list to $288/yr effective — and removes eleven renewal events per year where a lapsed invoice could take your fingerprint offline. The quarter (-10%) is the middle path if you are still evaluating the rack.

For the asset, the honest split is this: a relay is a public, pseudonymous object — its IP, fingerprint and bandwidth are published to the Tor consensus by design, so paying for it in a public-chain asset is less of a privacy loss than paying for, say, a personal VPN this way. XMR still makes sense if you do not want the invoice addressable to a wallet you reuse; USDT on TRC-20 makes sense when fees and price stability dominate. If you fund a balance once, the fund tiers at $1,000 (+10%) and $2,000 (+40%) let a single deposit carry a year of a $288 Business relay with margin to spare, and no further payment events touch the account during that year.

What a Tor exit on our network won't do

It won't shield the exit IP from reputation damage. Any exit will collect blocks from services that blanket-ban Tor ranges — that is their choice, not an outage, and no plan tier prevents it. It won't survive a policy that ignores the abuse desk: if you set an open ExitPolicy and ignore complaint mail, the standard escalation path for persistent abuse applies the same as to any other service. It won't turn a 1 Gbps port into unlimited exit bandwidth for a thousand-user relay — the unmetered port is real, but the relay's practical throughput is bounded by the plan's port and the rack's uplink, and the bandwidth rate you set in torrc is yours to configure honestly.

It also won't make the relay anonymous from us in the sense of zero data: we see the account token, the plan, the IP and the payment asset — nothing more is requested at signup — but 'no KYC' is not the same as 'no records exist'. Run your own threat model accordingly: if you need the operator to know literally nothing, a relay you cannot describe to anyone is the wrong mental model. What we do provide is the mechanical part: token-only signup, 19-asset checkout, unmetered 1–10 Gbps ports, ECC RAM across the VPS line, and racks with real peering (AMS-IX, DE-CIX and peers) so the relay's traffic has short paths out.

Where the limits are (October 2026)

Keep the threat model precise. Anonymous-adjacent hosting removes the host-side identity trail: token-only signup, optional email, no KYC review, crypto invoices that record a txid rather than a name. It does not blind the host to traffic it must carry, it does not make a logged-in panel session anonymous, and it does not protect workloads that identify themselves — an admin login from your home IP defeats the whole design. Exact limits of no-KYC anonymity. OPSEC guide. Full checklist. Payment-side note: chain analysis happens on public blockchains, not at the host. Coin choice and network choice are your OPSEC knobs, and the checkout keeps 19 of them open.