$ pwd
[$ ] DS Mid — no-KYC offshore dedicated servers (Iceland, Romania, Monero)
// NAME
ds-mid — Mid-tier offshore dedicated — Ryzen 9 power.
// SYNOPSIS
xmrhost-cli provision --plan=ds-mid --region=<is|ro> // SPEC
$ xmrhost-cli spec --plan=ds-mid
// REGIONS
$ xmrhost-cli regions --plan=ds-mid
// ORDER
Order DS Mid
// 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-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.
// HARDENING BASELINE — WHAT SHIPS BY DEFAULT
$ cat /etc/xmrhost/baseline.d/*
Every DS Mid 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/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.
// RECOMMENDED PLAYBOOKS
$ grep -l 'ds-mid' /usr/share/doc/xmrhost/playbook/
- /playbook/scraping — stable-asn vps for ethical crawling: clean ip reputation, generous egress, no per-target rate limits
- /playbook/crypto-node — run a btc/eth/xmr/lightning node or pos validator on hardware you control, in a crypto-neutral jurisdiction
- /playbook/ai-inference — open-weight llm serving on offshore gpu — vllm + ollama preinstalled, outside us export-control gating
// FAQ
$ faq -p ds-mid
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-mid// 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
- /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.