Self-host a Tor v3 hidden service.
Twenty minutes to your own .onion.

A v3 onion address is a 56-character base32 string ending in .onion, derived from an Ed25519 public key. v2 (deprecated and disabled by Tor since 2021) used a 16-character base32 from a truncated RSA-1024 key — short, but cryptographically much weaker. v3 has a stronger key (Ed25519), better directory privacy (no enumeration of services), client authorisation support, and is the only version still operational. If you see a 16-character .onion address, it is dead.

A correctly configured one does not. Tor connects out from your VPS to three Tor relays (a guard, a middle, a rendezvous) and never accepts inbound connections directly on the VPS IP. The hidden service is reached only through the Tor circuit. Misconfigurations that DO leak the IP: running the service on a public port (it should be 127.0.0.1-bound), DNS leaks from the hosted web app, server-software banner-stamping the IP into outbound responses. The standard checklist below covers each.

Your VPS provider sees outbound Tor traffic from your VPS — they know "this server runs Tor" but not what content is reached. They cannot see what is on the hidden service from the outside; they can see what is on the disk from the inside, like any VPS provider. NordBastion does not access customer disks, but a server you do not control with full-disk encryption is a server an operator can theoretically read. For absolute hidden-service privacy, run LUKS with a passphrase only you have — Servury packages that out of the box on owned hardware, others (NordBastion included) leave it as a customer-installable.

Use mkp224o — an open-source tool that brute-forces Ed25519 key pairs until the resulting v3 address starts with a chosen prefix. A 4-character prefix is found in minutes on a modern laptop; a 7-character prefix takes a few hours; 10+ characters takes weeks to months on dedicated hardware. The resulting onion address is cryptographically valid — the brute-force only finds the key whose hashed public part happens to start with the desired characters.

Slower than clearnet. Tor routes through three relays, so each round-trip adds ~300-800ms of latency. Throughput is bottlenecked by the slowest relay in the chosen circuit; expect 1-5 MB/s on average for static content, less for interactive workloads. Tor introduced "HSDir bandwidth" optimisations and HiddenServiceSingleHopMode for cases where the service-side anonymity is not required.

Only if your threat model accepts that the SERVICE side is publicly known (e.g., you have already published "this onion runs on my server in Iceland"). Single-hop mode skips the guard+middle relays on the service side and connects directly to the rendezvous, which is faster (200-400ms less latency) but does not protect the service-side IP. Clients still get full three-hop privacy on their side. For a hidden service that needs server-side anonymity, leave it disabled (the default).

Yes, and many sites do. The clearnet web server listens on the public IP at port 80/443; the Tor hidden service points to the same web server at 127.0.0.1 on the same ports. Both reach the same content. Two operational notes: (1) make sure the web server does not stamp the public IP into headers (Server, X-Real-IP, hostname banners), and (2) set the Onion-Location HTTP header on the clearnet site so Tor Browser users get auto-redirected to the onion address.

A Tor add-on (Vanguards) that pins the guard relay at the service side, mitigating a class of attacks where an attacker observes which guards the service rotates through and uses that to deanonymise. Vanguards-lite is built into the Tor daemon since 0.4.7 and is enabled by default for hidden services in current Tor versions — you generally do not need to do anything to benefit from it. The full Vanguards add-on is overkill for most personal hidden services and useful mainly for high-value targets.