DS Pro — no-KYC offshore dedicated servers (Iceland, Romania, Monero)
ds-pro — EPYC-grade offshore dedicated for production.
xmrcloud-cli provision --plan=ds-pro --region=<is|ro>Order DS Pro
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-pro
xmrcloud-cli describe --plan=ds-pro
ds-pro is the throughput tier: an EPYC 7443P (24c/48t), 128 GB ECC, 2×2 TB NVMe in RAID-1, a 10 Gbps uplink, and a 100 TB allowance behind a 200 Gbps shield. Where ds-mid favours single-thread latency, ds-pro sustains many concurrent processes — a consolidated multi-service platform, a video back-catalogue served to many viewers, or a Monero + Bitcoin + Lightning node cluster. Workloads that genuinely saturate this belong on the dual-socket ds-beast; most production loads do not, and stop here.
xmrcloud-cli regions --plan=ds-pro
after you click order
xmrcloud-cli provision --plan=ds-pro --region=is
[ok] reserving capacity in region=is
[ok] node allocated: ds-pro-is-14
[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 Pro 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/securityonly — feature releases stay operator-controlled. systemd-journald persistent storage withSystemMaxUse=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.
grep -l 'ds-pro' /usr/share/doc/xmrcloud/playbook/
- /playbook/ai-inferenceopen-weight llm serving on offshore gpu — vllm + ollama preinstalled, outside us export-control gating
- /playbook/crypto-noderun a btc/eth/xmr/lightning node or pos validator on hardware you control, in a crypto-neutral jurisdiction
faq -p ds-pro
What workloads justify ds-pro over ds-mid?
Sustained many-process throughput: a consolidated multi-service platform for a team, a video back-catalogue served to many concurrent viewers over the 10 Gbps uplink, or a large crypto-node cluster with heavy egress. The EPYC 7443P's 24c/48t and 128 GB ECC are about parallel throughput, where ds-mid's Ryzen is about single-thread latency.
Is the 10 Gbps uplink on ds-pro unmetered?
The uplink is 10 Gbps with a 100 TB monthly allowance — generous but metered. If your workload genuinely needs unmetered 10 Gbps egress (large-scale media distribution), ds-beast ships an unmetered port. For most production loads 100 TB is ample; overage terms are at /legal/aup.
Does ds-pro carry a 99.99% SLA?
Yes — ds-pro and ds-beast are the dedicated tiers at 99.99% (ds-lite and ds-mid are 99.9%). The credit ladder is at /legal/sla and the no-synthetic-badges framing at /uptime. Hardware swap on confirmed-failed diagnostics is within the SLA's stated 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.
no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.
ls /guide
- /guide/buy-vps-with-monero — step-by-step XMR checkout walkthrough.
- /guide/buy-vps-with-bitcoin — BTC / Lightning flow + chain-analytics caveat.
- /guide/how-to-host-a-website-anonymously — three-tier threat-model guide.
- /guide/best-offshore-vps-2026 — evaluation methodology + plan-to-use-case mapping.