Hosting a Tor Onion Service (v3) on a VPS

How an onion service works, why the backend never needs a public IP reputation, and the setup path for a v3 hidden service on your own KVM.

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

What an onion service actually is

An onion service publishes a .onion address instead of serving on the public internet. Clients reach it through Tor circuits; your server's IP stays out of DNS entirely. The service itself runs on localhost — Tor tunnels requests in. Middle relays and exits are a different animal (see the Tor relay playbook).

Setup path

1. Provision a plain VPS — any location; the .onion does not care about geography, pick by your admin latency.
2. Install Tor from the Tor Project repository, declare a HiddenServiceDir and HiddenServicePort 80 127.0.0.1:8080.
3. Tor writes the .onion hostname into the service directory — that is your address; back the private key up.
4. Bind your app to 127.0.0.1 only. Configure Onion-Location headers if you also serve clearnet.

Operational notes

• Keep the v3 key safe: lose it and the address is gone; leak it and the address can be cloned.
• Onions are DDoS-resilient by architecture — there is no public IP to flood.
• Legal content only: the AUP applies to onion services exactly as to clearnet sites.

Prerequisites: what to prepare before you publish an onion service

An onion service needs less infrastructure than almost anything else you will host - no domain, no TLS certificate, no open inbound ports, no public IP association - but the preparation list is specific, and skipping its rows is where most first attempts stall.

The counterintuitive row is the inbound ports one: an onion service makes no inbound connections at all. Tor dials out to build its circuits, so a firewall that permits only established outbound traffic still hosts a perfectly reachable onion. That property is also why an onion works fine on any of our 21 locations at the identical plan price - network position barely affects onion routing.

Step by step: a working v3 onion in about ten commands

The whole deployment fits in one SSH session. The commands below assume Debian or Ubuntu with the backing service already listening on 127.0.0.1:80 - get that working first, since Tor will only be as healthy as the service it fronts.

