How to Set Up a Tor Hidden Service on Anonymous VPS

Running a Tor hidden service from a residential connection works fine until your ISP renegotiates the contract, the IPv4 lease rotates, or someone with a court order shows up at the front door. The entire point of an .onion address is to decouple the service from a meatspace identity, and that decoupling collapses the moment the underlying network path can be traced to a name on a utility bill. That is why operators who care about long-term durability — Monero remote nodes, BTCPay servers, Matrix bridges, mirrors of getmonero.org — almost always rent a dedicated virtual private server from a host that accepts payment without identity verification.

This guide walks through the full pipeline for 2026: picking a VPS provider that takes Monero or unmarked cash, paying anonymously, hardening a fresh Debian 12 install, and bringing up a v3 onion service that survives reboots, kernel updates, and the occasional rDNS scan. Examples assume you intend to expose a Monero node, but the same recipe applies to any TCP service — Lightning, SSH, IRC, or a static website you would rather not connect to your legal name. When the goal is reaching a service like MoneroSwapper through a fully isolated endpoint, this network layer is the part that has to be right before anything else matters.

Why anonymous hosting matters for hidden services

A Tor v3 onion address derives from an ed25519 public key. The cryptographic guarantee is straightforward: anyone who can reach the .onion connects through three hops of Tor relays, and the rendezvous point never learns the server's IP. That much is sound. What Tor cannot do is hide the fact that you paid Hetzner €4.50 a month from a Visa tied to your name. The moment a hostile party correlates uptime patterns or a config leak with the billing record, the entire anonymity property of the service evaporates.

The threat models that justify a no-KYC VPS are concrete and overlapping:

• Subpoena pressure: Mainstream hosts (Vultr, DigitalOcean, Hetzner, OVH) keep KYC records and full payment history. Under a US grand-jury subpoena, an Article 18 production order in the EU, or a UK Investigatory Powers Act notice, those records are turned over with minimal friction and no public disclosure.
• Civil litigation discovery: A privacy lawsuit, copyright complaint, or trademark dispute can compel a provider to identify the customer behind an IP without any criminal proceeding at all. Discovery is faster and cheaper than indictment.
• Network-side fingerprinting: Even when a hidden service is configured correctly, application-layer leaks (server banners, NTP source, kernel version in error pages) can correlate the .onion with a public IP. Anonymous payment ensures that correlation does not back-end into a name.
• Operational resilience: Hosts that already operate KYC-free understand the threat surface. They are usually willing to receive an abuse report without instantly nuking the VPS, because they expect their customers to have legitimate privacy reasons rather than treating every complaint as ground truth.

The Monero ecosystem is the canonical example. Public remote nodes listed on monero.fail or in Cake Wallet's default seed list routinely run as v3 onion services because operators want to provide service without becoming targets. The same logic applies to atomic swap clients, P2Pool sidechains, and merchant-side BTCPay deployments. Once you have run any of these, you understand quickly why the VPS-and-onion combination is the default rather than a paranoid extreme.

Choosing a KYC-free VPS provider in 2026

After the FATF Travel Rule expansions of 2024 and the EU's CARF (Crypto-Asset Reporting Framework) entering force on 1 January 2026, the list of providers that accept genuinely anonymous payment has shrunk but not disappeared. The European hosters that survived are the ones that explicitly position themselves around privacy rather than offering it as a marketing afterthought, and the offshore providers that survived are the ones with a documented track record of refusing fishing expeditions.

Three constants define a usable provider in this market:

1. Accepts Monero (preferred) or Bitcoin via mixing-friendly channels, with no email verification beyond a working address that can receive a one-time link.
2. Does not require a phone number, a government ID upload, a selfie, or a credit-card 3-D Secure handshake at any point in the signup flow.
3. Operates from a jurisdiction with a defensible posture toward privacy — Iceland, Switzerland, Romania, Bulgaria, or specific offshore zones — rather than from a Fifth Amendment edge case in the United States.

The table below summarises providers most commonly cited by Monero operators in late 2025, with their typical entry-tier pricing and key trade-offs. Prices fluctuate with the XMR/EUR rate; treat them as ballpark figures.

