[$ xmrhost] _

$ pwd

/node/dedicated/ds-beast

[$ ] DS Beast — no-KYC offshore dedicated servers (Iceland, Romania, Monero)

// NAME

ds-beast — Top-spec dual-Xeon dedicated for enterprise loads.

// SYNOPSIS 

xmrhost-cli provision --plan=ds-beast --region=<is|ro>

// SPEC

$ xmrhost-cli spec --plan=ds-beast

cpu 2× Intel Xeon Gold 6338 (32c / 64t each)
ram 256 GB DDR4 ECC
storage 4× 4 TB NVMe (RAID-10)
bandwidth Unmetered
port 10 Gbps
virtualization Bare-Metal
os Ubuntu, Debian, AlmaLinux, Windows Server, Proxmox, VMware
ip 1 × IPv4 + IPv6
ddos-shield 400 Gbps
uptime-sla 99.99%

// REGIONS

$ xmrhost-cli regions --plan=ds-beast

region country ping flag
is Iceland (Reykjavik) ~38ms FRA --region=is
ro Romania (Bucharest) ~28ms FRA --region=ro

// ORDER

Order DS Beast

monthly +30% $584
annual -20% $4310
biennial -25% $8082
$ order ds-beast

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

// PROVISIONING

after you click order 

$ xmrhost-cli provision --plan=ds-beast --region=is
[ok] reserving capacity in region=is
[ok] node allocated: ds-beast-is-90
[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.

// HARDENING BASELINE — WHAT SHIPS BY DEFAULT

$ cat /etc/xmrhost/baseline.d/*

Every DS Beast ships with the xmrhost 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.

// RECOMMENDED PLAYBOOKS

$ grep -l 'ds-beast' /usr/share/doc/xmrhost/playbook/

  • /playbook/ai-inference — open-weight llm serving on offshore gpu — vllm + ollama preinstalled, outside us export-control gating
  • /playbook/crypto-node — run a btc/eth/xmr/lightning node or pos validator on hardware you control, in a crypto-neutral jurisdiction

// FAQ

$ faq -p ds-beast

Q.Is this a real bare-metal server?

A.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.

Q.Where is the dedicated server hosted?

A.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.

Q.Do I need to pay in Monero?

A.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.

Q.What hardening is applied to the dedicated server?

A.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.

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

A.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.

Q.What's the SLA on dedicated?

A.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

$ xmrhost-cli order --plan=ds-beast

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

// BEFORE YOU ORDER — RELEVANT GUIDES

$ ls /guide