Hosting a Tor Onion Service (v3) on a VPS

How a v3 onion service runs on a root KVM with no public IP, no DNS and no open port — from $6.00/mo annual-eff on a no-KYC VPS.

Published 2026-08-30 · Updated 2026-10-14 · FYRHost Editorial · 16 min read

What an onion address actually replaces

No public IP, no DNS record, no open port sounds like marketing until you read the rendezvous design, and then it reads as engineering. An onion service publishes a 56-character address instead of a socket; clients build Tor circuits to introduction points, meet the server at a rendezvous point, and the server's IPv4 never appears anywhere in that path. You are not hiding behind a firewall rule — the address simply has no public coordinate to find.

The mechanism has three roles. The service picks introduction points and uploads signed descriptors to hidden service directories, which the project documentation describes in detail. A client fetches the descriptor, builds a circuit to an introduction point, and negotiates a rendezvous point both sides reach over their own circuits — 6 hops in total between them. The application itself keeps listening on localhost, and Tor tunnels requests in, so nginx or whatever serves content never needs a public bind at all.

Where expectations break first is the word anonymous. The address hides the service from the network; it does not hide sloppy administration from the box. If you log into the same machine over clearnet SSH from a home line, or the application phones home with analytics, the correlation work happens on your side, not Tor's. Treat the onion as a network property and keep the operating habits separate — the backend placement question gets its own section below.

The second surprise is scope: this page is about hosting services, not running relay infrastructure. A middle or exit relay is a different workload with different abuse exposure, different bandwidth economics and a different playbook, and the relay documentation is where that lives. If the plan is a website, an API or a chat endpoint reachable as a .onion, everything that follows applies directly to a plain root-server VPS.

The pieces Tor actually runs on the box

One daemon does all the work. Install Tor from the project's own repository so you track current releases rather than a distribution's year-old package, then declare the service in torrc with two lines: a HiddenServiceDir and a HiddenServicePort 80 127.0.0.1:8080 mapping. The first names a directory Tor owns; the second says which local socket answers when a client requests port 80 on the onion. Nothing else about the application changes.

On first reload, Tor generates the v3 keypair — an ed25519 pair — and writes the 56-character hostname into the service directory. That string is the address, and it exists only because the private key says so; the source repository documents the format if you want the crypto details. Reload with systemctl reload tor rather than restarting bluntly, because a restart tears down live circuits that paying clients are mid-flight on, and they see errors you caused.

The mistake that costs an afternoon is editing torrc with a syntax slip and reloading: Tor exits, the service disappears, and the journal line explaining which line number failed sits unread. Run tor --verify-config after every edit — it parses the file and exits — before any reload touches the running daemon. The second slip is permissions: the service directory must stay owned by the tor user, and a chmod adventure there makes the daemon refuse to read its own keys.

Version drift is the quieter failure. An onion built on an end-of-life package keeps working until a client-side security change locks it out, and you find out from user reports instead of a monitor. Pin the upstream repository, update on the same cadence as the security news, and check the hostname file's timestamp when you do — an address that stops resolving after a system update is almost always a config regression you introduced, not a network mystery.

Daemon, keys, mapping, reload discipline: that is the whole moving part inventory. What remains is choosing the box underneath, and there the geography-versus-latency question catches people who assume an onion cares where it lives — it does not, and the next section turns that into a decision rule.

Choosing the box and the location

Geography is irrelevant to a .onion: clients reach the service through circuits, so a rack in one city answers as fast as a rack in another from the address's point of view. What location actually changes for you is administration latency — SSH round-trips while you edit configs — and jurisdiction posture, because abuse complaints route under the facility's law. Pick by those two factors and ignore ping-to-users entirely; one list price covers all 40 sites.

Take Sentry at $7.50/mo list — $6.00 annual-eff — for a small onion: 2 vCPU, 4 GB and 60 GB of NVMe carry a static site, a forum or an API gateway with circuits to spare. The premium flags are priced openly if jurisdiction matters to you: Iceland and Norway add 20 percent, Switzerland 35 percent, Luxembourg, Cyprus and Panama 15 percent, and the rest bill at list. Signup is an inbox plus a 12-character password or a bare token, and the box boots about 60 seconds after the crypto invoice credits.

Where sizing breaks is the bandwidth instinct: onions do not serve volumetric traffic from your port the way clearnet sites do, so the uplink number matters less than RAM when circuit counts climb. High-traffic services exhaust memory before they exhaust CPU, because every concurrent client connection lives as state in the daemon. If the plan is a busy endpoint rather than a brochure, scale the memory line first and let the core count follow.

The second sizing error is running the onion on the same cell as everything else you own, then wondering why a bad deploy on the clearnet site slows the onion too. One role per box keeps failure domains apart, and at these prices the separation costs less than the debugging time it saves. Decide the split before the first launch — after, you are migrating keys and rewriting client bookmarks at the same time.

