xmrcloud
menu

DS Mid — no-KYC offshore dedicated servers (Iceland, Romania, Monero)

ds-mid — Mid-tier offshore dedicated — Ryzen 9 power.

xmrcloud-cli provision --plan=ds-mid --region=<is|ro>

Order DS Mid

monthly $149
annual -20% $1430
biennial -25% $2682
order ds-mid

no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.

xmrcloud-cli spec --plan=ds-mid

cpu AMD Ryzen 9 5950X (16c / 32t @ 3.4 GHz)
ram 64 GB DDR4 ECC
storage 2× 1 TB NVMe (RAID-1)
bandwidth 50 TB / month
port 1 Gbps
virtualization Bare-Metal
os Ubuntu, Debian, AlmaLinux, Windows Server, Proxmox
ip 1 × IPv4 + IPv6
ddos-shield 100 Gbps
uptime-sla 99.9%

xmrcloud-cli describe --plan=ds-mid

ds-mid pairs a Ryzen 9 5950X (16c/32t @ 3.4 GHz base) with 64 GB ECC and 2×1 TB NVMe in RAID-1 — the high-clock, single-thread-favouring platform for latency-sensitive work: real-time corpus indexing, public-record scraping at a meaningful clip, or a CMS + search + image pipeline competing on one box. The 50 TB transfer and 100 Gbps shield carry a mid-bitrate media workload. Sustained many-process throughput wants ds-pro's 24-core EPYC; if removing the hypervisor is the only goal, ds-lite does it for less.

xmrcloud-cli regions --plan=ds-mid

region country ping flag
is Iceland (Reykjavik) ~38ms FRA --region=is
switzerland Switzerland (Zurich) ~?ms --region=switzerland
netherlands Netherlands (Amsterdam) ~?ms --region=netherlands
ro Romania (Bucharest) ~28ms FRA --region=ro
moldova Moldova (Chișinău) ~?ms --region=moldova
bulgaria Bulgaria (Sofia) ~?ms --region=bulgaria
russia Russia (Moscow) ~?ms --region=russia
panama Panama (Panama City) ~?ms --region=panama

after you click order

xmrcloud-cli provision --plan=ds-mid --region=is
[ok] reserving capacity in region=is
[ok] node allocated: ds-mid-is-39
[ok] applying hardened-by-default profile (sshd, fail2ban, unattended-upgrades)
[ok] base image bootstrapped (Debian 12)
[ok] handoff key sealed → view via the console at /console
provisioned in 47s. ssh access via onion-auth or wireguard, your choice.

you receive the onion-auth key + initial sshd config in the same handoff. no email-shipped credentials. nothing is logged to the operator side.

