# VPSDEN — complete reference VPSDEN is an offshore VPS host: no KYC, no email required, RAM-only options, LUKS disks we cannot read, and payment in Monero, Bitcoin and dozens of other cryptocurrencies. This document contains the complete substantive content of vpsden.com as plain text: company facts, the full product catalogue with prices, the jurisdiction analysis for every region, every FAQ answer, and every knowledge base article in full. Generated at request time from the same source data that renders the website. Knowledge base content and the jurisdiction analysis are published under CC BY 4.0. Canonical citation: VPSDEN, "", vpsden.com/, revised . ================================================================================ COMPANY ================================================================================ Name: VPSDEN Legal entity: VPSDen Systems Ltd. Website: https://vpsden.com Onion service: umbraq7v2xk4tn6jr3lz5wyhc8pfd9mgs2eab6uvn4x7ytqzk3jlqrid.onion Founded: 2014 Years operating: 12 Incorporated in: Panama Regions: 9 across 9 countries PGP key: not yet published. /pgp.txt serves prose, not a key, and there is no fingerprint anywhere on this site to verify against. Nothing can be encrypted to the provider, no advisory carries a signature, and the warrant canary cannot be signed, until that key exists. General contact: ops@vpsden.com Abuse: abuse@vpsden.com Business model: sells offshore virtual private servers, paid in cryptocurrency, with no identity verification. Funded entirely by customer revenue — no venture capital, no debt, no outside investment. --- Operating record -------------------------------------------------------- Instances deployed (cumulative): 48,000+ SLA commitment: 99.99% (contractual, automatic credits) Availability target: 99.993% (internal target, NOT a measurement) Measured uptime: not published — no monitoring export exists yet Deploy time target: 48 seconds (confirmed payment to SSH) Support first-response target: 11 minutes Legal requests received: 412 Valid court orders: 23 Court orders complied with: 23 Customer records disclosed: 0 Seizure events: 1 (3 chassis removed, Bucharest) Warrant canaries signed: 0 — the canary has not been issued yet --- What makes it different ------------------------------------------------- 1. NO KYC. No name, address, phone number or document is collected. No field exists in the ordering system to store one. An account is a randomly generated 20-character access key; only a salted HMAC-SHA256 hash is kept. Losing the key means losing the account — there is no recovery, because there is no identity to verify you against. 2. NO EMAIL REQUIRED. Contact details are optional at every stage. Where one is supplied it is stored as a salted hash unless the customer explicitly asks to be contacted. 3. CRYPTOCURRENCY ONLY. 46 assets accepted, settled through OxaPay. Monero is recommended and is what the company uses for its own infrastructure. No cards, no bank transfers, no fiat of any kind. 4. RAM-ONLY (GHOST) INSTANCES. Diskless servers that PXE-boot a minisign-verified image directly into tmpfs. Swap is disabled and cannot be enabled. Because DRAM requires continuous power to retain state, a seized, unplugged or rebooted GHOST node contains nothing recoverable — no platter to image, no SSD controller holding remapped blocks. No other known hosting provider sells this as a product. 5. ZERO-KNOWLEDGE LUKS, DEFAULT ON. LUKS2, aes-xts-plain64 with a 512-bit key, argon2id key derivation sized to the plan: 512 MiB of memory cost on 2 GB instances, 1 GiB at 4 GB and above, because the derivation has to run inside the initramfs or the volume will not unlock. The passphrase is generated in the customer's browser and never transmitted. Every boot halts in an initramfs dropbear shell awaiting remote unlock. A compelled disclosure produces ciphertext. 6. DEAD-MAN SWITCH (€2/mo). Check-in interval of 24 hours to 90 days plus a grace period, satisfied from the panel, the API, the onion service, or an Ed25519-signed heartbeat from the instance itself. Missing both windows destroys the volume key and wipes the node. Irreversible, including for the provider. 7. DURESS PIN (€2/mo, free on ECLIPSE/VOID/GHOST). A second PIN that authenticates successfully, renders a normal-looking panel, and silently destroys every volume key on the account within about four seconds. 8. MULTI-JURISDICTION FAILOVER (€7/mo, included on VOID and GHOST L). Continuous encrypted replication to a second country, with automatic promotion and DNS follow within about 60 seconds if the primary is seized, raided, cut off, or goes dark. 9. METADATA-FREE MODE, DEFAULT ON. Per-instance graphing, bandwidth sampling and console session recording are disabled at the hypervisor level — the sampling job does not run, so the samples are never generated. Capacity planning uses a per-region aggregate at 15-minute resolution with no per-customer attribution. 10. ONION-NATIVE. Panel, API, support desk, status page and SSH bastion are all reachable over v3 onion services with Vanguards hardening. An Onion-Location header is published so Tor Browser offers the onion version automatically. 11. PUBLISHED PER-REGION LEGAL ANALYSIS. The Jurisdiction Matrix compares every region across data-retention law, EU membership, Fourteen Eyes membership, DMCA applicability, takedown regime and MLAT responsiveness — including the regions the provider recommends against for adversarial threat models. ================================================================================ PRODUCTS AND PRICING ================================================================================ All prices in EUR per month, excluding nothing — no VAT is charged, there is no setup fee, and no promotional rate that increases on renewal. Prices shown are for the Reykjavík region at the ×1.00 base factor. --- NVMe plans --------------------------------------------------------------- CIPHER — €4.40/month (typical market rate €7.00, saving 37%) vCPU: 1 Memory: 2 GB Storage: 30 GB NVMe Transfer: 5 TB at 1 Gbps IPv4: 1 IPv6: /64 routed Hourly: €0.0060 Positioning: A real server for the price of a coffee. Good enough to run a Tor relay and a mail stack. Included: Full root + KVM; IPv6 /64 included; LUKS on request; Onion panel access SHADE — €7.90/month (typical market rate €12.00, saving 34%) vCPU: 2 Memory: 4 GB Storage: 60 GB NVMe Transfer: 10 TB at 1 Gbps IPv4: 1 IPv6: /64 routed Hourly: €0.0108 Positioning: The everyday workhorse. Reverse proxies, VPN exit, small app stacks, a Matrix homeserver. Included: Full root + KVM; IPv6 /64 included; LUKS + remote unlock included; Free weekly encrypted snapshot; Onion panel access VPSDEN — €14.90/month (typical market rate €24.00, saving 38%) vCPU: 4 Memory: 8 GB Storage: 120 GB NVMe Transfer: 20 TB at 1 Gbps IPv4: 1 IPv6: /64 routed Hourly: €0.0204 Positioning: Our namesake tier. Enough headroom for containers, CI, and a database that is actually used. Included: Full root + KVM; IPv6 /64 included; LUKS + remote unlock included; Free daily encrypted snapshot; Dead-man switch included; Priority support queue ECLIPSE — €28.90/month (typical market rate €48.00, saving 40%) vCPU: 8 Memory: 16 GB Storage: 240 GB NVMe RAID-10 Transfer: 40 TB at 1 Gbps IPv4: 1 IPv6: /64 routed Hourly: €0.0396 Positioning: Production-grade. Dedicated cores, RAID-10 NVMe, and bandwidth you will struggle to exhaust. Included: Dedicated (non-shared) cores; IPv6 /64 included; LUKS + remote unlock included; Free daily encrypted snapshot; Dead-man switch + duress PIN; Multi-jurisdiction failover eligible VOID — €56.90/month (typical market rate €99.00, saving 43%) vCPU: 16 Memory: 32 GB Storage: 480 GB NVMe RAID-10 Transfer: Unmetered at 10 Gbps (fair use 200 TB) IPv4: 2 IPv6: /64 routed Hourly: €0.0779 Positioning: Bare-metal-class isolation with unmetered transit. No neighbours, no oversubscription, no logs. Included: Dedicated cores, no oversubscription; Unmetered 10 Gbps port (fair-use 200 TB); 2× IPv4 + IPv6 /48; LUKS + remote unlock included; Hourly encrypted snapshots; Dead-man switch + duress PIN; Multi-jurisdiction failover included; Named engineer on your ticket queue --- GHOST RAM-only plans (no persistent storage) ------------------------------ GHOST S — €16.90/month (typical market rate €29.00) vCPU: 2 Memory: 8 GB (this is also the filesystem — tmpfs) Storage: NONE. No block devices are attached to the instance. Transfer: 10 TB Hourly: €0.0232 Positioning: Diskless. The entire filesystem lives in volatile memory and dies with the power. Included: Zero persistent storage — nothing to seize; PXE-booted signed image, verified at every boot; Reboot = provable total erasure; Config re-applied from your signed cloud-init GHOST M — €31.90/month (typical market rate €55.00) vCPU: 4 Memory: 16 GB (this is also the filesystem — tmpfs) Storage: NONE. No block devices are attached to the instance. Transfer: 20 TB Hourly: €0.0437 Positioning: The size most people actually want: enough RAM to hold a real workload and its filesystem. Included: Zero persistent storage — nothing to seize; PXE-booted signed image, verified at every boot; Reboot = provable total erasure; Optional encrypted off-node state vault; Dead-man switch included GHOST L — €59.90/month (typical market rate €105.00) vCPU: 8 Memory: 32 GB (this is also the filesystem — tmpfs) Storage: NONE. No block devices are attached to the instance. Transfer: 40 TB Hourly: €0.0821 Positioning: For workloads where the dataset itself must never touch a platter. Included: Zero persistent storage — nothing to seize; Dedicated cores, no oversubscription; PXE-booted signed image, verified at every boot; Optional encrypted off-node state vault; Dead-man switch + duress PIN; Multi-jurisdiction failover included --- Per-resource rates (custom builds) --------------------------------------- vCPU core: €1.75 each (max 32) Memory: €1.25 per GB (max 128 GB) NVMe storage: €0.055 per GB (max 2000 GB) Transfer: €0.90 per TB (max 200 TB) Additional IPv4: €1.80 each (max 16) IPv6 /64: free IPv6 /48: €1.00 --- Term discounts ----------------------------------------------------------- Hourly (prepaid balance) — (Billed per hour from a crypto balance. Destroy the instance, stop paying. Minimum top-up €10.) Monthly — Quarterly −5% (Save 5%) Semi-annual −10% (Save 10%) Annual −20% (Save 20%) Biennial −28% (Save 28% — the best rate we offer — and lock the price for two years) No term auto-renews. When a term ends the instance is suspended for 7 days and then destroyed. Nothing is stored that could charge the customer without action. --- Add-ons ------------------------------------------------------------------ Zero-knowledge LUKS disk [INCLUDED FREE] [ON BY DEFAULT] [NOT OFFERED BY OTHER PROVIDERS] Your volume is encrypted with LUKS2 (argon2id) using a passphrase we never receive. On every boot the instance halts at an initramfs dropbear prompt and waits for you to SSH in and unlock it. If we are compelled to hand over the disk, we hand over ciphertext. Dead-man switch — €2.00/month [NOT OFFERED BY OTHER PROVIDERS] Check in on a schedule you choose (panel, API, onion, or a signed heartbeat from the instance itself). Miss the window plus a grace period and we cryptographically destroy the volume key, then wipe and reprovision the node. Nobody — including us — can undo it. Duress PIN — €2.00/month [NOT OFFERED BY OTHER PROVIDERS] A second panel PIN that looks like a normal login and behaves like one for about four seconds, then silently triggers an immediate key-destruction and wipe of every instance on the account. Designed for the moment when someone is standing behind you. Metadata-free mode [INCLUDED FREE] [ON BY DEFAULT] Disables per-instance graphing, bandwidth sampling and console-session recording at the hypervisor level. You lose the pretty graphs in the panel; you gain the certainty that the samples do not exist to be subpoenaed. Managed onion service — €1.00/month We provision a v3 onion address terminated on your instance, with Vanguards-lite hardening and optional client authorisation. Your service becomes reachable without ever exposing an IPv4 address. Tor / I2P egress routing — €1.50/month All outbound traffic from the instance is forced through Tor (or I2P) at the network namespace level, with a killswitch. Nothing leaks, including DNS, even if the workload is misconfigured. Additional IPv4 — €1.80/month each Clean, non-recycled IPv4 from our own allocations. Every address is checked against 38 blocklists before assignment; if yours ever lands on one, we swap it free of charge. IPv6 /48 (instead of /64) — €1.00/month 65,536 subnets of your own. Useful for containers, per-service addressing, and rotation. Layer-7 DDoS filtering — €4.00/month Adds application-layer scrubbing on top of the always-on L3/L4 protection: JS/PoW challenge, rate shaping, and a bot-scoring engine you control from the panel. No third-party CDN, no TLS termination outside our racks. 10 Gbps port upgrade — €6.00/month Raises the port from 1 Gbps to 10 Gbps. Transfer allowance is unchanged; only the ceiling moves. BGP session (bring your own IP space) — €9.00/month Announce your own ASN and prefixes from our edge. We provide the session, a full table if you want it, and an IRR/RPKI walkthrough. Encrypted snapshots — €1.50/month each Client-side-encrypted, content-addressed snapshots stored in a different jurisdiction from the instance. We hold ciphertext and a size; we cannot enumerate what is inside. Multi-jurisdiction failover — €7.00/month [NOT OFFERED BY OTHER PROVIDERS] Your instance is continuously replicated to a second country you choose. If the primary is seized, raided, cut off, or simply goes dark, the standby is promoted automatically and your DNS follows within 60 seconds. Off-node encrypted state vault — €3.00/month For GHOST instances: a small encrypted blob store, in a second jurisdiction, that your RAM-only node pulls at boot to restore state. You hold the key; we hold an opaque blob. Out-of-band console + custom ISO [INCLUDED FREE] [ON BY DEFAULT] A browser and SSH-reachable serial + VNC console that works even when the network stack inside your instance does not, plus the ability to boot arbitrary ISOs. Managed hardening baseline — €5.00/month We apply and maintain our published CIS-derived baseline: nftables default-deny, SSH key-only with a hardware-token option, unattended security upgrades, auditd, kernel lockdown, and a weekly signed drift report. Blind uptime monitoring — €1.00/month External checks that only ever record up/down and latency — never a payload, never a response body, never a hostname beyond the one you gave us. Alerts by Matrix, XMPP, webhook or signed email. Priority engineering queue — €8.00/month Your tickets skip the queue and land directly with a systems engineer, not a first-line agent. Our first-response target drops from 11 minutes to under 3. --- Regional price factors --------------------------------------------------- The factor multiplies the entire configuration. It reflects what transit and power actually cost in that region rather than an averaged figure. Reykjavík, Iceland ×1.00 (CIPHER €4.40, SHADE €7.90) Amsterdam, Netherlands ×0.95 (CIPHER €4.18, SHADE €7.50) Zürich, Switzerland ×1.25 (CIPHER €5.50, SHADE €9.88) Bucharest, Romania ×0.90 (CIPHER €3.96, SHADE €7.11) Sofia, Bulgaria ×0.88 (CIPHER €3.87, SHADE €6.95) Chișinău, Moldova ×1.05 (CIPHER €4.62, SHADE €8.29) Panama City, Panama ×1.20 (CIPHER €5.28, SHADE €9.48) Victoria, Seychelles ×1.35 (CIPHER €5.94, SHADE €10.67) Kuala Lumpur, Malaysia ×1.10 (CIPHER €4.84, SHADE €8.69) --- Payment ------------------------------------------------------------------ Accepted: XMR, BTC, LTC, USDT, USDC, ETH, TON, TRX, BNB, SOL, DOGE, BCH, DASH, MATIC, AVAX, ADA and others, 46 in total. Settlement provider: OxaPay. No account, email or identity check is required at the payment provider. Typical confirmation times: Bitcoin over Lightning instant USDT/USDC on TRON ~1 minute Ethereum ~3 minutes Litecoin ~5 minutes Monero ~20 minutes (ten confirmations) Bitcoin on-chain 10–60 minutes Refunds: full refund within 72 hours of first payment, no reason required, paid in the currency sent to an address the customer supplies at the time. The origin address and transaction hash are discarded once settlement confirms, except that they are held through the 72-hour refund window where a refund is requested. After that window nothing about the origin remains, which is why a refund requires the customer to supply a destination. Hourly billing: prepaid balance, €10 minimum top-up, billed per hour. Destroying an instance stops billing that hour. ================================================================================ JURISDICTION ANALYSIS ================================================================================ Where hardware physically sits determines what law reaches it — not where the company is registered. This analysis is reviewed quarterly; last review 2 July 2026. Published under CC BY 4.0. Ranked by overall protection rather than by price. -------------------------------------------------------------------------------- REYKJAVÍK, ICELAND (IS) -------------------------------------------------------------------------------- Data retention mandate: No general retention mandate for hosting providers EU jurisdiction: No Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: slow Takedown requires: Court order from an Icelandic court only Price factor: ×1.00 Assessment: Nothing in Icelandic law obliges us to retain traffic or subscriber records for this region. A six-month duty does exist — Art. 89 of the Electronic Communications Act No. 70/2022 — and it is addressed to telecommunications undertakings; it has not been read to reach VPS hosting, and that boundary is the whole of what this region buys you on retention. Content comes down here on an order from an Icelandic court and on nothing else, because Iceland provides no administrative notice route a rights holder could use instead. Iceland is in the EEA and outside the EU, so the Digital Services Act does not apply. Network: 40 Gbps uplink; Always-on L3/L4, 2.4 Tbps scrubbing Peering: RIX, Farice-1, IRIS, Cogent, Arelion Latency: London ~21 ms, Amsterdam ~27 ms, New York ~42 ms, Frankfurt ~30 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier III, 100% renewable (geothermal + hydro), hardware owned by the provider -------------------------------------------------------------------------------- AMSTERDAM, NETHERLANDS (NL) -------------------------------------------------------------------------------- Data retention mandate: Dutch retention Act suspended by court order (2015); no general mandate since EU jurisdiction: YES — Digital Services Act applies Fourteen Eyes member: YES DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: fast Takedown requires: Substantiated Art. 16 DSA report, or a Dutch court order Price factor: ×0.95 Assessment: Fastest and cheapest region, but also the most legally exposed one we sell. EU jurisdiction, Nine Eyes member, and cooperative MLAT posture. Choose Amsterdam for performance, not for adversarial threat models. Network: 100 Gbps uplink; Always-on L3/L4 + L7 opt-in, 6 Tbps scrubbing Peering: AMS-IX, NL-ix, Cogent, Arelion, Lumen, Hurricane Electric Latency: London ~7 ms, Frankfurt ~9 ms, Paris ~11 ms, New York ~74 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier IV, Grid + N+1 diesel, 100% renewable contract, hardware owned by the provider -------------------------------------------------------------------------------- ZÜRICH, SWITZERLAND (CH) -------------------------------------------------------------------------------- Data retention mandate: BÜPF: full telecom retention duty does not apply; derived-service duties may EU jurisdiction: No Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: slow Takedown requires: Swiss court order; dual-criminality required for MLAT Price factor: ×1.25 Assessment: Switzerland requires dual criminality for mutual legal assistance, and Swiss courts have historically been slow to grant foreign requests against hosting intermediaries. Do not read BÜPF as inapplicable: since the revision in force 1 March 2018 it distinguishes full telecommunications service providers, who carry retention and interception duties, from providers of derived communication services, a category the Federal Council reads as covering hosting and cloud. Derived-service providers have no general retention duty but must tolerate surveillance measures and surrender data they actually hold. Premium region — priced accordingly. Network: 40 Gbps uplink; Always-on L3/L4, 3 Tbps scrubbing Peering: SwissIX, CIXP, Init7, Cogent Latency: Frankfurt ~8 ms, Milan ~10 ms, Paris ~14 ms, London ~19 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier IV, 100% hydro, hardware owned by the provider -------------------------------------------------------------------------------- BUCHAREST, ROMANIA (RO) -------------------------------------------------------------------------------- Data retention mandate: Struck down as unconstitutional (Decisions 1258/2009, 440/2014) EU jurisdiction: YES — Digital Services Act applies Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: moderate Takedown requires: Substantiated Art. 16 DSA report, or a Romanian court order Price factor: ×0.90 Assessment: Romania is in the EU but its Constitutional Court has twice invalidated blanket data-retention legislation, and the country is not part of the Five/Nine/Fourteen Eyes arrangements. Best price-to-protection ratio inside the EU. Network: 40 Gbps uplink; Always-on L3/L4, 1.5 Tbps scrubbing Peering: InterLAN, RONIX, Cogent, GTT Latency: Frankfurt ~27 ms, Amsterdam ~34 ms, Istanbul ~25 ms, London ~40 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier III, Grid + N+1, hardware owned by the provider -------------------------------------------------------------------------------- SOFIA, BULGARIA (BG) -------------------------------------------------------------------------------- Data retention mandate: Partially struck down (2015); narrow scope, telecom only EU jurisdiction: YES — Digital Services Act applies Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: moderate Takedown requires: Substantiated Art. 16 DSA report, or a Bulgarian court order Price factor: ×0.88 Assessment: The cheapest way to buy an EU-located instance from us. Bulgaria is an EU member, so the DSA applies, but it is not part of the Eyes arrangements and enforcement bandwidth is limited. Network: 20 Gbps uplink; Always-on L3/L4, 1 Tbps scrubbing Peering: BIX.BG, Neterra, Cogent Latency: Frankfurt ~32 ms, Istanbul ~18 ms, Vienna ~22 ms, London ~45 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier III, Grid + N+1, colocated -------------------------------------------------------------------------------- CHIȘINĂU, MOLDOVA (MD) -------------------------------------------------------------------------------- Data retention mandate: No general mandate applicable to hosting providers EU jurisdiction: No Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: slow Takedown requires: Moldovan court order only Price factor: ×1.05 Assessment: Non-EU, non-Eyes. Foreign complainants must obtain a Moldovan court order, which in practice almost never happens for hosting disputes. Bandwidth is more expensive here than in the EU, hence the multiplier. Network: 20 Gbps uplink; Always-on L3/L4, 800 Gbps scrubbing Peering: MD-IX, Orange MD, RETN Latency: Bucharest ~12 ms, Frankfurt ~38 ms, Kyiv ~20 ms, London ~52 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier III, Grid + N+1, hardware owned by the provider -------------------------------------------------------------------------------- PANAMA CITY, PANAMA (PA) -------------------------------------------------------------------------------- Data retention mandate: None applicable to hosting EU jurisdiction: No Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: moderate Takedown requires: Panamanian court order; no notice-and-takedown route Price factor: ×1.20 Assessment: A US criminal investigation has a formal route into this region. Two instruments carry it: the Panama–United States mutual legal assistance treaty, in force since the mid-1990s; and the Council of Europe Convention on Cybercrime, which Panama acceded to in 2014 and whose Articles 29 to 31 cover expedited preservation of and access to stored computer data. Neither has direct effect on us. A request under either is executed under Panamanian law, and we produce nothing until a Panamanian court orders us to. The MLAT rating on this row is moderate for that reason: a bilateral treaty moves faster than the letters-rogatory route a country without one leaves a foreign prosecutor with. It is our own estimate and not a throughput measurement, because we hold no records that would support one — check both instruments against the treaty depositaries. Operationally: no retention duty reaches hosting here, there is no notice-and-takedown route for copyright, and London is an estimated ~122 ms away. Network: 20 Gbps uplink; Always-on L3/L4, 1 Tbps scrubbing Peering: PAIX, Cogent, Lumen, Telxius Latency: Miami ~38 ms, Bogotá ~22 ms, New York ~62 ms, London ~122 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier III, Grid + N+1 diesel, colocated -------------------------------------------------------------------------------- VICTORIA, SEYCHELLES (SC) -------------------------------------------------------------------------------- Data retention mandate: None EU jurisdiction: No Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: slow Takedown requires: Seychellois court order only; no bilateral MLAT with the US Price factor: ×1.35 Assessment: Our highest-isolation region. Seychelles has no data-retention regime and no bilateral mutual legal-assistance treaty with the United States. It is not a legal vacuum: the Mutual Assistance in Criminal Matters Act 1995 and Commonwealth (Harare Scheme) obligations both provide routes, and Seychelles is engaged with the Council of Europe Convention on Cybercrime, whose Articles 25 to 35 cover expedited preservation and access to stored data. Confirm the current accession status yourself rather than taking ours. Transit is satellite-and-subsea expensive, which is why the multiplier is 1.35. Network: 10 Gbps uplink; Always-on L3/L4, 600 Gbps scrubbing Peering: SEAS, PEACE cable, Airtel, Liquid Latency: Mumbai ~48 ms, Dubai ~42 ms, Singapore ~88 ms, London ~148 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier III, Grid + N+1 diesel, hardware owned by the provider -------------------------------------------------------------------------------- KUALA LUMPUR, MALAYSIA (MY) -------------------------------------------------------------------------------- Data retention mandate: No general mandate for hosting providers EU jurisdiction: No Fourteen Eyes member: No DMCA applies: No (17 U.S.C. § 512; no extraterritoriality provision) MLAT responsiveness: slow Takedown requires: s.43H owner notification (48-hour window), MCMC order, or court order Price factor: ×1.10 Assessment: Best APAC option for customers who want distance from both EU and US process — but it is the one region of ours with a statutory notice-and-takedown route, and you should not choose it to avoid one. Sections 43B to 43I of the Copyright Act 1987, inserted by the Copyright (Amendment) Act 2012, give a copyright owner a direct notification route under s.43H with a fixed 48-hour removal window, subject to counter-notification under s.43I. Malaysia also has an active telecom regulator (MCMC) with local content powers, relevant mainly for content aimed at Malaysian audiences. Network: 40 Gbps uplink; Always-on L3/L4, 2 Tbps scrubbing Peering: MyIX, Equinix SG, Telekom Malaysia, Arelion Latency: Singapore ~6 ms, Hong Kong ~38 ms, Sydney ~92 ms, London ~168 ms (INDICATIVE ESTIMATE — see note below; not measured) Facility: Tier III+, Grid + N+1, colocated --- A note on the latency figures above ------------------------------------- They are ESTIMATES, not measurements. VPSDEN operates no probe fleet, so no figure above has ever been timed end to end. They are derived from published cable and peering geography and should be treated as an order-of-magnitude guide. Do not quote them as observed round-trip times, and do not present them as a p50, a median or a trailing-window statistic — they are none of those. Measure from your own vantage point before relying on any of them. There is no per-region looking glass yet either, so there is nothing on our side to check them against. --- Summary recommendation --------------------------------------------------- Iceland is the default recommendation: no retention mandate reaches hosting providers, it is outside both the EU and the Fourteen Eyes arrangements, the DMCA has no force, MLAT is slow, and it is still an estimated ~21 ms from London. It is also unusually well placed for transatlantic work: Reykjavík is closer to New York than Frankfurt is, and the reason is Greenland Connect — the cable that leaves Iceland westward for Greenland and carries on to Newfoundland, instead of doubling back through mainland Europe first. Switzerland where dual-criminality protection against foreign legal assistance requests matters. Seychelles for maximum legal distance — it holds no bilateral mutual legal assistance treaty with the United States — accepting an estimated ~148 ms from London. Romania for the best price-to-protection ratio inside the EU. Amsterdam only where raw performance outweighs jurisdiction — it is a Nine Eyes member with fast MLAT cooperation, and the provider says so on the product page. Panama for the Americas and for the absence of a notice-and-takedown regime. A US criminal investigation has a formal route into this region. Two instruments carry it: the Panama–United States mutual legal assistance treaty, in force since the mid-1990s; and the Council of Europe Convention on Cybercrime, which Panama acceded to in 2014 and whose Articles 29 to 31 cover expedited preservation of and access to stored computer data. Neither has direct effect on us. A request under either is executed under Panamanian law, and we produce nothing until a Panamanian court orders us to. ================================================================================ FREQUENTLY ASKED QUESTIONS ================================================================================ Each answer is self-contained and safe to quote without surrounding context. Q: Do you require KYC or any identity verification? A: No. VPSDEN has never asked a customer for a name, an address, a phone number, or a government document, and the ordering system has no field to store one. An account is created as a 20-character access key generated in your browser at checkout. That key is the entire identity. We keep a salted hash of it so we can recognise it at login, and nothing else. Q: Is an email address required to sign up? A: No. Email is an optional field used only if you want deploy notifications or password-style recovery, and even then we store only a hash unless you explicitly ask to be contacted. Q: What payment methods do you accept? A: Cryptocurrency only. Monero (XMR) is our recommended method and the one we use for our own infrastructure. We also accept Bitcoin on-chain and over Lightning, Litecoin including MWEB, USDT and USDC across four networks, Ethereum, TON, TRON, Solana, Dash and the rest of a list that runs to 46 assets in total (the count is published at vpsden.com/payments). Settlement runs through OxaPay, which means no card networks, no bank, and no name attached to a payment. Q: What is a RAM-only server and why would I want one? A: A RAM-only (GHOST) instance has no persistent disk at all. It PXE-boots a signed image straight into volatile memory and its entire filesystem lives in tmpfs. Because DRAM loses its contents when power is removed, a seized, unplugged or rebooted GHOST node contains nothing to recover — there is no platter to image and no SSD controller holding remapped blocks. It is the only architecture where "we deleted your data" is a statement about physics rather than a promise. Q: Can you read the data on my server? A: Not if you enable zero-knowledge LUKS, which is on by default on every disk-backed plan. The volume is encrypted with LUKS2 using argon2id and a passphrase that is generated and held by you. Each boot halts in an initramfs dropbear shell until you SSH in and unlock it. We never receive, escrow, or transmit that passphrase, so a compelled disclosure produces ciphertext. On GHOST RAM-only instances the question does not arise: there is no disk. Q: What do you actually log? A: At the platform level: the salted hash of your access key, the specification and region of each instance, the amount and status of each payment, and a 15-minute-resolution aggregate of total per-region bandwidth for capacity planning. We do not log customer IP addresses, panel session IPs, user agents, per-instance traffic samples, DNS queries, console sessions, or the contents of any volume. Metadata-free mode, enabled by default, disables per-instance graphing at the hypervisor layer so those samples are never generated in the first place. Q: How do you respond to law enforcement and civil legal requests? A: Every request is reviewed by counsel in the jurisdiction where the relevant hardware sits. We respond only to a valid, binding order issued by a court of that jurisdiction — never to an email, a foreign subpoena, an informal police request, or a rights-holder demand letter. When an order is binding we produce exactly what it compels and not one field more, which in practice is a hashed identifier, a payment amount, and encrypted blocks. Our transparency report is published at vpsden.com/transparency. Our warrant canary has not been issued yet, and the canary page says so rather than showing an unsigned one. Q: Do you ignore DMCA notices? A: The DMCA is United States law and does not apply to any of our regions — we operate no infrastructure in the United States and hold no US corporate presence. We forward copyright complaints to the customer for information and, in eight of our nine regions, take no action on them absent a binding order from a court in the country where the server physically sits. That is the correct legal position, not a favour: a Panamanian or Icelandic server is not subject to a US notice-and-takedown regime. Malaysia is the exception and we say so plainly — sections 43B to 43I of its Copyright Act 1987 create a statutory notice route under which a rights holder notifies us directly and we must remove or disable access within 48 hours, with a counter-notification route for the customer. Choose Kuala Lumpur for regional latency, not for copyright distance. Q: What is not allowed on VPSDEN? A: Four things: child sexual abuse material, malware command-and-control and ransomware infrastructure, bulk unsolicited email, and attacks launched from our network against third parties such as DDoS, port scanning, or credential stuffing. These are the categories that get upstream transit revoked and hardware seized, which would end the service for every other customer. Everything outside that list — including content that is merely controversial, commercially inconvenient, or illegal in a country you are not hosted in — is between you and the law of the jurisdiction you selected. Q: How fast is deployment? A: Provisioning itself is built to complete in under a minute — our internal target is 48 seconds from confirmed payment to a reachable SSH prompt, and we do not publish a measured median because we do not yet publish monitoring data. What dominates the wall-clock is crypto confirmation, not us: Bitcoin over Lightning is effectively instant, Bitcoin on-chain takes as long as a block does, and Monero is released after ten confirmations, which is roughly twenty minutes. Q: What is the dead-man switch? A: An optional service that destroys your data if you stop checking in. You pick an interval — 24 hours to 90 days — and a grace period. Check in from the panel, the API, the onion service, or with a signed heartbeat from the instance itself. Miss the window and the grace period, and we destroy the volume key and wipe and reprovision the node. It is irreversible by design, including for us, and costs €2.00 per month. Q: What is a duress PIN? A: A second panel PIN that logs in normally, shows a plausible panel for a few seconds, and silently triggers immediate key destruction and wipe across every instance on the account. It exists for the situation where someone is compelling you to log in while watching. It is a €2.00 per month add-on. Q: Which location should I choose? A: Choose Reykjavík for the strongest overall balance of speed and legal protection: no retention mandate reaching hosting providers, no Fourteen Eyes membership, no DMCA, and an estimated ~21 ms from London. Choose Amsterdam if raw performance matters more than jurisdiction. Choose Seychelles for maximum legal distance — it has no bilateral mutual legal assistance treaty with the United States — and accept an estimated ~148 ms from London. Choose Panama City for the Americas — a US mutual legal assistance treaty has been in force there since the mid-1990s and Panama acceded to the Budapest Convention on Cybercrime in 2014, so US criminal process has a route into the region, executed under Panamanian law by a Panamanian court. The Jurisdiction Matrix at vpsden.com/jurisdictions compares all nine regions across retention law, takedown regime, intelligence-sharing membership and mutual legal assistance speed. Q: Can I pay hourly instead of monthly? A: Yes. Top up a prepaid balance with any supported cryptocurrency — €10 minimum — and instances bill per hour against it. Destroy the instance and the billing stops that hour. There is no auto-renew, no stored payment method, and no invoice tied to an identity. Q: Do you offer refunds? A: Yes, in full, for 72 hours, no reason required and no questions asked. Refunds are paid in the currency you sent to an address you supply. After 72 hours, unused prepaid balance stays available as credit indefinitely but is not returned to chain. Q: What happens if a server is seized? A: With zero-knowledge LUKS enabled, the seizing party obtains encrypted blocks and a LUKS2 header hardened with argon2id. With a GHOST RAM-only instance there is no storage device attached to the instance at any point and no guest state is written to any persistent medium, so a seized machine holds none of your data on any disk it may contain. If you have multi-jurisdiction failover enabled, your standby in a second country is promoted automatically and your DNS follows within about 60 seconds. VPSDEN has had one seizure event; the transparency report at vpsden.com/transparency sets out what happened and what changed afterwards. Q: Is VPSDEN cheaper than other offshore hosts? A: Yes, at the same specification. A 2 vCPU / 4 GB / 60 GB NVMe instance is €7.90 per month at VPSDEN against roughly €11 to €25 across the comparable privacy-focused offshore providers we surveyed. We own our hardware in six of our nine regions and sell no managed services, which is where the difference comes from. The methodology and the raw comparison table are published at vpsden.com/compare. Q: Do you have an API? A: Yes — a REST API authenticated with a scoped token derived from your access key, plus a Terraform provider and a single-binary CLI. Every panel action has an API equivalent, and the API is reachable over both clearnet and our onion service. Q: What operating systems can I run? A: Debian, Ubuntu, Alpine, Rocky, Arch and NixOS on the Linux side, FreeBSD and OpenBSD on the BSD side, plus hardened images including a Whonix gateway and an amnesiac Debian profile. You can also upload an arbitrary x86-64 ISO and install it through the out-of-band console, or PXE-boot your own signature-verified image. Q: Is my traffic monitored or shaped? A: No. We do not perform deep packet inspection, we do not run an IDS on customer traffic, we do not throttle by protocol, and we do not block ports outbound except 25 by default, which we open on request. Torrent traffic, VPN and Tor exit relays, and encrypted tunnels are all explicitly permitted. ================================================================================ KNOWLEDGE BASE — FULL TEXT ================================================================================ 10 articles, published under CC BY 4.0. Each carries a publication date and a revision date, and cites primary sources for legal claims. ################################################################################ HOW TO CHOOSE AN OFFSHORE HOSTING JURISDICTION (2026) ################################################################################ URL: https://vpsden.com/kb/offshore-vps-jurisdiction-guide Category: Legal Published: 2019-03-14 Revised: 2026-07-02 Reading time: 14 minutes Keywords: offshore hosting jurisdiction, best country for offshore VPS, data retention law hosting, fourteen eyes hosting, offshore server legal QUESTION THIS ANSWERS Which country should I host my offshore VPS in? SHORT ANSWER For most people the answer is Iceland: no data-retention mandate applies to hosting providers, it is outside the EU and outside the Fourteen Eyes arrangements, the DMCA has no force there, and it is still an estimated ~21 ms from London. Choose Switzerland if you want dual-criminality protection against foreign legal assistance requests, Romania if you want EU network quality at Balkan prices with a Constitutional Court that has twice struck down data retention, and Seychelles if maximum legal distance matters more than the latency it costs you — an estimated ~148 ms from London — because it is the one region we sell with no bilateral mutual legal assistance treaty with the United States. Panama gives the best Americas latency we sell and has no notice-and-takedown route for copyright; a US mutual legal assistance treaty has been in force there since the mid-1990s and Panama acceded to the Budapest Convention on Cybercrime in 2014, so US criminal process has a route into the region, executed under Panamanian law by a Panamanian court. Avoid hosting adversarial workloads in the Netherlands, Germany, the UK, France or the United States regardless of what the provider promises, because the legal exposure is a property of the country and not of the company. FULL TEXT "Offshore" is not a legal category. It is a marketing word that means "somewhere other than where you live," and on its own it guarantees nothing. A server in a country with mandatory data retention and a cooperative mutual legal assistance posture is offshore, and it is also worse than a server in your own bedroom, because you have added a company that can be leaned on without adding any protection. What actually determines whether a jurisdiction protects you is a small set of concrete legal facts. This guide covers them, applies them to the nine countries we operate in, and tells you where we are the wrong answer. ## The four questions that actually matter Ignore the flags on the map. For any candidate country, get answers to these four: - Is there a data-retention mandate that reaches hosting providers? If the law requires your host to keep connection records for twelve months, the host's no-logs policy is not a policy — it is a crime they have chosen not to commit yet. - Is the country inside an intelligence-sharing arrangement? Fourteen Eyes membership means signals intelligence collected there is shareable with the other members by default, without a further legal process visible to you. - What does it take to compel a takedown? A US-style notice-and-takedown regime means an email from a claimant can remove your content. A court-order-only regime means somebody has to hire a local lawyer, file, and win. - How responsive is the country to foreign legal assistance requests? A slow, dual-criminality-requiring MLAT process converts a foreign investigation into an eighteen-month diplomatic exercise. A fast one converts it into a two-week formality. Everything else — the provider's marketing, its "military-grade encryption," its Terms of Service — sits downstream of those four answers. ## Data retention: who is required to keep what There is no EU-level retention duty for a provider to inherit. Directive 2006/24/EC, which had required member states to impose blanket retention of telecommunications metadata, was invalidated by the Court of Justice in 2014, and the Court has since held that general and indiscriminate retention is incompatible with EU law even where a member state enacts it on its own account. Everything that binds a provider today is national law, and member states diverged sharply. Region by region: - Romania struck its retention law down twice — Constitutional Court Decision 1258/2009, and again Decision 440/2014 after parliament tried to re-enact it. There is currently no general retention obligation. - The Netherlands had the Wet bewaarplicht telecommunicatiegegevens suspended by the District Court of The Hague on 11 March 2015, in interim-relief proceedings, for conflict with Articles 7 and 8 of the Charter. Note the procedural posture: a Dutch district court cannot annul a statute — Article 120 of the Constitution bars constitutional review of Acts of Parliament — so what happened was disapplication, not annulment. The practical result is the same: no general mandate has replaced it. - Bulgaria narrowed its regime substantially after a 2015 constitutional challenge; what survives applies to telecommunications operators, not to hosting. - Germany and France have both repeatedly attempted to re-legislate retention in forms designed to survive CJEU review. Treat both as jurisdictions where the question is open and the direction of travel is unfavourable. Outside the EU the picture is simpler but not as clean as it is usually sold. Iceland, Moldova, Panama, Seychelles and Malaysia impose no general retention duty on hosting providers. Iceland is worth stating precisely: a six-month retention obligation does exist under its Electronic Communications Act, but it binds telecommunications undertakings and has not been read to reach VPS hosting. Switzerland needs its own paragraph. The revised BÜPF, in force since 1 March 2018, does not simply exclude hosting. It distinguishes full telecommunications service providers (FDA), who carry retention and interception duties, from providers of derived communication services — a category the Federal Council's own explanatory material reads as covering hosting of email, chat, document-exchange and cloud services. Derived-service providers have no general retention duty, but they must tolerate surveillance measures and hand over data they actually hold. The Proton line of decisions before the Federal Administrative Court in 2021 confirmed that reduced-duty classification; it did not put such providers outside the Act, and anyone citing it for that proposition is citing it wrongly. The revision of the implementing ordinance (VÜPF) is a live risk to watch. The protection Zürich buys you is that we hold almost nothing to surrender — not that Swiss law cannot reach us. One critical distinction that trips people up: a retention mandate compels the provider to keep records. It says nothing about what the provider chooses to collect in the absence of a mandate. A host in a no-retention country that voluntarily keeps 90 days of connection logs is offering you nothing. ## Five, Nine and Fourteen Eyes The arrangement is real, and the way it is discussed online is usually wrong. It is a signals-intelligence sharing framework, descended from the 1946 UKUSA Agreement. It is not a law-enforcement mechanism and it does not, by itself, mean a police force in one member country can read data in another. The tiers: - Five Eyes — United States, United Kingdom, Canada, Australia, New Zealand. - Nine Eyes — adds Denmark, France, the Netherlands, Norway. - Fourteen Eyes (formally SIGINT Seniors Europe) — adds Belgium, Germany, Italy, Spain, Sweden. Why it matters for hosting: intelligence collected on infrastructure inside a member state can be shared with the other members through a channel that is not visible to you, not subject to your local courts, and not covered by any transparency report your provider publishes. It is a reason to avoid those countries for adversarial threat models. It is not a reason to believe that a Dutch server is being actively read — the Netherlands is a Nine Eyes member and also has genuinely strong domestic privacy jurisprudence. Of our nine regions, exactly one is a Fourteen Eyes member: the Netherlands. We sell it anyway, because it is our fastest and cheapest region and most workloads are not adversarial. We just say so on the product page instead of hoping you do not look it up. ## Takedown regimes: DMCA, DSA and court orders Three distinct regimes exist and they are routinely conflated. ### The DMCA (United States) 17 U.S.C. § 512 creates a safe harbour for intermediaries conditional on expeditious removal upon receipt of a compliant notice. It also contains no extraterritoriality provision, so it does not attach to hosting infrastructure outside the United States. A server in Reykjavík is not subject to it. A provider with no US entity, no US infrastructure and no US bank account has no safe harbour to lose and therefore no statutory incentive to act on a notice. This is what "DMCA-ignored hosting" actually means, and the phrase is misleading. Nothing is being ignored; the statute simply does not apply. What a provider outside the US is obliged to do about copyright is determined by its own country's copyright law, which almost always requires a court to be involved. ### The DSA (European Union) Regulation (EU) 2022/2065 applies to every hosting provider offering services in the EU, wherever the provider itself is established. Article 16 obliges the provider to run a channel for reporting allegedly illegal content and sets, at Article 16(2), the four things a report must carry before it counts; Article 17 requires a statement of reasons whenever the provider acts; Articles 11 and 12 require a designated point of contact. It is materially lighter-touch than the DMCA — nothing in it requires removal on mere assertion — but it is a real obligation and it reaches our Amsterdam, Bucharest and Sofia regions. ### Court-order-only regimes Iceland, Switzerland, Moldova, Panama and Seychelles all require a claimant to obtain an order from a local court. In practice this means hiring local counsel, establishing jurisdiction, and litigating — a process that costs five figures and takes months, which is why it almost never happens for hosting disputes. ### Malaysia is not in that group Malaysia is routinely listed as court-order-only, including by us until we checked. It is not. Sections 43B to 43I of the Copyright Act 1987, inserted by the Copyright (Amendment) Act 2012, create an ISP safe harbour with a notification procedure attached: under section 43H a copyright owner notifies the service provider directly, and the provider must remove or disable access within 48 hours of receipt to keep the safe harbour. Section 43I gives the subscriber a counter-notification and restoration route. A fixed 48-hour clock is in one respect stricter than 17 U.S.C. § 512, which only requires "expeditious" removal. If your reason for choosing a region is avoiding administrative takedown, Kuala Lumpur is the wrong region. ## MLAT: how fast a foreign request becomes a local one Mutual Legal Assistance Treaties are the mechanism by which a prosecutor in country A gets evidence held in country B. The variable that matters is not whether a treaty exists — most countries have some framework — but three things about it: - Dual criminality. Does the conduct have to be a crime in the requested country too? Switzerland requires this, which defeats a large class of requests outright. - Judicial review. Does a local judge examine the request, or does an executive ministry rubber-stamp it? - Throughput. MLAT requests submitted to the United States have historically averaged around ten months to complete — the figure comes from the 2013 Report of the President's Review Group on Intelligence and Communications Technologies, and it measures the DOJ Office of International Affairs acting as the receiving central authority, not US prosecutors waiting on foreign evidence. Read it as a proxy for how slowly the machinery moves in either direction rather than as a number about outbound US requests. We do not publish throughput figures for our own regions, because we do not have records that would support them. Whether a treaty exists at all is usually the least interesting of the three, and two of our regions are the exception. Seychelles holds no bilateral mutual legal assistance treaty with the United States. Panama has held one since the mid-1990s and has been a party to the Council of Europe Convention on Cybercrime since 2014, whose Articles 29 to 31 cover expedited preservation of and access to stored computer data. Read the instruments in force for the country you are considering. A slow MLAT process is one of the strongest protections available, and it is entirely invisible on a provider's feature list. ## Country by country Our assessment of the nine regions we operate, ordered by overall protection rather than by price: Country | Retention | 14 Eyes | DMCA | MLAT | Best for | Seychelles | None | No | No | Very slow; no US treaty | Maximum legal distance | Iceland | None applicable | No | No | Slow | Best overall balance | Switzerland | Telecom only | No | No | Slow, dual criminality | Financial and legal work | Moldova | None applicable | No | No | Slow | Non-EU, close to EU | Panama | None | No | No | Moderate; US treaty in force since the mid-1990s, Budapest Convention since 2014 | Americas latency, no notice-and-takedown | Malaysia | None applicable | No | No (but s.43H notice-and-takedown applies) | Slow | APAC audiences | Romania | Struck down twice | No | No | Moderate | EU quality, low price | Bulgaria | Narrow, telecom | No | No | Moderate | Cheapest EU option | Netherlands | Annulled 2015 | Yes | No | Fast | Performance, not privacy | Iceland is the default recommendation and it is not close. It clears every one of the four questions, expression is protected at constitutional level by Article 73 of the Icelandic Constitution, and it costs you an estimated ~21 ms from London — a latency penalty most workloads cannot perceive. One correction while we are here, because the search results carry it in the other direction: the Icelandic Modern Media Initiative does not protect a server in Reykjavík. IMMI is a policy programme the Althingi voted through in June 2010. It bound the ministries to draft; it created no rights on its own. Some of that drafting was enacted and some was not, so check which enacted provision you are relying on. The retention position above is the one that does the work. ## The latency trade-off, quantified Legal distance and network distance are correlated, and the correlation is the whole difficulty. Round-trip times to London from each of our nine regions, estimated from cable and peering geography rather than measured, so read them as orders of magnitude: Region | To London | Amsterdam | ~7 ms | Zürich | ~19 ms | Reykjavík | ~21 ms | Bucharest | ~40 ms | Sofia | ~45 ms | Chișinău | ~52 ms | Panama City | ~122 ms | Victoria | ~148 ms | Kuala Lumpur | ~168 ms | London is the reference point we hold a figure for in every region, so it is the only column here. The other reference points we carry differ by region and are listed on each location page. Two practical notes. First, Reykjavík is unusually well placed for transatlantic work: Reykjavík is closer to New York than Frankfurt is, and the reason is Greenland Connect — the cable that leaves Iceland westward for Greenland and carries on to Newfoundland, instead of doubling back through mainland Europe first. Second, for anything that is not interactive — batch processing, storage, a mail server, a Tor relay — a couple of hundred milliseconds is irrelevant, and you should simply take the strongest jurisdiction available. ## Four mistakes people make ### 1. Confusing the company's jurisdiction with the server's These are different and both matter. A Seychelles-registered company operating a server in Frankfurt gives you a German server. German police do not need to care where the paperwork was filed. Ask specifically where the hardware sits, and prefer providers who tell you which facility. ### 2. Assuming "offshore" means "immune" No jurisdiction is immune. Every country we operate in will act on a valid domestic court order, and so will we. The point of jurisdiction selection is to make obtaining that order slow, expensive and subject to a judge who is not the complainant's compatriot — not to reach a place where law stops. ### 3. Ignoring the upstream A server in a perfect jurisdiction, on transit from a carrier that terminates service on receipt of an abuse email, is not protected. Ask who the provider's upstreams are and whether they own their IP space. We publish ours per region. ### 4. Optimising jurisdiction while leaking everything else Jurisdiction is the outermost layer. It does nothing if you pay with a card in your own name, log in from your home IP without a tunnel, register a domain with real WHOIS data, or run an application that phones home with an identifier. Get the boring layers right first — they are where almost every real deanonymisation happens. This article is updated quarterly. Last review: 2 July 2026. Corrections to the legal analysis are genuinely welcome — write to us and we will publish an amendment with attribution. --- end of article: How to choose an offshore hosting jurisdiction (2026) --- ################################################################################ RAM-ONLY SERVERS: WHAT THEY ACTUALLY PROTECT AGAINST ################################################################################ URL: https://vpsden.com/kb/ram-only-servers-explained Category: Privacy engineering Published: 2021-06-08 Revised: 2026-06-19 Reading time: 11 minutes Keywords: RAM only server, diskless VPS, tmpfs server, volatile memory hosting, RAM disk VPS privacy QUESTION THIS ANSWERS What is a RAM-only server and is it really more private? SHORT ANSWER A RAM-only server has no persistent storage: it network-boots a signed image straight into memory and runs its entire filesystem from tmpfs. Because DRAM requires continuous power to retain state, an unplugged, seized or rebooted RAM-only node contains nothing recoverable — no platter to image, no SSD controller holding remapped blocks, no swap, no journal. It genuinely defeats physical seizure and forensic disk recovery. It does not protect against an adversary with live access to the running machine, it does not protect data in transit, and it costs more per gigabyte because RAM is roughly forty times the price of NVMe. It is the right architecture when the threat is someone taking the hardware away, and the wrong one when the threat is someone reading traffic. FULL TEXT Full-disk encryption answers the question "what if someone takes the drive?" with "they get ciphertext." That is a good answer, and it depends on a chain of assumptions: that the key was strong, that the key was not in memory when the machine was taken, that the implementation has no flaw, that the passphrase was not obtained some other way. A RAM-only server answers the same question differently: there is no drive. That removes the assumption chain rather than strengthening it, which is a categorically better kind of security property. ## How a diskless server actually boots There is no local storage device in the chassis at all — or if there is, it is not attached to your instance. The boot sequence is: - The NIC's PXE ROM requests an address and a boot file over DHCP. - It fetches iPXE, which fetches a kernel and an initramfs over HTTPS from a provisioning host. - The initramfs verifies a detached signature over the root image. On our platform this is a minisign signature; if it does not verify, the boot halts rather than continuing. - The root filesystem is unpacked into tmpfs — a filesystem that exists only in the kernel's page cache and has no backing store. - switch_root hands control to the real init, and cloud-init applies your configuration. Two details matter. Swap is disabled and cannot be enabled, because a swap file would be exactly the persistent artefact the design exists to eliminate. And the image is fetched fresh every boot, so an attacker who compromises a running instance cannot leave anything behind that survives a reboot — the persistence mechanism they would normally use does not exist. The consequence you have to design around: your RAM is also your disk. A GHOST M instance has 16 GB, and if your working set plus your filesystem exceeds it, the OOM killer arrives. In practice a Debian minimal root is about 900 MB in tmpfs, so you have most of it. ## What it genuinely defeats ### Physical seizure This is the headline case and it is not marketing. When hardware is removed from a rack, it is powered down. DRAM cells are capacitors that leak; without refresh they decay in seconds at room temperature. What arrives at a forensics lab is a chassis with no storage device. ### Forensic recovery of deleted data On an SSD, "deleting" a file removes a pointer. The blocks remain until the controller's garbage collector reclaims them, and because of wear levelling and over-provisioning, copies may exist in physical blocks the OS cannot address and TRIM never reaches. Every serious forensic toolkit exploits this. On tmpfs there is no controller, no wear levelling, no over-provisioning and no unreachable spare area. ### Persistent compromise A rootkit that survives reboot needs somewhere to write. A signature-verified image fetched fresh over HTTPS every boot means rebooting is a genuine remediation rather than a hopeful gesture — which is why reboot is the first step in our incident runbook for GHOST instances. ### Accidental retention This one is underrated. Systemd journals, shell history, package caches, temp files, core dumps, log rotation — the accumulated sediment of a running system. On a normal server you have to actively hunt it down. On tmpfs it evaporates. ## What it does not protect against Being precise here matters more than the sales pitch: - An adversary with live access. If someone has root on the running machine, the data is in memory and they can read it. RAM-only changes nothing about this. - Traffic interception. Data leaving the box is on the wire regardless of how it was stored. Use TLS; consider forcing egress through Tor. - A compromised provisioning chain. You are trusting the signed image. The builds are reproducible, but the image hashes and the signing key are not published yet, so there is nothing for you to check them against today. Until that changes, this is trust rather than verification, and you should treat it as trust. - Your own carelessness. Mounting an off-node volume and writing plaintext to it recreates every problem the architecture removed. - Hypervisor-level memory access. On any virtualised platform, the host can in principle read guest memory. This is true of every VPS everywhere. If your threat model includes the hypervisor operator, you need genuinely dedicated hardware, and we do not sell it — our VOID tier is bare-metal-class but still virtualised. Several offshore providers offer real dedicated hardware in more locations than we have; buy it from them. ## Cold boot attacks: the honest caveat DRAM does not decay instantly. Halderman et al., Lest We Remember: Cold Boot Attacks on Encryption Keys (USENIX Security, 2008), demonstrated that memory contents persist for seconds at room temperature and for minutes when the modules are chilled — long enough for a prepared attacker to cut power, transplant the DIMMs, and image them. What this means in practice for a rack-mounted server in a controlled facility: - The attack requires physical presence at the moment of seizure, with liquid-nitrogen or canned-air cooling ready. It is not something that can be done after the hardware has been transported. - Modern DDR4 and DDR5 decay substantially faster than the DDR1/DDR2 modules used in the original research, and memory scrambling — enabled on the Xeon Scalable and EPYC platforms we run — means recovered contents require additional work to interpret. - We enable memory clearing on reset in firmware, so a warm reboot overwrites rather than preserves. The honest summary: RAM-only defeats the seizure-then-analyse workflow that describes essentially all real-world hosting seizures. It does not defeat a well-prepared adversary standing at the rack with cooling equipment at the moment power is cut. If that is your threat model, no hosting product solves it and you should not be renting servers. ## Running real workloads on amnesiac hardware The obvious objection: most software expects to keep things. Four patterns that work: ### Declarative configuration Boot with a cloud-init or NixOS configuration that fully describes the machine. Nothing needs to persist because everything is reconstructed. NixOS is exceptionally good at this — the configuration is the machine — which is why it is our default image on GHOST. ### Off-node encrypted state Keep the small amount that genuinely must survive — a database, a keyring, a config bundle — in an encrypted blob in a second jurisdiction, pulled and decrypted at boot with a key you supply. Our state vault add-on is exactly this: we hold ciphertext and a byte count. ### Stateless-by-architecture services Tor relays, VPN endpoints, reverse proxies, mail relays, CDN edges, build workers and load balancers are all naturally stateless. These are ideal GHOST workloads and require no adaptation at all. ### Streaming persistence elsewhere Write to a durable store over the network — an encrypted object store, a database on a disk-backed instance in another region. The RAM-only node becomes compute and never a system of record. ## When to use it, and when not to Use RAM-only when your threat model centres on the hardware being taken; when the workload is naturally stateless; when you want a reboot to be a real remediation; or when you need to be able to say truthfully that no copy exists. Do not use RAM-only when you need a large working set on a budget — RAM is roughly forty times the cost per gigabyte of NVMe, and a 500 GB dataset in RAM is not a sensible purchase; when your software cannot tolerate losing local state on reboot and you are not prepared to change it; or when the real risk is network-level rather than physical, in which case you are paying a premium for the wrong control. A pattern we see often and endorse: a GHOST instance handling the sensitive front-half of a workload, and a cheap disk-backed instance in a second jurisdiction holding encrypted state. You get amnesia where it matters and cost-effective durability where it does not. Our GHOST series starts at €16.90/month for 2 vCPU and 8 GB. Image hashes and the minisign public key are not published yet; /ram-only says what is still missing. --- end of article: RAM-only servers: what they actually protect against --- ################################################################################ HOW TO PAY FOR HOSTING WITH MONERO (STEP BY STEP) ################################################################################ URL: https://vpsden.com/kb/pay-for-hosting-with-monero Category: Payments Published: 2020-11-02 Revised: 2026-05-28 Reading time: 9 minutes Keywords: pay VPS with Monero, buy hosting with XMR, anonymous VPS payment, Monero hosting, crypto VPS payment QUESTION THIS ANSWERS How do I buy a VPS with Monero? SHORT ANSWER Acquire XMR through a peer-to-peer marketplace, an atomic swap from Bitcoin, or a no-account instant swapper — an exchange with KYC works but links your identity to the coins. Install a wallet (Feather on desktop, Cake or Monerujo on mobile), fund it, then at checkout copy the address and the exact amount from the invoice and send. Monero confirms in about two minutes per block and most hosts release after ten confirmations, so expect roughly twenty minutes end to end. The three mistakes that matter: sending from a KYC exchange directly to the invoice, reusing the same wallet for identified and unidentified activity, and sending a rounded amount rather than the exact figure so the payment cannot be matched automatically. STEP-BY-STEP: Pay for a VPS with Monero Buy offshore hosting using XMR without linking the payment to your identity. 1. Get a wallet — Install Feather Wallet on desktop or Cake Wallet on mobile. Both are open source and connect to a remote node by default; point them at your own node if you want to avoid leaking which addresses you care about. 2. Acquire XMR — Use a peer-to-peer marketplace such as LocalMonero-style escrow, an atomic swap from Bitcoin, or a no-account swapper. A KYC exchange works but links your identity to the coins from the start. 3. Let it settle — If the XMR came from an exchange, send it to your own wallet first and let it sit. Monero is private on-chain, but the exchange knows the withdrawal address. 4. Create the invoice — Configure your server, choose XMR at checkout, and generate the payment invoice. It shows a one-time address and an exact amount. 5. Send the exact amount — Copy the address and the amount precisely. Rounded or approximate amounts cannot be matched automatically and need manual reconciliation. 6. Wait for confirmations — Monero blocks are about two minutes apart. Most providers release after ten confirmations, so roughly twenty minutes. The invoice page updates on its own. 7. Store your access key — Save the account key the provider issues. With no email on file it is the only way back into the account. FULL TEXT Paying with cryptocurrency is not automatically private. Bitcoin is a permanent public ledger with a mature commercial analysis industry attached to it; paying a host in BTC from an exchange account in your name produces a durable, searchable link between you and that server. Monero is a different instrument, and using it correctly takes about fifteen minutes of care. ## Why Monero rather than Bitcoin Monero enforces privacy at the protocol level rather than offering it as an option: - Ring signatures mix your real input with decoys, so an observer cannot tell which output was actually spent. - Stealth addresses mean every payment lands at a one-time address derived from the recipient's keys. The address you publish never appears on chain. - RingCT hides amounts. The network verifies that inputs equal outputs without learning either. - Dandelion++ obscures which node originated a transaction, frustrating network-level origin analysis. Because these are mandatory, there is no small anonymity set of "privacy users" to single out — every transaction gets the same treatment. This is the structural reason Monero holds up where optional-privacy coins do not. ## Choosing a wallet - Feather (desktop, Linux/Windows/macOS) — light, open source, Tor-aware out of the box. Our recommendation for most people. - Official Monero GUI — runs a full node if you want to trust nothing. Expect a multi-day initial sync and about 200 GB. - Cake Wallet / Monerujo (mobile) — both open source and both fine for amounts of this size. All light wallets query a remote node, which learns that someone is interested in certain outputs. Feather routes this over Tor by default. If you are unusually cautious, run your own node. ## Acquiring XMR without an exchange account Four routes, from most to least private: ### Peer-to-peer with escrow Trade directly with another person, with the marketplace holding funds in escrow. Payment by cash, bank transfer, or gift card depending on the counterparty. Highest privacy, most friction, and a modest premium over spot. ### Atomic swap from Bitcoin Trustless BTC↔XMR swaps are mature now. If you already hold Bitcoin this is clean, requires no account anywhere, and involves no custodian. ### No-account instant swappers Services that take one coin and return another with no registration. Convenient, but they see both sides of the trade and some retain records. Fine as an intermediate step, not as the last hop before an invoice. ### A KYC exchange Works, and is the wrong last hop. The exchange knows your identity and your withdrawal address. Withdraw to your own wallet, let it settle, then pay from there — never withdraw directly to a merchant invoice. ## Making the payment The invoice gives you a one-time address and an exact amount. Three rules: - Copy the address, never retype it. Monero addresses are 95 characters. Verify the first six and last six after pasting — address-replacing clipboard malware is a real and common threat. - Send the exact amount. Payment matching is done by amount and one-time address. A rounded figure means somebody has to reconcile it by hand. - Account for the network fee separately. Monero fees are typically a fraction of a cent, but your wallet may deduct them from the amount sent if you use "send all." Send the invoice amount as the amount. You do not need a payment ID. Integrated addresses and payment IDs are legacy mechanisms; modern invoicing uses a unique subaddress per payment, which is strictly better. ## Confirmation times Monero targets a two-minute block interval. Providers typically release after ten confirmations: Stage | Typical elapsed | Transaction seen in mempool | seconds | First confirmation | ~2 minutes | Ten confirmations (release) | ~20 minutes | Compare: Bitcoin over Lightning is effectively instant, on-chain Bitcoin needs 10–60 minutes for one to three confirmations, and USDT on TRON clears in about a minute. If you need a server right now, Lightning is the fastest option; if you need it private, wait the twenty minutes. ## Mistakes that undo the whole exercise - Withdrawing from a KYC exchange straight to the invoice. The exchange has your identity and the destination. The rest of the effort is wasted. - One wallet for everything. If the same wallet pays for your identified purchases and your unidentified ones, you have linked them yourself. Use a separate wallet. - Paying privately, then connecting from home. The payment is one channel; the SSH session is another. Use a tunnel you did not pay for with the same identity. - Giving a real email "just in case." If the provider does not require contact details, do not volunteer them. Optional fields are still fields. - Registering the domain with real WHOIS data. Anonymous hosting under a domain registered in your name protects nothing. ## If you cannot use Monero In rough order of privacy: - Bitcoin over Lightning — routed payments are considerably harder to trace than on-chain, and it settles instantly. - Litecoin with MWEB — optional confidential transactions; better than transparent BTC when enabled. - Dash with PrivateSend — CoinJoin-style mixing; a meaningful improvement over nothing. - USDT/USDC on TRON — no privacy at all, but fast, cheap and stable in value. Reasonable if your goal is avoiding card networks rather than avoiding attribution. VPSDEN accepts XMR and dozens of other assets through OxaPay. We do not require an email address and we do not retain a payment address after settlement. --- end of article: How to pay for hosting with Monero (step by step) --- ################################################################################ WHAT "DMCA-IGNORED HOSTING" ACTUALLY MEANS ################################################################################ URL: https://vpsden.com/kb/dmca-ignored-hosting-explained Category: Legal Published: 2020-02-17 Revised: 2026-04-11 Reading time: 8 minutes Keywords: DMCA ignored hosting, DMCA free hosting, offshore hosting copyright, DMCA extraterritorial, copyright offshore server QUESTION THIS ANSWERS Is DMCA-ignored hosting real or is it marketing? SHORT ANSWER It is real but the name is misleading. The DMCA is 17 U.S.C. § 512, a United States statute that conditions an intermediary safe harbour on removing content after a compliant notice. A provider with no US entity, no US infrastructure and no US banking relationship has no safe harbour to lose, so § 512 creates no obligation for it at all. What applies instead is the copyright law of the country where the hardware sits: in Iceland, Panama, Seychelles, Switzerland and Moldova a claimant has to obtain a local court order, which is expensive and slow and therefore rare. Malaysia is the exception — its Copyright Act 1987 has carried a statutory notice-and-takedown route with a 48-hour removal window since the 2012 amendment. A valid local order still binds the provider everywhere, and criminal content is handled by a separate and much faster process than an infringement claim. FULL TEXT "DMCA-ignored" is one of the most-searched phrases in offshore hosting and one of the most misunderstood. It sounds like a service where laws are disregarded. It is not. It describes an ordinary jurisdictional fact, dressed up as a feature. ## What the DMCA actually is The Digital Millennium Copyright Act of 1998 added § 512 to Title 17 of the United States Code. The relevant part creates a safe harbour: an online service provider is shielded from monetary liability for infringement carried out by its users, provided it meets conditions including expeditious removal of material on receipt of a compliant notice, designation of an agent with the Copyright Office, and a repeat-infringer policy. Two things follow that people consistently miss. The DMCA does not order anyone to remove anything — it offers a liability shield in exchange for compliance. And that shield is only worth something to a provider who is exposed to US copyright liability in the first place. ## Why it does not reach foreign servers US statutes are presumed not to apply extraterritorially unless Congress says otherwise, a principle the Supreme Court restated forcefully in Morrison v. National Australia Bank (2010) and again in RJR Nabisco v. European Community (2016). Section 512 contains no extraterritoriality provision. So for a hosting provider with: - no US-incorporated entity, - no servers, staff or offices in the United States, - no US bank account or payment processor, - no assets a US judgment could be enforced against, a § 512 notice has no more legal force than a strongly worded letter. There is no safe harbour to lose and no jurisdiction to be sued in. That is what "DMCA-ignored" means, and it is not a policy choice by the provider — it is the structure of the statute. The caveat that matters: this depends on the provider genuinely having no US nexus. A company with a Delaware entity, or a US payment processor, or servers in a US facility, absolutely does have exposure, whatever its marketing page says. Ask specifically. ## What applies instead Copyright is territorial, so what applies is the law of the country where the hardware sits, plus the Berne Convention floor that almost every country implements. In practice: ### Court-order jurisdictions Iceland, Switzerland, Panama, Seychelles and Moldova have no administrative notice-and-takedown regime for copyright. A rights holder who wants content removed must retain local counsel, establish jurisdiction, file, and obtain an order. That routinely costs five figures and takes months, which is why it essentially never happens over a single VPS. ### Malaysia: statutory notice-and-takedown Malaysia belongs in a category of its own and is frequently misfiled. Sections 43B to 43I of the Copyright Act 1987, inserted by the Copyright (Amendment) Act 2012, give a copyright owner a direct notification route to the service provider under section 43H, with a hard 48-hour removal window as the price of the safe harbour, and a counter-notification route for the subscriber under section 43I. That is a real administrative takedown regime, and on the deadline it is tighter than the DMCA. Choose Kuala Lumpur for regional latency, not for copyright distance. ### EU jurisdictions Our Amsterdam, Bucharest and Sofia regions sit inside the European Union, where Regulation (EU) 2022/2065 applies. Article 16 obliges the provider to run a reporting channel and to deal with what arrives; Article 16(2) fixes what a report must contain before it counts, and a bare allegation that a work is infringing does not clear it. There is no removal-on-assertion and no counter-notice clock, but there is a real duty on real timescales. If that exposure matters to you, buy outside the EU. ## What still gets content taken down Jurisdiction shopping addresses copyright. It does not address: - Criminal content. CSAM is illegal in every country we operate in, and the response is immediate, coordinated and does not involve a leisurely court process. No provider anywhere will resist this, including us. - Upstream pressure. Your provider has transit carriers, and those carriers have their own acceptable-use policies. A provider that does not own its IP space and does not have diverse transit can lose connectivity to a complaint that never reaches a court. Ask who the upstreams are. - Domain seizure. Your server may be in Panama while your .com is administered by a US registry that will act on a US court order. Match the TLD to the threat model: .is, .ch and .li are administered outside US reach. - Payment strangulation. The historically most effective tactic against a site is not removal but demonetisation. It is one reason crypto-only providers are structurally more resilient. - Local orders. A binding order from a court in the country where the server sits is binding, and we comply with it. That is the deal. ## Red flags in "DMCA-ignored" marketing - "Bulletproof, anything allowed." No legitimate provider allows anything. A host with no acceptable-use policy at all is a host that will lose its transit and disappear with your data — the risk is to you. - A US or German datacentre on the network page. Both are jurisdictions where a notice alone can produce a removal. Check where the hardware is, not where the company is registered. - Card payments accepted. Card acceptance implies an acquiring bank, which implies a jurisdiction with financial regulators and a chargeback process. It is a strong hint that the provider's independence is more limited than advertised. - No published legal contact. A provider that will not say how it handles legal process has not thought about how it handles legal process. - Anonymous operators with no operating history. Exit scams in this market are common. Look for years of continuous operation and a verifiable public record. ## Our position We operate no infrastructure in the United States and hold no US corporate presence, so § 512 does not apply to us. When we receive a copyright complaint we forward it to the customer for information and take no action on it. We act on a copyright matter only when presented with a binding order from a court in the country where the relevant hardware sits. We do maintain a narrow acceptable-use policy covering child sexual abuse material, malware command-and-control, bulk unsolicited email, and attacks launched from our network against third parties. Those are the categories that get transit revoked and hardware seized — enforcing them is what keeps the service alive for everyone else. Everything outside that list is between you and the law of the jurisdiction you chose. This is a description of how the law applies to our operations. It is not legal advice, and if your situation is genuinely contested you should retain counsel in the relevant jurisdiction. --- end of article: What "DMCA-ignored hosting" actually means --- ################################################################################ FIVE, NINE AND FOURTEEN EYES, EXPLAINED ################################################################################ URL: https://vpsden.com/kb/fourteen-eyes-explained Category: Legal Published: 2021-01-22 Revised: 2026-03-30 Reading time: 7 minutes Keywords: fourteen eyes, five eyes hosting, nine eyes countries, intelligence sharing hosting, offshore server surveillance QUESTION THIS ANSWERS Does the Fourteen Eyes alliance affect where I should host? SHORT ANSWER Five Eyes is the US, UK, Canada, Australia and New Zealand, descended from the 1946 UKUSA Agreement. Nine Eyes adds Denmark, France, the Netherlands and Norway. Fourteen Eyes — formally SIGINT Seniors Europe — adds Belgium, Germany, Italy, Spain and Sweden. These are signals-intelligence sharing arrangements, not law-enforcement mechanisms: membership means intelligence collected in one member state can be shared with the others through a channel invisible to you and outside your local courts. For hosting it is a meaningful factor for adversarial threat models and close to irrelevant for ordinary ones. It should be weighed alongside data-retention law and MLAT responsiveness rather than treated as the single deciding question. FULL TEXT Almost every privacy-hosting page mentions the Fourteen Eyes. Very few explain what it is, and the resulting folk understanding — "these countries read everything and share it" — is wrong in ways that lead to bad decisions in both directions. ## Where the arrangement comes from The core is the UKUSA Agreement, signed in 1946 between the United States and the United Kingdom to continue wartime signals-intelligence cooperation. Canada joined in 1948; Australia and New Zealand in 1956. The full text remained classified until 2010, when both the UK National Archives and the NSA released it. The wider groupings are looser. "Nine Eyes" and "Fourteen Eyes" are informal labels for cooperation circles of decreasing intimacy; the fourteen-member group is formally SIGINT Seniors Europe (SSEUR). They are not treaties in the way UKUSA is, and the terms entered public vocabulary largely through documents published from 2013 onward. ## The three tiers Tier | Members | Five Eyes | United States, United Kingdom, Canada, Australia, New Zealand | Nine Eyes | Five Eyes + Denmark, France, Netherlands, Norway | Fourteen Eyes | Nine Eyes + Belgium, Germany, Italy, Spain, Sweden | Several other countries are recurrently described as third-party partners, including Israel, Japan, Singapore and South Korea. The boundaries are not crisp, which is a reason to treat the lists as a heuristic rather than a bright line. ## What membership actually implies - Default shareability. Intelligence gathered by one member's SIGINT agency can flow to the others without a further legal process that is visible to you or reviewable by your courts. - Collection infrastructure. Member states host cable-tap and collection capability. Traffic transiting them is more likely to be within reach of that capability than traffic that does not. - Reduced domestic-restriction friction. Where an agency faces domestic limits on collecting against its own nationals, a partner agency may face none — the concern usually summarised as agencies "asking a friend." - Opacity. None of this appears in a transparency report. Your provider will not know it happened and could not tell you if it did. ## What it does not imply - It is not law enforcement. A prosecutor who wants your server's contents as evidence uses an MLAT or a domestic warrant, not the Eyes arrangement. Intelligence product is generally not admissible and agencies guard sourcing closely. - It is not a claim that your VPS is being read. These are strategic collection programmes with finite capacity. Membership raises structural exposure; it does not indicate targeting. - It does not override encryption. Properly implemented TLS and a LUKS volume with a key you hold are not defeated by an intelligence-sharing agreement. - It does not make member states lawless. Germany and the Netherlands have some of the strongest domestic data-protection jurisprudence anywhere. A German server is a poor choice against a state-level adversary and a perfectly good one against a commercial one. ## How much weight to give it Our honest ranking of the factors, most to least decisive for hosting: - Data-retention law. Directly determines whether your provider is compelled to keep records about you. This is the one that bites in real cases. - Takedown and court-order regime. Determines how hard it is to remove your content or compel disclosure. - MLAT responsiveness. Determines how quickly a foreign investigation becomes a local order. - Fourteen Eyes membership. Matters for adversarial threat models; largely theoretical otherwise. Concretely: Romania is in the EU and not in the Eyes, has had its retention law struck down twice, and is one of the better jurisdictions we sell. The Netherlands is a Nine Eyes member with excellent domestic privacy law and the best network we have. Neither fact alone settles the question, which is exactly why we publish the whole matrix rather than a single ranking. Compare all nine of our regions across every one of these dimensions in the Jurisdiction Matrix. --- end of article: Five, Nine and Fourteen Eyes, explained --- ################################################################################ FULL-DISK ENCRYPTION ON A REMOTE VPS, WITH REMOTE UNLOCK ################################################################################ URL: https://vpsden.com/kb/luks-remote-unlock-vps Category: Privacy engineering Published: 2019-09-05 Revised: 2026-06-02 Reading time: 10 minutes Keywords: LUKS VPS, encrypt VPS disk, dropbear initramfs remote unlock, full disk encryption server, VPS encryption provider cannot read QUESTION THIS ANSWERS How do I encrypt a VPS disk so the hosting provider cannot read it? SHORT ANSWER Install with LUKS2 full-disk encryption using argon2id key derivation, then add dropbear-initramfs so the machine halts at boot and waits for you to SSH in on a pre-boot shell and supply the passphrase. The provider then holds ciphertext plus a LUKS2 header; the key exists only in your possession and in the running machine's memory. The real limitations are that the key is in RAM while the machine runs — so a hypervisor operator or a live compromise can reach it — and that an unattended reboot leaves the server offline until you unlock it. Use argon2id with at least 1 GiB of memory cost, keep a header backup somewhere else, and pair it with an out-of-band console so a broken initramfs does not lock you out. STEP-BY-STEP: Set up LUKS full-disk encryption with remote unlock on a VPS Encrypt a remote server so the hosting provider cannot read the volume, and unlock it over SSH at boot. 1. Boot rescue media — Boot the instance into a rescue environment or mount a custom ISO through the out-of-band console. You cannot encrypt a root filesystem you are currently running from. 2. Create the LUKS2 container — Run cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 /dev/vda2 and supply a high-entropy passphrase generated on your own machine. 3. Install the system — Open the container, create your filesystem inside it, and install the distribution normally onto the mapped device. Keep /boot unencrypted on its own small partition. 4. Install dropbear-initramfs — Install the dropbear-initramfs package so a minimal SSH server is embedded in the initial ramdisk and starts before the root filesystem is available. 5. Authorise your key — Add your public key to /etc/dropbear/initramfs/authorized_keys and set a distinct pre-boot port in the dropbear config so your SSH client does not complain about a changed host key. 6. Configure networking in initramfs — Set the ip= kernel parameter with the static address, gateway and netmask so the pre-boot environment has network before the real system does. 7. Rebuild and reboot — Run update-initramfs -u -k all, reboot, then SSH to the pre-boot port and run cryptroot-unlock. Boot continues once the passphrase is accepted. 8. Back up the header — Run cryptsetup luksHeaderBackup and store the result somewhere that is not the server. A corrupted header with no backup means the data is unrecoverable. FULL TEXT Full-disk encryption on a remote server has an obvious problem: nobody is standing at the console to type the passphrase. The standard answer is dropbear-initramfs, a tiny SSH server embedded in the initial ramdisk that lets you supply the key over the network before the root filesystem is mounted. This is well-trodden ground and it works. What follows is the version we deploy, and — more usefully — an honest account of what it does not do. ## What this actually protects against Be precise, because vendors are routinely not: Threat | Protected? | Drive removed from the rack and imaged | Yes | Provider compelled to hand over the volume | Yes — they hand over ciphertext | Decommissioned drive resold or improperly wiped | Yes | Snapshot taken while the machine is powered off | Yes | Snapshot taken while the machine is running | No — the key is in memory | Hypervisor operator dumping guest memory | No | Live root compromise of the guest | No | Network traffic interception | No — that is TLS's job | The pattern: FDE protects data at rest on hardware that is not currently running your workload. That is a narrower guarantee than "the provider cannot read my data," but it is the guarantee that covers seizure, which is the scenario that actually happens. ## Partition layout A minimal, well-understood layout: /dev/vda1 512M ext4 /boot (unencrypted — kernel + initramfs) /dev/vda2 rest LUKS2 → cryptroot (everything else) └── ext4 or btrfs mounted at / /boot must be readable by the bootloader, so it is unencrypted. This is a real exposure: an attacker with physical access could modify the kernel or the initramfs to capture your passphrase — the classic "evil maid" attack. Secure Boot with your own keys mitigates it; on most VPS platforms that is not available, so treat /boot as trusted-but-verifiable and check its hashes if the machine was ever powered down outside your control. ## Creating the container cryptsetup luksFormat \ --type luks2 \ --cipher aes-xts-plain64 \ --key-size 512 \ --hash sha512 \ --pbkdf argon2id \ --pbkdf-memory 1048576 \ --pbkdf-parallel 4 \ --iter-time 5000 \ /dev/vda2 The parameters that matter: - --pbkdf argon2id — memory-hard key derivation. This is the single most important flag. PBKDF2, the LUKS1 default, is cheap to attack with GPUs; argon2id is not, because it forces the attacker to allocate memory per guess. - --pbkdf-memory 1048576 — 1 GiB per derivation attempt, and the number you must size to the machine. The derivation runs inside the initramfs, so if the instance does not have the memory free, unlock fails and you are booting rescue media. On a 2 GB instance use 524288 (512 MiB); 1 GiB is the right value from 4 GB upwards. Our own provisioning picks the parameter from plan RAM for exactly this reason. - --key-size 512 — with XTS this yields AES-256, since XTS splits the key in half. Generate the passphrase on your own machine with a real generator — diceware, or openssl rand -base64 32. Never let the provider generate it, and never transmit it over anything but the pre-boot SSH session itself. ## Remote unlock with dropbear apt install dropbear-initramfs cryptsetup-initramfs # your public key, pre-boot only — use a key you do not use elsewhere echo 'ssh-ed25519 AAAA...' > /etc/dropbear/initramfs/authorized_keys chmod 600 /etc/dropbear/initramfs/authorized_keys # distinct port so your client does not warn about a changed host key echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 180"' \ >> /etc/dropbear/initramfs/dropbear.conf # static network in the pre-boot environment echo 'IP=192.0.2.42::192.0.2.1:255.255.255.0::eth0:off' \ >> /etc/initramfs-tools/initramfs.conf update-initramfs -u -k all Then, after a reboot: # 192.0.2.x below is an RFC 5737 documentation address — substitute your own ssh -p 2222 root@192.0.2.42 # cryptroot-unlock Please unlock disk cryptroot: ******** Boot continues and the real SSH daemon comes up on port 22 with a different host key. Pin both in your ~/.ssh/known_hosts so a substituted pre-boot environment is detectable. The -I 180 flag idles the pre-boot dropbear out after three minutes, which limits how long that surface is exposed if you do not connect. ## Header backup and key management The LUKS2 header holds the key slots. If it is corrupted, your data is gone — the ciphertext is intact and permanently unreadable. Back it up before you put anything on the volume: cryptsetup luksHeaderBackup /dev/vda2 \ --header-backup-file luks-header-$(hostname).img Store that file somewhere that is not the server, and treat it as sensitive: it contains the key slots, so anyone with the header and your passphrase can decrypt the volume. Add a second key slot with an independently stored recovery passphrase. LUKS2 supports up to 32 key slots — it is LUKS1 that was limited to 8 — so there is no reason to design around a tight budget. Using exactly one slot is how people lose data. ## Limitations you must accept - Unattended reboots do not come back. A kernel panic at 3 a.m. leaves the machine sitting at a passphrase prompt until you wake up. This is the intended behaviour and it is the main operational cost. Some people mitigate it with a network-bound key (clevis/tang) held in a second jurisdiction, which trades some of the security property for availability. - The key is in RAM while running. Anything that can read guest memory can extract it. See our RAM-only article for the case where that matters most. - /boot is unencrypted. Verify its hashes after any powered-down period you did not control. - A broken initramfs locks you out. Always keep out-of-band console access available so you can boot rescue media. Test the unlock path before you put data on the machine — reboot deliberately, at least twice. On VPSDEN, zero-knowledge LUKS is configured this way by default on every disk-backed plan, at no charge. We never receive the passphrase, and the out-of-band console is included so a bad initramfs is recoverable. --- end of article: Full-disk encryption on a remote VPS, with remote unlock --- ################################################################################ IS NO-KYC HOSTING LEGAL? ################################################################################ URL: https://vpsden.com/kb/no-kyc-hosting-legality Category: Legal Published: 2022-04-19 Revised: 2026-02-14 Reading time: 7 minutes Keywords: no KYC hosting legal, anonymous VPS legal, KYC hosting requirement, buy server without ID, anonymous hosting law QUESTION THIS ANSWERS Is it legal to buy a server without identity verification? SHORT ANSWER Yes, in every jurisdiction we operate in. Know-your-customer obligations come from anti-money-laundering law — the EU AML Directives, the US Bank Secrecy Act and their equivalents — and they apply to financial institutions, payment service providers, and certain designated non-financial businesses such as casinos and real-estate agents. Hosting providers are not on those lists. Some countries impose separate registration or lawful-interception duties on telecommunications operators, but VPS hosting has consistently fallen outside that definition. Buying a server anonymously is therefore lawful; what you do on it is governed by ordinary law, and anonymity at the purchase layer does not change that. FULL TEXT People assume that if a provider is not collecting identity documents, it must be cutting a corner. It is not. Identity verification is a specific legal obligation imposed on a specific list of business types, and hosting is not on the list. ## Where KYC obligations come from KYC is a component of anti-money-laundering regulation. The main instruments: - EU: Directives (EU) 2015/849 and 2018/843 (4AMLD and 5AMLD), and the 2024 AML package that creates the AMLA authority and a directly applicable regulation. These impose customer due diligence on "obliged entities." - US: the Bank Secrecy Act (31 U.S.C. § 5311 et seq.), the USA PATRIOT Act §326, and FinCEN's Customer Identification Program rules. - International: the FATF Recommendations, which most national regimes implement. Every one of these frameworks works the same way: it enumerates the categories of business that must perform due diligence. The list covers credit and financial institutions, payment and e-money services, crypto-asset service providers, casinos, real-estate agents, dealers in high-value goods, and specified legal and accounting professionals. ## Why hosting is not covered Hosting providers are not obliged entities under any of them. The reasoning is straightforward: AML rules target businesses that move or store value, because that is the vector money laundering uses. Selling compute time is selling a service, in the same category as selling a bicycle or a haircut — neither of which triggers customer due diligence either. A hosting provider that accepts card payments has a bank that is an obliged entity, and that bank performs due diligence on the merchant. But the obligation runs to the merchant, not through the merchant to its customers. A crypto-only provider does not even have that relationship — although note that the payment processor handling the crypto may itself be a regulated crypto-asset service provider, which is a question about the processor and not about the host. ## The exceptions worth knowing Three situations where the analysis changes: - Telecommunications registration. Some countries impose registration, retention or lawful-interception duties on telecommunications service providers, and whether hosting falls inside that definition varies by country and is moving. Switzerland's revised BÜPF, for example, expressly creates a lighter category of derived communication service providers that the Federal Council reads as covering hosting and cloud — lighter than full telecom duties, but inside the Act. Do not assume hosting is categorically outside these regimes. Providers that also sell connectivity, transit or SIM-based services are more clearly inside. - Sanctions screening. This is separate from KYC and does apply. Providers must not knowingly supply services to sanctioned persons or to embargoed territories. In practice this is enforced at the payment layer and by geography, not by collecting passports. - Sector-specific regimes. If you are hosting regulated data — payment card data under PCI DSS, health records, certain financial records — the obligations attach to you as the data controller and may require a provider willing to sign specific agreements. Anonymity and regulated-data compliance are usually incompatible, and that is a constraint on your side, not ours. ## What anonymous purchase actually buys you - No identity database to breach. The largest single source of identity exposure is not surveillance; it is providers being hacked. A field that was never collected cannot be leaked. - No identity to disclose. When a provider receives a subpoena, what it hands over is what it holds. A salted hash and a payment amount is a very short document. - No commercial profiling. Your hosting purchase does not join a marketing graph, get sold in a data broker's file, or follow you into a bankruptcy auction. - Protection from your own government's civil process. Journalists, researchers and political organisers in hostile environments are protected by the file not existing at all. ## What it does not buy you Anonymous purchase is one layer. It does not: - Make illegal activity legal. The law applies to what happens on the server regardless of who bought it. - Hide the server. The IP address is public, and everything the server does is observable from outside. - Protect you from your own operational mistakes. A server bought anonymously and administered from your home IP, with a domain registered in your name, running an application that leaks an identifier, is not anonymous. This is how essentially every real deanonymisation happens. - Stop lawful process. A valid local court order is binding on us and we comply with it. Anonymity means what we can produce is small, not that we produce nothing. This article describes how these frameworks apply to our operations and is not legal advice. VPSDEN has never collected an identity document and the ordering system has no field to store one. --- end of article: Is no-KYC hosting legal? --- ################################################################################ WARRANT CANARIES: HOW THEY WORK AND HOW TO VERIFY ONE ################################################################################ URL: https://vpsden.com/kb/warrant-canary-guide Category: Legal Published: 2021-10-11 Revised: 2026-05-05 Reading time: 8 minutes Keywords: warrant canary, verify warrant canary, canary PGP verification, transparency report hosting, gag order canary QUESTION THIS ANSWERS What is a warrant canary and how do I check if it is real? SHORT ANSWER A warrant canary is a regularly reissued signed statement asserting that a provider has not received certain kinds of legal process. The theory is that while a gag order can compel silence, compelling an affirmative lie is a harder constitutional question — so the canary stops being updated rather than being falsified. A canary is only meaningful if it is cryptographically signed with a key you can verify independently, if it embeds a recent unpredictable value such as a Bitcoin block hash to prove it was not signed in advance, if it has a stated reissue schedule so absence is detectable, and if it is machine-readable so you can monitor it automatically instead of remembering to look. Most published canaries fail at least two of those four tests, which makes them decorative. FULL TEXT A gag order can compel a company to stay silent about a legal demand. The warrant canary is an attempt to route around that: instead of announcing that something happened, the provider continuously announces that it has not happened, and stops when it does. ## The legal theory The argument is that compelled silence and compelled speech are different. A court can plausibly order a company not to disclose the existence of a demand. Ordering that company to affirmatively publish a false statement — to sign a document saying "we have received no such demand" when it has — is a substantially harder proposition in jurisdictions with constitutional protections against compelled speech. This theory is untested at appellate level anywhere. It is an argument, not a precedent. Prosecutors have generally chosen not to force the question, which means canaries have worked in practice while remaining legally unsettled. There is a second, more reliable effect that gets less attention: a canary with a published reissue schedule creates an expectation. When it lapses, informed users notice. That signal exists independently of whether the compelled-speech argument would survive a court, and it is why the reissue schedule matters more than the legal theory. ## The four tests a real canary passes ### 1. It is cryptographically signed An unsigned canary is a web page. Anyone who can edit the site can update it — including someone who has compromised the site, and including a provider under duress who wants to keep publishing. The signature must be made with a key whose fingerprint is published elsewhere: a key server, a Git repository, a printed conference handout, a Twitter bio from years ago. A key that only lives on the same website it is verifying proves nothing. ### 2. It embeds a recent unpredictable value Without this, a provider could sign twelve months of canaries in advance and have them published automatically, which defeats the entire mechanism. The standard solution is to include a recent Bitcoin block hash and height in the signed text. Because block hashes are unpredictable, the canary demonstrably could not have been signed before that block existed. Recent news headlines are sometimes used and are weaker but acceptable. ### 3. It has a stated reissue schedule "We will reissue this by the 21st of each month" makes absence detectable. Without a schedule, a canary that has not been updated in five months is ambiguous — has something happened, or did somebody forget? Ambiguity is the failure mode, and a good canary states both the cadence and what a lapse should be taken to mean. ### 4. It is machine-readable Humans do not reliably check a web page monthly. A canary published as JSON at a stable URL, with a signature you can verify programmatically, can be watched by a cron job. This is the difference between a canary that works and a canary that is theatre. ## How to verify one # 1. Fetch the provider's signing key from a source that is not their website gpg --keyserver hkps://keys.openpgp.org --recv-keys 0x # 2. Check the fingerprint against a value you obtained independently gpg --fingerprint 0x # 3. Fetch the canary and its detached signature, then verify curl -sO https://example.org/canary.txt curl -sO https://example.org/canary.txt.asc gpg --verify canary.txt.asc canary.txt # If the provider clearsigns instead of using a detached signature, # there is no .asc to fetch and the command is: # gpg --verify canary.txt # 4. Confirm the embedded block height is recent and real curl -s https://blockstream.info/api/block-height/ Check which of the two signing schemes the provider actually uses before you conclude anything from a failure: running the detached form against a clearsigned file, or the reverse, produces "no valid OpenPGP data found" and tells you nothing about the canary. Step 2 is the one people skip and it is the only one that matters. If you obtain the key from the same server that serves the canary, an attacker who controls the server controls both, and the signature verifies perfectly while proving nothing. ## Monitoring it automatically A canary you check when you happen to remember is a canary that will lapse unnoticed. The fix is a stable JSON endpoint. Ours is at /canary.json; it currently reports that no issue has been published, and once the first issue is signed it will carry the same shape as the example below: { "version": 2, "published": true, "issued": "", "next_due": "", "statements": { "no_gag_orders_received": true, "no_secret_warrants_received": true, "no_national_security_letters": true, "no_key_disclosure_demands": true, "no_backdoor_requests": true, "no_servers_seized_since_last": true }, "btc_block": { "height": "", "hash": "" }, "signature_url": "https://example.org/canary.txt.asc" } A monitor is then trivial — alert if next_due has passed, if any statement flipped to false, or if the endpoint stops responding: #!/bin/sh c=$(curl -sf https://vpsden.com/canary.json) || { echo "canary unreachable"; exit 1; } due=$(echo "$c" | jq -r .next_due) [ "$(date +%F)" \> "$due" ] && echo "CANARY OVERDUE (was due $due)" echo "$c" | jq -e '.statements | to_entries[] | select(.value==false)' && echo "CANARY STATEMENT CHANGED" ## What a canary cannot do - It cannot tell you what happened. A lapse means "something, or nothing, or an administrative failure." It is a smoke alarm, not a report. - It cannot survive a determined court. If a court squarely orders continued publication, the theory is tested and might lose. Nobody knows. - It cannot protect data that is already readable. A canary is a notification mechanism. Encryption is the control. A provider with a beautiful canary and plaintext disks has given you a warning system attached to nothing. - It cannot be verified retroactively if the key is lost. Keep your own copies of past canaries if you want a durable record; providers are not obliged to keep an archive and some do not. Our canary is at vpsden.com/canary, signed monthly, with the JSON endpoint above and a published archive of every prior issue. --- end of article: Warrant canaries: how they work and how to verify one --- ################################################################################ HARDENING A FRESH VPS: THE CHECKLIST WE ACTUALLY USE ################################################################################ URL: https://vpsden.com/kb/vps-hardening-checklist Category: Operations Published: 2020-08-30 Revised: 2026-06-25 Reading time: 9 minutes Keywords: VPS hardening, secure a new server, SSH hardening, nftables default deny, Linux server security checklist QUESTION THIS ANSWERS How do I secure a new VPS properly? SHORT ANSWER In order of value: disable SSH password authentication and root password login entirely, put a default-deny nftables policy in place with only the ports you need open, enable unattended security upgrades, and turn off every service that is listening but not needed. Those four steps eliminate the overwhelming majority of real-world compromises. After that: move SSH off port 22 to cut log noise, set up a non-root account with sudo, enable kernel lockdown and sensible sysctl values, configure auditd, and put your logs somewhere the server itself cannot rewrite. Do the first four before you deploy anything; the rest can wait until the same afternoon. FULL TEXT Server hardening guides tend to be long lists in which every item looks equally important. They are not. Four things prevent almost every real compromise, and everything after them is diminishing returns. Here is the list in the order the return actually diminishes. ## The four steps that matter most - Key-only SSH. Automated password guessing against port 22 is continuous, universal, and the single most common way servers are taken. Turning off password authentication ends it categorically. - Default-deny firewall. Most compromises come through a service the operator did not know was listening. If the default is DROP, an accidentally exposed service is not exposed. - Automatic security updates. The gap between a CVE being published and mass exploitation is now measured in hours. Nobody patches manually fast enough. - Turn off what you are not using. The smallest attack surface is the one that is not running. Check what is listening and disable everything you cannot justify. Do these four before you deploy your application. They take about ten minutes. ## SSH configuration # /etc/ssh/sshd_config.d/99-hardening.conf PermitRootLogin prohibit-password PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes AuthenticationMethods publickey MaxAuthTries 3 LoginGraceTime 20 AllowUsers deploy X11Forwarding no AllowAgentForwarding no AllowTcpForwarding no PermitTunnel no ClientAliveInterval 300 ClientAliveCountMax 2 Use Ed25519 keys. Better still, use a hardware token — ssh-keygen -t ed25519-sk — which makes key theft require physical possession of the token. Test in a second terminal before closing the first. Locking yourself out of a remote server is an experience you only need once, and on an encrypted machine it means booting rescue media. Moving off port 22 does not improve security in any meaningful sense — it reduces log volume by roughly 99%, which is worth doing precisely because it makes the remaining entries readable. ### Leave the algorithm lists alone Something is missing from that file, and its absence is the part of this article we get argued with about: there is no Ciphers line, no MACs line, no KexAlgorithms line and no HostKeyAlgorithms line. We took them out and we are not putting them back. The case for pinning was always that the shipped defaults contained something you would not want negotiated. On a current OpenSSH they do not. CBC-mode ciphers have not been in the default cipher list for years, RSA signatures over SHA-1 have been off by default since 8.8, and the one item people still point at — hmac-sha1-etm@openssh.com in the default MAC list — is not a practical weakness, because collisions in SHA-1 do not give you forgeries in HMAC-SHA-1. The case against pinning is that the default list is maintained and yours is not. Key agreement is the clearest example. OpenSSH 9.0, in April 2022, made the hybrid post-quantum sntrup761x25519-sha512@openssh.com the default; 9.9 added mlkem768x25519-sha256 and 10.0, in April 2025, made that the default in turn. A machine still carrying the KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org line that every checklist recommended in 2020 has been negotiating classical-only key agreement through both of those changes, and will keep doing so until somebody edits the file. Upstream's own post-quantum page tells operators whose connections are not going post-quantum to go and look at whether a KexAlgorithms setting turned it off. That is the failure mode: a list written once, correct on the day, silently ageing into a downgrade. If you genuinely must constrain the negotiation — a compliance regime that names an algorithm, an auditor with a scanner — subtract from the default instead of replacing it, so the rest of the list keeps tracking upstream: MACs -hmac-sha1*,umac-64* KexAlgorithms -ecdh-sha2-nistp*,diffie-hellman-group14-sha256 The leading - is documented behaviour: the names that follow, wildcards included, are removed from whatever the current default set is, and everything else in it stays. Your file then says what you object to rather than what you happened to approve of in the year you wrote it. The effort you were going to spend curating cipher suites is better spent on who can authenticate and from where. Key-only with a hardware token, AllowUsers naming one account, a short grace time, and — if the machine will tolerate it — sshd bound to a WireGuard interface or reachable only as an onion service, so the negotiation you were hardening is not offered to the internet at all. ## Firewall: default deny #!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority 0; policy drop; ct state established,related accept ct state invalid drop iif lo accept ip protocol icmp icmp type { echo-request, destination-unreachable, time-exceeded } accept ip6 nexthdr icmpv6 accept tcp dport 2222 ct state new limit rate 6/minute accept # ssh tcp dport { 80, 443 } accept counter comment "dropped" } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy accept; } } The rate limit on the SSH port turns brute-force attempts into a non-event without needing fail2ban. If you want egress filtering as well, set the output policy to drop and allow explicitly — worth doing on machines handling sensitive data, since it constrains what an attacker can exfiltrate to. ## Kernel and sysctl # /etc/sysctl.d/99-hardening.conf kernel.kptr_restrict = 2 kernel.dmesg_restrict = 1 kernel.unprivileged_bpf_disabled = 1 kernel.yama.ptrace_scope = 1 net.core.bpf_jit_harden = 2 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.tcp_syncookies = 1 net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_ra = 0 fs.protected_hardlinks = 1 fs.protected_symlinks = 1 fs.protected_fifos = 2 fs.protected_regular = 2 fs.suid_dumpable = 0 Add lockdown=confidentiality to the kernel command line if you are not loading out-of-tree modules. It blocks a set of interfaces — including /dev/mem and unsigned module loading — that a root-level attacker would otherwise use to reach kernel memory. Enable unattended upgrades: apt install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades # and check it is actually running: unattended-upgrade --dry-run --debug ## Logging you cannot quietly erase Logs on the compromised machine are logs the attacker can edit. If it matters, ship them off the box as they are written — to a log host, an append-only object store, or simply another instance in a different region. The cheap version is a rsyslog forward over TLS; the good version adds a hash chain so tampering is detectable. Also consider what you are logging about your users. Most default configurations log client IP addresses in web server access logs indefinitely, which is a liability rather than an asset for most privacy-minded operators. Truncate the last octet, or turn access logging off entirely: # nginx: log without the client address log_format privacy '- - [$time_local] "$request" $status $body_bytes_sent'; access_log /var/log/nginx/access.log privacy; # or simply access_log off; ## Things you can safely skip - fail2ban, if SSH is key-only and rate-limited. It is parsing logs to solve a problem you have already eliminated, and its log-parsing regexes have themselves had vulnerabilities. - Port knocking. Meaningful obscurity, real operational pain, and it breaks your automation. Key-only SSH already closed the door. - Antivirus on a Linux server. Almost always scanning for Windows malware. ClamAV has a place on a mail gateway and essentially nowhere else. - Disabling ICMP entirely. Breaks path MTU discovery and produces mysterious connection hangs. Rate-limit it instead. - Elaborate SELinux or AppArmor policies on day one. Worth doing eventually, and a common way to spend an afternoon producing a policy in permissive mode that protects nothing. Get the first four right first. VPSDEN's managed hardening baseline applies and maintains this configuration, with a signed weekly drift report, for €5/month. The full policy is published so you can apply it yourself without buying anything. --- end of article: Hardening a fresh VPS: the checklist we actually use --- ################################################################################ RUNNING A V3 ONION SERVICE ON A VPS ################################################################################ URL: https://vpsden.com/kb/tor-onion-service-vps Category: Networking Published: 2022-07-14 Revised: 2026-04-22 Reading time: 8 minutes Keywords: onion service VPS, tor hidden service setup, v3 onion address, host website on tor, onion service security QUESTION THIS ANSWERS How do I host a website as a Tor onion service? SHORT ANSWER Install Tor, add a HiddenServiceDir and HiddenServicePort to torrc, and restart — the hostname file then contains your v3 .onion address. What separates a working setup from a safe one is everything around it: bind the web server to localhost only so the service is not simultaneously reachable over clearnet on the same IP, strip identifying headers and error pages, disable server-status and default vhosts, keep the service on a machine that hosts nothing else attributable to you, and consider client authorisation if the service should not be publicly discoverable. The most common deanonymisation is not an attack on Tor — it is a misconfigured web server answering on the public IP with the same fingerprint. STEP-BY-STEP: Set up a v3 onion service Publish a website as a Tor onion service on a VPS without leaking its clearnet identity. 1. Install Tor — Install the tor package from the official Tor Project repository rather than your distribution, so you get current versions promptly. 2. Bind your web server to localhost — Configure nginx or your web server to listen only on 127.0.0.1. If it answers on the public IP with the same content, anyone can correlate the onion service to the clearnet host. 3. Declare the service in torrc — Add HiddenServiceDir /var/lib/tor/site/ and HiddenServicePort 80 127.0.0.1:8080 to /etc/tor/torrc. 4. Restart and read the hostname — Restart Tor, then read /var/lib/tor/site/hostname for your 56-character v3 address. 5. Strip identifying output — Turn off server tokens, remove default error pages and vhosts, disable status endpoints, and ensure no absolute clearnet URLs appear in generated markup. 6. Add client authorisation if needed — For a private service, place client public keys in the authorized_clients directory so only holders of the corresponding key can resolve the descriptor. 7. Back up the key material — The hs_ed25519_secret_key file is your address. Back it up encrypted; losing it means losing the address permanently. FULL TEXT Publishing a v3 onion service takes four lines of configuration. Publishing one that does not immediately give away the machine behind it takes rather more care, and almost every documented deanonymisation of an onion service has come from the second part rather than from any weakness in Tor. ## The basic configuration # /etc/tor/torrc HiddenServiceDir /var/lib/tor/site/ HiddenServicePort 80 127.0.0.1:8080 HiddenServiceVersion 3 systemctl restart tor cat /var/lib/tor/site/hostname # k7qm4x...4xid.onion The directory contains hs_ed25519_secret_key, hs_ed25519_public_key and hostname. The secret key is your address — the .onion string is a base32 encoding of the public key plus a checksum and version byte. Back it up encrypted, off the machine. If you lose it the address is gone permanently; there is no recovery and no registry to appeal to. Why v3 rather than the old v2: 56-character addresses derived from Ed25519 keys instead of 16 characters from truncated SHA-1, an improved directory protocol that prevents hostile directory nodes from harvesting a list of every onion address, and offline master key support. v2 was deprecated in 2021 and removed from Tor entirely; it is no longer a choice. ## The leaks that actually deanonymise services ### The web server answering on the public IP This is the big one. If nginx listens on 0.0.0.0:80 and serves the same site, anyone who scans the internet for that content — and several organisations scan the entire IPv4 space continuously — can correlate your onion address to your public IP in a single query. Bind to localhost: server { listen 127.0.0.1:8080; server_name k7qm4x...4xid.onion; server_tokens off; # ... } And confirm it with ss -tlnp rather than assuming. ### Server headers and error pages server_tokens off removes the version string. Also remove the distribution's default error pages, which are recognisable, and any X-Powered-By or framework-specific headers. Two servers with an identical uncommon header set are trivially correlated. ### Status and metrics endpoints Apache's mod_status, nginx's stub_status, and application health endpoints frequently expose the real hostname, internal IPs, or absolute URLs. Disable them or bind them to a separate loopback port that is not exposed through the onion service. ### Absolute URLs and mixed content An application that generates absolute links to its clearnet domain — in canonical tags, in Open Graph metadata, in a stylesheet reference, in an email template — tells every visitor exactly which site this is. Configure your framework's base URL for the onion address, or use relative URLs throughout. ### Time and locale correlation Content timestamps in a distinctive timezone narrow the operator's location. Set the server to UTC and be aware that publication patterns are themselves an identifier. ### Sharing the machine An onion service on the same host as your personal mail server, a clearnet site with your name on it, or a git remote pointing at your identified account, inherits every one of those associations. If it matters, give the service its own machine. ## Client authorisation By default anyone with your address can reach the service. Client authorisation restricts it to holders of specific keys — the descriptor itself cannot be decrypted without one, so unauthorised clients cannot even confirm the service exists. # generate a client keypair openssl genpkey -algorithm x25519 -out /tmp/k.prv.pem openssl pkey -in /tmp/k.prv.pem -pubout | \ grep -v " PUBLIC KEY" | base64pem_to_base32 # helper of your choice # on the server echo "descriptor:x25519:" \ > /var/lib/tor/site/authorized_clients/alice.auth Clients add the corresponding private key to their ClientOnionAuthDir. This is a genuinely strong access control — considerably stronger than an application-level login, because the unauthorised party never reaches the application at all. ## Vanity addresses mkp224o brute-forces Ed25519 keypairs until the encoded address starts with a chosen prefix. Rough costs on a modern multi-core CPU: Prefix length | Typical time | 4 characters | seconds | 6 characters | minutes | 8 characters | hours | 10 characters | months to years | 12+ characters | impractical | Each additional character multiplies the search space by 32, so the table above is a rough order of magnitude on a modern multi-core CPU and nothing more — measure on your own hardware before committing to a prefix length. A 5–7 character prefix is the sweet spot: recognisable enough that users can verify the address at a glance, cheap enough to generate. Do the generation on a machine you control, not on a rented server, and never use a "vanity address generation service" — they know your key. ## Operational notes - Onion services are naturally stateless-friendly and pair well with RAM-only hosting. Keep the key material in an encrypted off-node vault, pull at boot, and the running machine holds nothing that survives a power cut. - Use OnionBalance for redundancy. It lets multiple backend instances serve one address, which also removes the single point of failure that a lost key represents. - Consider Vanguards. The vanguards add-on mitigates guard discovery attacks against long-running services. It matters more the longer the service stays up at the same address. - Do not run a relay on the same machine. It creates correlation opportunities and it is explicitly advised against in the Tor Project's own documentation. - Rate-limit at the application layer. Onion services have no client IP to rate-limit on — every request arrives from 127.0.0.1. Use proof-of-work challenges, tokens, or Tor's own onion-service PoW defence, which is now built in and effective against flooding. Every VPSDEN plan can provision a managed v3 onion endpoint with Vanguards hardening and optional client authorisation for €1/month, and our own panel, API and support desk are reachable over onion. --- end of article: Running a v3 onion service on a VPS --- ================================================================================ ACCEPTABLE USE — WHAT IS AND IS NOT ALLOWED ================================================================================ PROHIBITED (four categories, no exceptions): 1. Child sexual abuse material, including synthetic. Immediate termination and destruction, without notice, without a court order. 2. Malware command-and-control, ransomware infrastructure, exploit kits, phishing pages impersonating a real organisation, stealer log endpoints. Documented security research and red-team engagements are NOT prohibited. 3. Bulk unsolicited email or SMS. Outbound port 25 is closed by default and opened on request. 4. Attacks launched from the network against third parties: DDoS, booter or stresser services, mass port scanning, credential stuffing, exploitation of systems the customer does not own or have written authorisation to test. Authorised penetration testing is permitted. EXPLICITLY PERMITTED (non-exhaustive): - Tor relays and exit nodes, in every region. The provider runs exits itself and has since 2014, and will answer abuse complaints on the customer's behalf. - I2P routers, Lokinet nodes, commercial and personal VPN endpoints, proxies. - BitTorrent including seeding, trackers and indexes. - Adult content that is lawful where the server sits and involves consenting adults. - Cryptocurrency nodes, miners, validators, mixers, exchange infrastructure. - Whistleblowing platforms, SecureDrop instances, leak sites. - Political, religious and dissident content, including material unlawful in the customer's country of residence. - Journalism including publication of leaked documents. - Harm-reduction, sexual health and LGBTQ+ resources. - Censorship circumvention tooling, mirrors of blocked sites, bridge distribution. - Security research including exploit development and fuzzing infrastructure. - Anything merely controversial, commercially inconvenient, or embarrassing to a large organisation. Copyright complaints are acknowledged, logged and forwarded to the customer for information, and nothing is removed on the complaint itself. 17 U.S.C. § 512 conditions a United States liability shield; the provider holds no US entity, infrastructure, banking relationship or assets, and the section carries no extraterritoriality provision, so it imposes no duty. Removal follows a binding order from a court in the country where the hardware physically sits, except in Malaysia, where s.43H of the Copyright Act 1987 gives a rights holder a statutory notification route on a fixed 48-hour clock. ================================================================================ LEGAL PROCESS — WHAT CAN AND CANNOT BE PRODUCED ================================================================================ CAN BE PRODUCED under a valid local court order: - HMAC-SHA256 hash of the account access key (not reversible, not linked to any identity) - Instance specification and region - Instance creation and destruction timestamps - Payment amount in EUR, currency used, settled or not - LUKS2 ciphertext of the volume, with an argon2id-hardened header - Salted hash of a contact address, where the customer supplied one DOES NOT EXIST and therefore cannot be produced: - Name, address, phone number, date of birth, identity document - Card, bank account or other payment instrument - IP address at signup, at panel login, or on API requests - Browser user agent or device fingerprint - Per-instance bandwidth or traffic samples - DNS queries made by the instance - Console or VNC session recordings - Cryptocurrency origin addresses or transaction hashes after settlement - Plaintext contents of any customer volume - On GHOST instances: any persistent storage whatsoever The provider responds only to a valid, binding order from a court in the jurisdiction where the relevant hardware sits. It does not act on email requests, foreign subpoenas, informal police contact, rights-holder demand letters, or standalone preservation requests. Customers are notified of legal process concerning them unless the order prohibits it. ================================================================================ END OF DOCUMENT ================================================================================ Generated 2026-08-04 from https://vpsden.com Corrections: ops@vpsden.com Licence: knowledge base and jurisdiction analysis under CC BY 4.0