Box chosen and service declared, the next surface is the backend itself: what binds where, and which headers leak the clearnet twin you may or may not want connected. That is binding discipline, and it is the next section — the place where most leaks in otherwise careful onion setups actually happen.

Binding the backend so nothing leaks

The rule is one line: the application answers on 127.0.0.1 only. A web server left on 0.0.0.0 advertises the clearnet face you built the onion to avoid, and scanners will find the port within hours of the IP going live regardless of your intentions. Check with ss -tlnp after every deploy — the output should show your app on a loopback socket and nothing else public except SSH.

The mapping in torrc does the rest: HiddenServicePort 80 127.0.0.1:8080 tunnels client requests to that loopback socket, and Tor exposes a SOCKS interface on port 9050 for outbound testing through the network. If a reverse proxy sits in front of the app, bind the proxy to loopback too and let it think it is public — the virtual host logic still works, and loopback sockets simply have no route to the outside.

Where leaks happen is application behavior, not sockets. A CMS that generates absolute URLs from the Host header will happily write https://your-real-domain into every page it serves, and Onion-Location headers — the documented way to advertise the onion twin from a clearnet site — cut both directions, so decide deliberately which way the link goes. Disable external CDNs and analytics entirely; each one is a third party watching your onion's traffic, which defeats the point at the last hop.

The classic mistake is the staging shortcut: binding 0.0.0.0 to test something quickly and shipping the config. The symptom arrives as scanner noise in the logs within the day, because every public IPv4 is enumerated continuously. Make the loopback check part of the deploy checklist — one ss line between build and done — and the leak class disappears rather than gets patched when noticed.

Binding settled, one asset remains that outranks everything else on the box: the key pair that makes the address exist at all. Losing it ends the service; leaking it clones the service. Key custody is its own discipline, and the next section is where the backup rituals belong.

Key custody: the address is the key

The v3 private key is not a credential for the service — it is the service. Lose the directory and the 56-character address dies with it, since there is no recovery, no registrar and no reset flow. Leak it and anyone can publish the identical address byte for byte from their own box, complete with valid descriptors. Every operational habit in this section follows from treating that file the way you would treat a wallet seed.

Back it up the day you create it. The default location is /var/lib/tor/hidden_service/, holding the private key and the hostname file, and the backup belongs somewhere the box cannot reach: an encrypted archive on storage you control, tested by an actual restore, not by a file listing. A copy sitting in the same filesystem as the live key protects against nothing except your own rm — which is the least interesting failure it will face.

Where custody breaks is the rebuild reflex. The box gets wedged, you recreate the service directory to fix it, and Tor happily generates a fresh keypair — a new address, with every bookmark, flyer and forum signature now pointing at a service nobody owns. Never let a recovery script include a fresh HiddenServiceDir creation; restoring keys is always slower than generating them, and that slowness is the feature you are paying for.

The second habit is access discipline: the key file needs root or the tor user and nothing else, and if you ever rotate it deliberately, do it as a planned migration with overlap — publish the new address from the old one before retiring it. An address change users discover by accident reads as a breach even when it was housekeeping, because from the outside the two look identical.

Keys guarded, the remaining questions are operational: what the network can and cannot do to you, which rules apply to a hidden service, and how the daily routine keeps the thing up. Traffic and attacks come first, because the volumetric story has a twist that surprises people used to clearnet hosting.

What floods can and cannot reach an onion

Volumetric DDoS has no target here: with no public IP and no open port, there is no pipe to saturate at the edge of your provider, because reflection traffic needs an address that answers. That is a structural property of the design, not a filtering product, and it is the honest answer to whether an onion needs the protection tiers a clearnet site wants. The filtering guide covers that platform side; an onion simply starts past most of it.

What can still arrive is application-shaped pressure through the circuits themselves — request floods that look like readers, introduction-point hammering, rendezvous churn. Newer Tor versions ship rate-limiting knobs for exactly this: HiddenServiceEnableIntroDoSDefense 1 enables defenses on the introduction layer, and you can cap concurrent circuits per source. None of it is a switch that makes abuse impossible; all of it raises the attacker's cost per request above the value of annoying you.

The capacity mistake mirrors that division of labor. Operators buy uplink speed for a service that never uses it and starve the line that matters, which is RAM — every live circuit holds state, and a busy endpoint outgrows memory before CPU. Pick Warden at $19.00/mo list when circuit counts climb: 6 vCPU and 16 GB of DDR5 absorb busy services, and the jump from 4 GB is where most growing onions feel the ceiling move.

Where monitoring breaks is the temptation to measure from inside the tunnel only. A service can be healthy from your own SOCKS fetches while introduction points are quietly refusing new clients, and users see timeouts you do not. Test through a separate client circuit, watch the daemon's notices rather than the application logs first, and treat a rising rate of circuit builds that never complete as the onion equivalent of packet loss.

Traffic handled, the policy layer needs one clear statement, because hidden services attract assumptions about lawlessness that the actual rules do not support. What the AUP says, where abuse lands and which content classes are simply out — that is the next section, and it is shorter than people expect.