cat /etc/xmrcloud/baseline.d/*

Every DS Mid ships with the xmrcloud hardening baseline applied on the first boot — no opt-in flag, no add-on, no separate purchase. The baseline is the same across the catalog (vps / dedicated / gpu / tor / i2p / lokinet); category-specific extras are listed below the common section. Detailed per-control runbooks live in /docs; the cross-cutting overview is at /hardening.

  • KERNEL. KSPP-baseline sysctls applied (kernel.kptr_restrict=2, kernel.yama.ptrace_scope=1, kernel.unprivileged_bpf_disabled=1, vm.unprivileged_userfaultfd=0, net.ipv4.tcp_syncookies=1, +12 more), unprivileged user-namespace creation gated, kexec disabled at runtime. Full list and rationale: /docs/kernel-hardening-checklist.
  • SSHD. PasswordAuthentication no, ChallengeResponseAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin prohibit-password, MaxAuthTries 3, Ed25519-only host keys (RSA host keys removed), legacy KEX / cipher / MAC families disabled. fail2ban preconfigured with the sshd-default ruleset. Runbook: /docs/harden-sshd; key migration: /docs/ssh-key-migration.
  • AUDIT. auditd enabled with the laurel-compatible default ruleset (auth, identity, network-config, time-change, mount, perm-mod). unattended-upgrades on for main/security only — feature releases stay operator-controlled. systemd-journald persistent storage with SystemMaxUse=512M.
  • NETWORK. Egress-default-permit (the box reaches the internet), ingress-default-deny (only sshd + the customer's declared services). Outbound port 25 (SMTP) closed by default; customers operating a real MTA request the lift via /contact with the reverse-DNS pointing to a domain they control. Dual-stack IPv4 + IPv6 (/64 routed). RIPE- allocated PI on Iceland and Romania.
  • MONITORING. node_exporter (Prometheus textfile exporter) listening on 127.0.0.1:9100 — the operator's monitoring scrapes via wireguard from the management VLAN, never from the public internet. Customers wanting their own metrics tap add a second exporter on a private interface.
  • BARE-METAL ACCESS. IPMI / iDRAC / iLO console access depending on chassis vendor, full sysctl control, customer can swap kernel (linux-hardened, grsec-flavoured patches if a subscription is held), grub LUKS + dropbear-initramfs available for full-disk encryption with remote unlock.

the baseline is editorial-stable — when the operator changes a default, the change is logged in /notes with the rationale and the migration notes for boxes already in service. /hardening is the canonical pillar; /docs is the procedural manual.

faq -p ds-mid

ds-mid or ds-pro?

ds-mid's Ryzen 9 5950X favours single-thread latency (16c/32t at a high 3.4 GHz base) — best for real-time indexing, scraping, and latency-sensitive pipelines. ds-pro's 24-core EPYC favours sustained throughput across many concurrent processes. Pick ds-mid for fewer, faster threads; ds-pro for many parallel ones.

Is ds-mid good for a crypto full-node cluster?

Yes — 64 GB ECC and 2×1 TB NVMe in RAID-1 comfortably host several full nodes (Bitcoin unpruned, Monero, Lightning) side by side with room for their indices. The high-clock Ryzen helps initial block download and reorg handling. For an unmetered-egress node-distribution role, ds-pro's 10 Gbps uplink is the better fit.

What does the 100 Gbps DDoS shield mean in practice?

Volumetric L3/L4 filtering upstream, sized to survive campaigns that take smaller shields offline — appropriate for a publication or service that draws sustained adversarial traffic. It is not L7/application protection; you still run your own rate-limiting. Attack-traffic data is retained only for the operational response window.

Is this a real bare-metal server?

Yes. Dedicated tiers ship with full bare-metal hardware (no virtualization layer, no hypervisor). The customer has IPMI / iDRAC / iLO access depending on chassis vendor for OS reinstall and emergency console. The OS is whatever the customer picks at provisioning — Debian / Ubuntu / Rocky / Alma / OpenBSD / Whonix Gateway templates are all available; bring-your-own-ISO is supported on request via /contact.

Where is the dedicated server hosted?

Iceland (Reykjavik, RIPE) at the moment — the dedicated catalog is Iceland-only at MVP because the Romania racks are spec'd for VPS density rather than bare metal. The Iceland datacenter has hydroelectric / geothermal power, RIPE-allocated IPv4 + IPv6, and the jurisdictional posture documented at /location/is.

Do I need to pay in Monero?

No. XMR is recommended (chain-analytics-resistant) but the OxaPay processor accepts BTC, Lightning, LTC, ETH, and USDT. The trade-off is documented at /why-monero. For a dedicated tier the order surface is the same as VPS — no card, no fiat, no KYC bridge. Per-order Monero subaddresses are derived per MRL-0006.

What hardening is applied to the dedicated server?

The same KSPP kernel-baseline + sshd / auditd / unattended-upgrades hardening that VPS tiers receive. On a dedicated chassis the customer also gets full sysctl control, can recompile a hardened kernel (linux-hardened from Arch or grsec-flavoured patches if the customer holds a grsec subscription), and can install grub LUKS + dropbear-initramfs for full-disk encryption with remote unlock. Default install ships unencrypted; encryption is opt-in per-customer.

Can I host a Tor relay or exit node on a dedicated server?

Yes. Dedicated bandwidth (unmetered on the contracted port speed) makes the dedicated tier the right pick for high-traffic Tor relays. The AUP (/legal/aup) permits middle, exit, and bridge relays. Dedicated tor-relay setup is documented at /docs/run-non-exit-tor-relay and /docs/bgp-resilience-for-tor-relay-operators.

What's the SLA on dedicated?

The /legal/sla document covers the full uptime target (99.9% monthly on the contracted port, hardware swap within 4 hours of confirmed-failed diagnostics). Service credits ladder per the SLA section 3 schedule. The honest framing is at /uptime — synthetic 99.99% badges are not used; the SLA reflects what the operator can actually commit to.

order ds-mid

no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.

ls /guide