1. Add the official Tor package repository and install: apt install tor (after adding the repo per the Tor Project's download instructions). Verify with tor --version.
2. Edit /etc/tor/torrc and add two lines: HiddenServiceDir /var/lib/tor/my-site/ and HiddenServicePort 80 127.0.0.1:80.
3. Restart the daemon: systemctl restart tor. Bootstrapping takes a few seconds; journalctl -u tor should show "100%: Done".
4. Read your new address: cat /var/lib/tor/my-site/hostname. That 56-character .onion string is live immediately - open it in Tor Browser and your site answers.
5. Restrict the backing service to loopback only: nginx should listen 127.0.0.1:80;, so the site exists exclusively on the onion, not on the public IP.
6. Back up the key directory: tar czf onion-key-backup.tar.gz -C /var/lib/tor my-site, then move that archive off the server over SSH. This is the address's identity; treat it like a private key, because it is one.
7. Optionally add a second port mapping - HiddenServicePort 443 127.0.0.1:80 - so both scheme prefixes resolve to the service.

Total elapsed time is usually under ten minutes. The only steps people skip and later regret are the loopback restriction (leaving the site on the public IP undoes the point) and the key backup (a reinstall without the key means a new address and dead links).

How to verify the onion is actually yours and working

Verification has to answer three questions: is the address live, is it the address your key generates, and is the backing service the thing answering. Check all three from outside the server, because testing from the box itself proves nothing about the path real visitors take.

1. Liveness from a clean client. Open the .onion in Tor Browser on a different machine or network. First load takes seconds while circuits build; subsequent loads should be comparable to a small clearnet site.
2. Key-to-address match. Recompute the address from the backed-up key: restore the key directory on any machine with Tor installed and let it publish - the hostname file it generates must match your live address character for character. This proves your backup is real, not corrupt or truncated.
3. The right backend answers. Serve a marker page - a file with a distinctive string - as the loopback site's index. If the marker comes through the onion, the full path works; if you see the default nginx welcome page instead, you are answering on the wrong server block.
4. Descriptor propagation. After a restart, the service re-publishes its descriptor; if a fresh Tor Browser cannot connect for a minute or two after your restart, that is normal descriptor timing, not an outage. Wait, then retry before debugging.

Repeat the backup-restore check whenever you regenerate keys or migrate servers, and keep two verified copies of the key in different physical places. The address is reconstructible only from that key - there is no registrar to call.

Troubleshooting: why your onion service is unreachable

Symptom → cause → fix, ordered by frequency. Before anything else, read journalctl -u tor -e - Tor's own log states the failure stage (bootstrap, descriptor publish, circuit build) and that stage names the row below.

1. Symptom: browser shows "onion service not reachable" forever. Cause: the backing service is down or no longer on the loopback port Tor dials. Fix: curl -I http://127.0.0.1:80 on the server must return your site; fix the backend before blaming Tor.
2. Symptom: tor exits fatal at startup. Cause: syntax error in torrc or wrong permissions on HiddenServiceDir. Fix: Tor runs as the debian-tor user - the directory must be owned by it with 0700. Run tor --verify-config to get the offending line number.
3. Symptom: worked before a reboot, now nothing. Cause: tor service not enabled. Fix: systemctl enable --now tor; check that the service also starts after your backend does, or add a small start delay.
4. Symptom: reachable from some clients, not others. Cause: stale descriptor caches or client-side clock skew. Fix: confirm server time with timedatectl status; on the client side, a "New Tor circuit for this site" often clears a bad cached path.
5. Symptom: address changed after reinstall. Cause: the key directory was not restored before tor started, so a fresh key was generated. Fix: stop tor, restore your key backup into the directory, start tor - the original address returns. This is why the key backup step exists.

Performance: what onion latency costs and how to claw some back

Honest baseline: a v3 onion connection routes through six relays in three hops per direction, and the added latency is seconds on first circuit build, then typically tens to a few hundred milliseconds per request - enough to feel on interactive use, invisible on document-style browsing. No hosting choice removes that, because the cost lives in the Tor network, not the last mile. What the server side controls is everything after Tor hands off the request: a local backend on loopback sees zero network overhead, and NVMe-backed responses keep the per-request work small.

Practical tuning, in order of impact. Enable Tor's connection pooling rather than letting each request tear down circuits - defaults are reasonable, but avoid exotic torrc tweaks that promise speed; they usually degrade anonymity. Keep the backing application lightweight and cache-friendly: onion visitors tolerate the Tor overhead but not extra round trips inside your own app. Compress responses; bytes cost time on circuits. Avoid heavy single-page frameworks that fire dozens of sub-resource requests, which multiplies the per-request penalty - a static site or server-rendered pages feel dramatically faster than a JS-heavy bundle over the same onion. On the plan side, none of this is RAM-hungry: a single onion-fronted site idles well under 1 GB, which keeps Nano ($5.49/mo, $36/yr flat) viable for text sites, with Starter the comfortable default once an application server or database sits behind the onion. Uplink size is irrelevant to onion performance - the bandwidth ceiling that matters is the volunteer relay network's, not your port's.

Paying for an onion box without undoing the point

Design coherence check: an onion service whose visitors are anonymous loses most of its value if the billing account names someone and the payment carries a card trail. This checkout closes that loop natively - token-only signup with email optional, and 19 crypto assets including BTC, XMR and USDT across seven networks. For an onion deployment the reasoning parallels the service itself: XMR breaks the on-chain link between buyer and invoice; a public-chain payment is fine where that link does not matter to your threat model, and the honest framing is that the chain, not the host, is what publishes it.

Operational anonymity of the hosted service needs one more deliberate choice: the onion's location is in no DNS zone and no certificate log, so the usual leaks do not apply - but the server's public IPv4 still exists and can host other things. Either keep the onion-only discipline (loopback binding, no clearnet vhost) so the box's IP is never associated with the site, or accept and design for the association. If the address itself is sensitive, run the onion alone on the box, pay in a private asset, and manage the account over Tor from the start rather than retrofitting it.

Where the budget lands: a single onion service runs comfortably on Nano at $36/yr flat; with an application backend, Starter at $8.50/mo - $6.80/mo on the annual -20% term - carries it with headroom. Quarterly and annual terms just cut the invoice size; nothing about the plan changes for onion workloads, and the same checkout serves clearnet, onion, or both.

Plan and location for an onion service: what actually matters

An onion service inverts the usual hosting checklist: geography barely matters and admin latency matters most, because the .onion address has no relationship to the server's IP or country. Clients build Tor circuits to the service; the location only sets how fast you can SSH in to maintain it. Pick the plan by traffic and state, not by the address: Starter at $8.50/mo - 2 EPYC 7443P vCPU, 4 GB ECC RAM, 60 GB NVMe - runs a personal site or self-hosted service comfortably; Nano at $3/mo effective handles a static onion; high-traffic services want Business at $30 ($24/mo billed yearly) for RAM and connection tables. Bandwidth is unmetered on 1-10 Gbps ports on every plan, which matters because onion traffic is chatty by design. Tor hosting including onion services is an allowed workload here under the same AUP as clearnet - legal content, no attacks. No KYC, 19 crypto assets, optional email, and the deploy finishes in about 60 seconds, which is convenient because the rest of the setup is all yours.

Hardening a long-lived onion: keys, descriptors, and vanguards

A v3 onion address is its keypair - protect it like one. Back up the HiddenServiceDir immediately: lose it and the address is gone; leak it and anyone can clone the service. For services that live months, run vanguards-style layer-2/3 guard pinning so an attacker cannot force guard rotation and probe their way toward the backend; a small service that redeploys weekly has different math than one that stays put for a year. Keep the application bound to 127.0.0.1 so it is reachable only through Tor, and disable any service that would announce the server's real IP - no IPv6 listener, no analytics callback, no certificate transparency trail from a TLS cert that names your domain. Onion services need no certificate at all; the address itself authenticates the connection. Test the leak surface the boring way: inspect what the app emits in headers and error pages, because software loves to volunteer hostnames. One operational note: descriptor publishing takes a few minutes after Tor starts, so an onion that seems 'down' right after reboot is often just mid-publish.

What an onion service does not protect against

Name the residual risks before trusting the architecture. The backend IP stays hidden from clients, but traffic-correlation attacks over long windows remain the academic threat to any Tor-hidden service, which is exactly what guard pinning mitigates rather than eliminates. The server itself is a normal root box: a compromised application leaks whatever it holds, and an operator mistake - a DNS record, a certificate, an email from the box - deanonymizes faster than any circuit attack. Abuse and legal limits are unchanged: the AUP applies to onion services exactly as to clearnet sites, criminal content is out everywhere, and hosting in a favorable jurisdiction does not legalize content where you live. Availability is a real limit too - onion services depend on the Tor network's health, and a flood against the descriptor infrastructure can slow reachability even though there is no public IP to DDoS directly. Finally, users must bring their own Tor Browser; the service cannot make a clearnet visitor reach it. Plan for those limits and the onion model delivers what it actually promises: no public IP, no DNS, no CDN in the path.

Onion-only, or clearnet with an Onion-Location header

Serving the same site both ways is common and cheap, but the two modes have different leak profiles worth deciding in advance. Onion-only: the strongest posture - no domain to register, no certificate transparency trail, no public IP in DNS - with the cost that only Tor Browser users arrive and discovery is word-of-mouth. Dual-mode: clearnet TLS plus the Onion-Location header, which tells Tor Browser users a .onion exists and switches them to it automatically; you keep clearnet reachability, and you accept everything clearnet implies - a domain, a CT log entry, a public IP that can be scanned. If you go dual, keep the identities severed at the application: the clearnet vhost should not embed absolute onion URLs in pages that clearnet crawlers archive, and the backend should serve both vhosts from one bind on localhost so neither references the server's real address. Cost-wise both modes fit the same hardware - a Starter at $8.50/mo runs Tor, the web server and the TLS termination comfortably, and the .onion itself costs nothing but the keypair's backup discipline.

Load-balancing onion traffic across two racks without splitting the identity

The direct answer: onion services balance over multiple introduction points natively, and the practical way to add capacity is running the same onion descriptor from two servers — with the private key synced between exactly two places you control, never copied through chat or email.

The mechanics: the .onion identity lives in the service's private key file (the v3 key under HiddenServiceDir). Two Tor instances holding the same key publish descriptors for the same address, and clients reach whichever introduction path answers first — this is onion-level redundancy that no external load balancer provides, because there is no clearnet DNS to round-robin. Deploy the second instance on a separate BitCloudVPS rack (any of the 21 sites, same no-KYC checkout) and copy the key with scp or an encrypted transfer you control; the descriptor publication interval means failover takes minutes, not seconds, so treat this as redundancy against rack loss rather than true high availability. Keep the backing application state shared or replicated exactly as you would behind a clearnet balancer — Tor changes the transport, not the consistency problem. Verify the setup by stopping Tor on the first server and confirming clients still reach the .onion within the descriptor refresh window; if they do not, the second instance's key is not actually identical, and that is a copy-step bug, not a Tor mystery.

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.