Rules, abuse and the policy layer

Tor hosting and onion services are an explicitly allowed workload: the AUP reads the same for a .onion as for a clearnet site, no special permission is required, and there is no abuse deposit to post before the first launch. The banned classes are stated once for both worlds — CSAM, phishing, spam and network attacks — and hiding behind an address does not move content across the line; it only moves the reader's path to it.

Abuse complaints route under the facility's jurisdiction, which is the practical meaning of location choice for a hidden service: the 40-city map spans jurisdictions with different postures, priced at Iceland and Norway plus 20 percent, Switzerland plus 35 percent, Luxembourg, Cyprus and Panama plus 15 percent, and list elsewhere. The project's support portal answers the protocol-side questions; the jurisdiction question is answered by the facility you pick at checkout.

Where assumptions break is the reverse direction: operators expecting the host to be an anonymity service. It is not — the box behaves like any root server you administer, and the privacy properties come from the design plus your habits. Connection metadata is kept at most 24 hours, there are no payload or traffic logs, and billing runs on 19 coins with no identity check; what you do from the shell afterward is the part no plan description covers.

The typical mistake is treating the policy line as unclear enough to matter-of-factly blur — it is not, and services that spam or attack find their sessions ended under the same facility rules a clearnet spammer would face. Onion is a network property, not a policy carve-out, and reading the AUP once before launch costs five minutes against a lost service later.

With traffic and rules both mapped, what remains is the unglamorous part that keeps a service up for years instead of months: monitoring, updates, backups and the small rituals that catch problems while they are still cheap. The next section is that routine, in the order a working operator would actually run it.

Operating habits that keep an onion up

Monitoring an onion starts with fetches through the network, not around it. Script a periodic request via the SOCKS interface — curl --socks5-hostname 127.0.0.1:9050 against the onion address — and alert when it fails twice in a row, because that is what a user's client experiences. Inside the box, systemctl status tor and the daemon's notices tell you whether failures are circuits, descriptors or your application, three very different repair paths.

Update cadence matters more than for a typical daemon, because client-side countermeasures evolve: an onion that lags releases eventually meets a version gate it cannot pass, and the outage is scheduled by someone else. Track the upstream repository, apply security updates within days rather than quarters, and read the release notes for anything touching hidden service behavior — the changes that break services are announced, just not loudly.

The administration surface is where discipline pays most. SSH keys only, the firewall default-deny, and the daily driver account unprivileged — the hardening checklist covers the ordering — plus one onion-specific habit: reach your own admin panels through a second hidden service rather than through any public bind. The sshd_config reference documents the knobs, and ssh over a tunnel keeps the management path off the clearnet entirely.

Where routines break is drift: the box that worked in January silently accumulates a second application, a test vhost, a debugging endpoint on an odd port, and by June the one-ss-line check fails because the list is longer than you remember. Re-run the baseline checks monthly, keep the service directory backed up after every legitimate key change, and treat any address mismatch between backup and live as an incident, not a curiosity.

Every habit above assembles into a launch sequence, and the last section lines it up in the order you would type it: account to keys to binding to first client fetch. Nothing in it is exotic — the whole design is that an afternoon of careful setup yields an address no scanner can find.

The onion service, in the order to run it

Start at the account: inbox plus a 12-character password or a bare token, 19 coins to pay with, and the box up about 60 seconds after the credit. Pick the location for jurisdiction and admin latency, not for users — geography is invisible to a .onion — and take the 2 vCPU, 4 GB tier for a small service, scaling memory later if circuits pile up. Install Tor from the project repository before anything else touches the box.

Second, declare the service in torrc: the HiddenServiceDir and the HiddenServicePort 80 127.0.0.1:8080 mapping, then tor --verify-config before a reload, every time. Third, bind the application to 127.0.0.1 only and confirm with ss -tlnp that nothing public answers except SSH. Fourth, copy the service directory off-box into an encrypted archive the same hour it is created, and test that the restore produces the same hostname file before you call the address real.

Fifth, publish: hand the 56-character address to the people who need it, decide deliberately whether a clearnet twin advertises it via Onion-Location or stands alone, and strip external CDNs and analytics from the pages so the last hop stays yours. Sixth, enable the introduction-point defenses and circuit caps if you expect attention, and set the RAM-sized plan that matches real circuit counts rather than uplink fantasy numbers.

Seventh, rehearse: fetch the service through a fresh client circuit, kill the application and watch the monitor fire, restore the key archive into a scratch directory and compare hostnames. Eighth, schedule the rhythm — upstream updates within days, the monthly baseline re-check, and a quarterly restore drill. Re-check the backup archive after every legitimate key rotation, since a restore that produces a different hostname file is an incident you want to meet in rehearsal, not on a live 56-character address. Run in that order, the service keeps one property people pay for and rarely get: an address that simply continues to exist.