[$ xmrhost] _

$ pwd

/node/gpu/gpu-lite

[$ ] GPU Lite — RTX 4090 — no-KYC offshore GPU servers (Iceland, Romania, Monero)

// NAME

gpu-lite — Offshore RTX 4090 for AI inference & rendering.

// SYNOPSIS

xmrhost-cli provision --plan=gpu-lite --region=<is|ro>

// SPEC

$ xmrhost-cli spec --plan=gpu-lite

cpu 8 vCPU (Threadripper)
ram 64 GB DDR5
storage 1 TB NVMe SSD
bandwidth 20 TB / month
port 10 Gbps
virtualization Bare-Metal
os Ubuntu 22.04 + CUDA 12, Debian + CUDA 12, Custom
ip 1 × IPv4 + IPv6
ddos-shield 40 Gbps
uptime-sla 99.9%

// NOTES

  • NVIDIA RTX 4090 (24 GB VRAM)
  • Pre-installed PyTorch & vLLM

// REGIONS

$ xmrhost-cli regions --plan=gpu-lite

region country ping flag
is Iceland (Reykjavik) ~38ms FRA --region=is

// ORDER

Order GPU Lite — RTX 4090

monthly +30% $636
annual -20% $4694
biennial -25% $8802
$ order gpu-lite

// 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=gpu-lite --region=is
[ok] reserving capacity in region=is
[ok] node allocated: gpu-lite-is-72
[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 GPU Lite — RTX 4090 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.
  • INFERENCE STACK. CUDA 12.x toolkit, cuDNN, NCCL, NVIDIA driver matched to the installed accelerator, vLLM (latest stable), Ollama with model-registry mirror, llama.cpp (CUDA-compiled), PyTorch + transformers — preinstalled, container runtime ready.

// 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

$ faq -p gpu-lite

Q.What GPU is in each tier?

A.Tier-specific. The lite tier is RTX 4090 24GB (Ada Lovelace, 16384 CUDA cores, 82.58 TFLOPs FP16); pro is RTX 4090 24GB × 2; beast is H100 80GB SXM (Hopper, 14592 CUDA cores, 989.4 TFLOPs FP16) — the latter is procurement-sensitive. Spec is on the plan detail page; if the listed GPU is unavailable at order time the operator surfaces the substitute via /contact before charging.

Q.What does "offshore GPU hosting" actually buy me vs cloud?

A.Two things. (1) Jurisdiction — the box runs in Iceland or Romania, neither of which is subject to US export-control orders that gate cloud GPU access for some workloads (open-weight LLMs from non-US authors, certain red-team / jailbreak-eval workloads, etc.). (2) Billing privacy — Monero / no-KYC vs cloud-card-on-file. The trade-off vs hyperscaler GPU is honestly documented at /playbook/ai-inference.

Q.Is vLLM / Ollama / llama.cpp preinstalled?

A.Yes — the gpu-* tiers ship with vLLM (latest stable), Ollama (with the model registry mirror configured), llama.cpp (CUDA-compiled), CUDA 12.x toolkit, cuDNN, NCCL, PyTorch with CUDA support, and the HuggingFace transformers stack. Customers needing other inference engines (TensorRT-LLM, mlc-llm, exllama2) install via the package manager — the box is a normal Linux machine with NVIDIA driver + container runtime support.

Q.Can I serve LLM endpoints publicly?

A.Yes — the AUP (/legal/aup) does not restrict serving open-weight LLM inference endpoints. Customers running a public chat / API surface should configure their own rate-limits and authentication; the operator does not provide a hosted gateway. Per /docs (Caddy-fronted vLLM is the common pattern), the xmrhost hardening defaults already cover the OS layer.

Q.Where is the GPU server hosted?

A.Iceland (Reykjavik, RIPE) — the GPU catalog is Iceland-only because the Romanian racks do not have the GPU-density power / cooling provisioned. Iceland's hydroelectric + geothermal power is the operator's preference for GPU workloads on cost and emissions footprint; jurisdictional posture is at /location/is.

Q.Do I need to pay in Monero?

A.No. XMR is recommended; OxaPay accepts BTC, Lightning, LTC, ETH, and USDT. GPU-tier orders settle the same way VPS orders do — per-order Monero subaddress on XMR (MRL-0006), straight invoice on the transparent rails. No card, no fiat. The /why-monero rationale applies identically.

// ORDER

$ xmrhost-cli order --plan=gpu-lite

// 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