Provider	Entry price / month	Pros	Cons
Njalla (SE/NL)	~€15	Strong privacy track record, accepts Monero directly, runs its own ASN with custodial domain registration.	Higher price tier, smaller fleet, occasional VPS waitlist.
1984 Hosting (IS)	~€10	Iceland jurisdiction, geothermal-powered, Monero accepted via third-party gateway.	Limited IPv4 supply, only one datacentre region.
BitLaunch (multi)	~$5	Resells DigitalOcean, Vultr, and Linode behind a crypto front-end, very fast deploys, hourly billing.	Underlying provider still has the network logs; not bulletproof against upstream subpoena.
Cockbox (US)	~$15	Free-speech operator, Monero accepted, public no-logs policy.	US jurisdiction, small one-person operation, no SLA.
BuyVM / Frantech (LU/CA)	~$3.50	Cheapest sustained option, accepts crypto, generous unmetered bandwidth on most plans.	Less privacy-forward branding; payment hygiene is on you.
Privex (multi)	~€5	Long-running Monero-friendly host, footprints in Iceland and Sweden, supports IPv6-only tiers.	Stock fluctuates, older hardware on the cheapest tier.

Pay with Monero whenever the option exists. Bitcoin payments, even when routed through CoinJoin or a non-KYC swap, leave a traceable UTXO graph that future chain analysis may collapse. Monero's RingCT, Bulletproofs+, and stealth address construction make payment-side deanonymization effectively impossible with currently published techniques. If a provider only accepts Bitcoin, use MoneroSwapper or an equivalent no-account swap to convert XMR to BTC at the last possible moment, send directly to the payment address from a fresh wallet, and never reuse the source wallet for anything else.

Email and signup hygiene

Use a fresh email per provider — disposable inboxes like cock.li, danwin1210.de, or a self-hosted catch-all on a separate domain. Never reuse a username, a password, or an SSH key fingerprint that exists in any other context. The signup IP should already be on Tor or a VPN that is not paid with the same identity as anything else you operate. Treat every form field as a permanent disclosure: anything you type into the signup is the worst-case identification surface for the entire lifetime of the VPS, and that lifetime can stretch into years.

Step-by-step: deploying a Tor v3 onion service

The procedure below assumes a fresh Debian 12 (Bookworm) VPS with a single public IPv4, root SSH access, and the rental already paid via Monero. Steps are written to be copy-pasteable, but read each one before executing — defaults change between releases and a careless paste can lock you out of the box.

1. Initial hardening. SSH in as root, create a non-root user with sudo, disable root login and password authentication in /etc/ssh/sshd_config, restart sshd, and enable ufw with default-deny inbound. Open only SSH (preferably on a non-standard port) until Tor is installed and verified.
2. System updates and baseline packages. Run apt update && apt full-upgrade -y, then install tor, nyx, ufw, fail2ban, unattended-upgrades, and apt-listbugs. Enable automatic security updates via dpkg-reconfigure -plow unattended-upgrades and confirm with systemctl status unattended-upgrades.
3. Install the official Tor repository. The Debian-shipped Tor is often weeks behind. Add the Tor Project's repo to /etc/apt/sources.list.d/tor.list, import the signing key, and reinstall tor and tor-geoipdb from upstream. Confirm with tor --version — expect 0.4.8.x or newer through 2026.
4. Configure the hidden service. Edit /etc/tor/torrc: add HiddenServiceDir /var/lib/tor/monero-node/, then HiddenServicePort 18089 127.0.0.1:18089 for a public Monero remote node, and finally HiddenServiceVersion 3. For non-Monero services, map whatever port your application listens on locally to whatever port you want exposed on the onion.
5. Start Tor and read the onion address. Run systemctl restart tor@default, wait for nyx to show a successful bootstrap to 100%, then cat /var/lib/tor/monero-node/hostname. The 56-character ed25519 address ending in .onion is your service identity. Back up the contents of the directory — especially hs_ed25519_secret_key — to an encrypted offline medium, because losing it means losing the address forever.
6. Bind the application to localhost only. Edit your service's configuration to listen on 127.0.0.1 rather than 0.0.0.0. For a Monero daemon, set rpc-bind-ip=127.0.0.1 in monerod.conf and pass the --restricted-rpc flag to refuse wallet operations on the public endpoint. Restart the application and confirm with ss -tlnp that nothing is bound to the public interface.
7. Verify externally. From a separate machine running Tor Browser, navigate to the .onion address. The application should respond exactly as it would over clearnet, with no leakage of the underlying IP in headers or error pages. Use curl --socks5-hostname 127.0.0.1:9050 http://yourservice.onion/ from any Tor-enabled host for scripted checks.
8. Optional: generate a vanity onion. Tools like mkp224o brute-force ed25519 keypairs for a desired prefix. A 6-character prefix takes minutes on a modern CPU; 8 characters takes hours; 10 characters takes days on a GPU. Avoid prefixes that match your legal name, project alias, or any other linkable string — defeats the entire purpose of the exercise.

An onion service is only as anonymous as its weakest application-layer leak. A Monero node that prints its hostname in error messages, or a webserver that ships a Server header with the underlying IP-based reverse DNS, will compromise the deployment regardless of how careful the Tor config was.

Hardening, monitoring, and operational discipline

