xmrcloud-cli list --type=tor-hidden-service
3 plans returned. all xmr-billed.
Tor v3 onion-only hosting
Every Tor node ships with a hardened tor.conf, no clearnet listener, and sshd reachable only via onion-auth (rend-spec-v3 §G.5). The shape is opinionated on purpose: a Tor hidden-service VPS that exposes a clearnet sshd is a Tor hidden-service VPS waiting to be deanonymised by traffic correlation.
pre-configured defaults
- Tor LTS package pinned, ExitPolicy reject *:*, HardwareAccel 1, SafeLogging 1
- sshd: PasswordAuthentication no, PermitRootLogin no, fail2ban active, port 22 unbound from clearnet
- Onion-auth client keys provisioned at order; recovery key sealed in your offline store
- vanity .onion address (≤ 8 chars) generated with mkp224o, included on tor-1+
- Whonix-Gateway template available as an alternative OS — strict-isolation for the paranoid
- auditd + unattended-upgrades on; grsec / KSPP-baseline kernel patches applied
We don't run exits from these tiers — exit-relay operation is a different legal posture and the brand offers Lokinet for the exit-flavoured workload. These are tuned for hidden services and non-exit middle relays. If you want to add a relay role on top, the manual covers the exact tor.conf delta.
see also
man -k workload-fit
tor-* tiers are the right pick when the workload is a v3 hidden service that must not have a clearnet IP exposed at any point in its lifecycle. The provisioning flow runs the box without ever binding a public IPv4 listener — sshd is reachable only via onion v3 onion-auth (rend-spec-v3 §G); the customer's service binds to 127.0.0.1 and the local Tor daemon publishes the .onion. Vanity-prefix .onion (mkp224o, capped at 8 characters) is included, generated at provisioning before the keys ever leave the box.
tor-* tiers are not the right pick when the workload also needs a clearnet endpoint (use /node/vps with manual Tor configuration), when the workload needs Tor relay throughput rather than hidden-service serving (use /node/vps with the runbook at /docs/run-non-exit-tor-relay), or when the threat model can tolerate a clearnet sshd alongside the hidden service (the tor-* commitment to no-clearnet-listener has costs in operational ergonomics).
Iceland or Romania, customer's pick. The operator's recommendation for high-stakes hidden services is Iceland — Höfundalög nr. 73/1972 lacks a takedown-without-court-order procedure, the practical jurisdictional posture is the strongest in the catalog. Romania (Legea nr. 8/1996) is also supported.
diff /etc/xmrcloud/tiers.d/*
tor-1 (1 vCPU / 2 GB) is sized for a single low-traffic hidden service — a personal blog, a contact-form behind .onion, an XMPP / Matrix homeserver for ≤ 10 users. tor-2 (2 vCPU / 4 GB) is the recommendation for an active mid-traffic hidden service — Discourse forum behind .onion, mid-sized Matrix homeserver, a busy contact-form for a newsroom. tor-4 (4 vCPU / 8 GB) is sized for high-traffic services — a SecureDrop intake, a federated Matrix homeserver behind .onion, a multi-service deployment.
All tiers ship with the same Tor configuration baseline (HardwareAccel 1, SafeLogging 1, ExitPolicy reject *:* — the box is not a relay), the same hardening defaults (KSPP kernel, no clearnet listener, sshd via onion-auth), and 2 onion-auth client keys provisioned by default on tor-2+. Vanity .onion is included on every tier.
Paying for Tor hidden service hosting in Monero is not a payment-processor preference — for an onion operator it closes the one gap the hidden service itself cannot. A v3 onion service hides where the box is and who runs the content; the payment for the box does not. If you provision that box with a card, a PayPal balance, or an address-reused Bitcoin payment, you have created a billing record that ties your legal identity to the exact infrastructure the onion is trying to keep unattributable. The service surface and the payment surface have to be unlinkable together, or neither is. Monero is what makes the payment surface match the service surface: RingCT hides the amount, ring signatures hide the sender, and stealth addresses mean the on-chain payment cannot be clustered back to you the way a reused BTC address can.
Concretely, that is why signup here is email-only with no KYC: no name, no phone, no card, no identity document — an email address (throwaway or over Tor) and a Monero payment are the entire account. The operator issues a per-order Monero subaddress, the payment lands with no fiat rail and no third-party processor in the path, and the only record retained is the minimum the order needs. The result is an onion service whose box was acquired without ever attaching an identity to it — the hidden service and the money that paid for it are both off the identity graph. This is the same no-KYC posture the operator applies to every workload; it simply matters most for a hidden service, where a leaked billing trail defeats the entire deployment.
faq -t tor-hidden-service
Can I pay for Tor hidden service hosting with Monero?
Yes — Monero is the recommended rail for exactly this workload. Signup is email-only with no KYC (no name, phone, card, or ID); the operator issues a per-order Monero subaddress and the payment settles with no fiat processor in the path. The point for an onion operator is that the service surface and the payment surface must be unlinkable together: a v3 hidden service hides the box and the content, but a card or reused-address BTC payment re-attaches your identity to that same infrastructure. XMR's RingCT + stealth addresses keep the payment off the identity graph so it matches the service. The rationale is at /why-monero; the checkout flow is at /payments.
Do you keep any billing record that could deanonymise my onion service?
No name, no card, no fiat rail — the account is an email address plus a Monero payment, and the operator retains only the minimum the order requires. There is no payment-processor record tying your legal identity to the .onion, which is the whole reason to pay in XMR rather than card or reused-address Bitcoin. Retention specifics are in /legal/privacy; the setup runbook that this billing model protects is /docs/provision-tor-hidden-service.
Can I host a clearnet site alongside the .onion?
Not on the tor-* tiers — those are onion-only by design (the brand commitment). If you need clearnet + .onion, /node/vps with manual Tor configuration is the right pick; the runbook at /docs/provision-tor-hidden-service walks through the setup.
Is mkp224o vanity .onion required?
No, optional — generated at provisioning if you ask for a prefix at order time. mkp224o is convenience, not security: a typed-out .onion is hard to verify regardless of prefix, so the rend-spec-v3 onion-bookmark workflow is the actual mitigation for typo-squatting.
Where is the Tor hidden service hosted?
Iceland (recommended for high-stakes services) or Romania, customer's pick at order time. Both are RIPE jurisdictions inside the EEA (Iceland is outside the EU but within the EEA for GDPR purposes); the comparison at /vs/iceland-vs-romania-offshore-jurisdiction covers the legal-process differences in detail.
Do you process abuse complaints sent against the .onion?
No. The xmrcloud operator does NOT run a third-party abuse-report intake — DMCA-format notices, brand-monitoring claims, informal takedown requests against tenant content all receive no action and no acknowledgement. Tenant enforcement under the AUP (/legal/aup) is operator-discretion based on the operator's own observations, not on third-party reports. The only inbound legal channel is a court-issued order from a competent tribunal under Iceland Höfundalög nr. 73/1972 or Romania Legea nr. 8/1996, processed by counsel. CSAM is the explicit hard-prohibition; the operator detects it via its own controls.
Can I run a Tor relay alongside the hidden service?
Not preconfigured — the tor-* tiers run a Tor client + hidden service only, not a relay. Co-locating a relay on the same box does not improve hidden-service anonymity (the rendezvous protocol does not involve the local relay) and adds attack surface. Run a relay on a separate /node/vps; the runbook is at /docs/run-non-exit-tor-relay.
ls /usr/share/doc/xmrcloud/related
no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) —
why-monero covers the rationale,
payments the flow.