The Tor daemon is one component. The rest of the system has to match its threat model or it becomes the weakest link in the chain. Disable swap entirely with swapoff -a and remove the swap entry from /etc/fstab so that ed25519 secret material is never paged to disk. Enable kernel.kptr_restrict=2, kernel.dmesg_restrict=1, and the rest of the kernel-hardening sysctls bundled in linux-hardening or pulled from the Whonix sysctl reference. AppArmor profiles for Tor and your application add another layer at modest configuration cost.

Configure nftables or ufw to drop all inbound traffic except SSH — and ideally only from your management IPs, if you have stable ones. Otherwise rely on strong key authentication and rate-limiting with fail2ban. Outbound, allow only what Tor needs: TCP 443 and 9001/9030 for relay traffic if the box is also a Tor relay, and force DNS through the Tor SOCKS port for any application that needs name resolution. Never let an application speak directly to the clearnet DNS resolver of the VPS provider — that path quietly leaks the existence of your application to the provider's logs.

Monitor with nyx locally and ship Prometheus metrics over the onion service itself if you need remote graphing. Avoid pushing logs or metrics to any third-party SaaS — that is a textbook deanonymization vector. Log rotation should be aggressive: logrotate daily with maxage 7, and journalctl --vacuum-time=7d in a weekly cron job. The less historical data sits on disk, the less there is for a hostile actor to seize and the less you have to explain after the fact.

Backups deserve their own discipline. The hs_ed25519_secret_key file is the one piece of state you cannot regenerate. Encrypt it with age or GPG using a strong passphrase, store on at least two offline media (USB sticks plus paper-printed base64 in a sealed envelope), and keep one copy geographically separate from your primary location. For the rest of the system, rebuild from configuration management (Ansible, NixOS, or shell scripts in a private repo) rather than backing up the entire disk image — the system should be ephemeral and only the secret should be stable.

FAQ

Can I run a Tor hidden service from home instead of a VPS?

Technically yes — Tor does not care where the server lives. Practically, residential connections introduce uptime risk (power outages, ISP renegotiation, dynamic IP rotation breaking long-lived guard relays), and any leak that exposes the public IP collapses anonymity to your billing identity at the ISP. A no-KYC VPS isolates the service from your meatspace footprint at modest cost — €5 to €15 a month — and most experienced operators consider that trade-off obvious.

Does paying with Monero really hide me from the VPS provider?

Payment-side, yes. Monero's RingCT, ring signatures, stealth addresses, and Dandelion++ transaction relay break the link between your wallet and the deposit address you pay. The VPS provider sees an incoming payment with no plaintext sender. What payment hygiene cannot fix is the rest of the signup process: an email used elsewhere, a username from a public forum, or an SSH key fingerprint shared with a non-anonymous account. Treat anonymity as a chain — Monero is one link, not the whole thing.

How long does a v3 onion address last?

Indefinitely, as long as you keep the hs_ed25519_secret_key file safe. The address is derived deterministically from that key. You can copy the directory to a new VPS, restart Tor, and the same .onion address resolves to the new server within minutes. This is the foundation of operational resilience: when one VPS becomes untrustworthy or unavailable, you migrate the key, not the address, and clients reconnect without any change on their side.

Do I need to run my own Monero node, or can I use a public one over Tor?

Both are legitimate. Public onion nodes (listed on monero.fail) are convenient and require no infrastructure, but they see your transaction broadcasts and queries. Running your own node behind your own hidden service costs roughly 200 GB of disk plus the VPS bill, but it removes the trust requirement entirely. For high-value flows — including converting funds via MoneroSwapper without leaving correlatable metadata at any third-party endpoint — the self-hosted node is the materially stronger posture.

What happens if my hidden-service private key is seized?

Whoever holds the hs_ed25519_secret_key file can serve traffic on your .onion address from any infrastructure they control, and the substitution is indistinguishable to clients. Backups must therefore be encrypted at rest with a passphrase only you know — full-disk encryption on the VPS alone is not enough, because the running system holds the key in memory. If a seizure is imminent, rotate to a new onion address immediately and announce the change through a previously signed out-of-band channel that clients already trust.

Conclusion

Setting up a Tor hidden service on an anonymous VPS is not a single product purchase; it is a sequence of decisions about jurisdiction, payment hygiene, system hardening, and key management. Each step closes one identification surface and leaves the rest visible. The point of doing all of them together is that no single failure — a provider audit, a misconfigured banner, a leaked log line — collapses the entire stack. For Monero operators and anyone else who needs durable, no-KYC infrastructure, the recipe above is the working baseline. When the service you reach on the other side is something like the MoneroSwapper onion endpoint, the same standards apply on the client side as well: own the path end-to-end, or accept that you do not actually have privacy.