The FYRHost knowledge base: how to use it, what each cluster covers, where to start by task

An annotated map of the FYRHost knowledge base: payments, anonymity, jurisdiction, self-hosting, hardware and ops — where to start, by task.

Published 2026-08-30 · Updated 2026-10-10 · FYRHost Editorial · 20 min read

How to read this knowledge base

The counter-intuitive habit that saves the most time here: skip the overview you are reading for as long as you can. This base is built narrow on purpose — one page per decision, one decision per page — and the fastest route to an answer is almost always the specific guide, not the hub. What this page adds is the map: which clusters exist, what each one covers, and which page answers which task, so the narrow guide you need is one hop away instead of five.

Three routes in, by design. By task — I need to pay, I need a domain, my box is under attack — the task list in the second-to-last section maps straight to a page. By cluster — payments, anonymity, jurisdiction, self-hosting, hardware, ops — the sections below annotate each one and its guides. By product — VPS, storage, dedicated — the hardware cluster covers the sizing and comparison pages. Every guide is self-contained, so entering anywhere does not require the others; links run one way, from context to detail.

The facts are grounded in one catalog and stay consistent across pages: forty locations on four continents, nineteen coins from XMR to GRAM (TON), a Saint Kitts and Nevis contract entity in Nevis, and a root-only service that never grows a managed layer at any tier. Prices quote list and annual-eff side by side — Scout at the floor of the ladder, Sentinel at the top — because the −20% annual term applies before coin conversion everywhere.

You can put the base to work in one sitting if you let the map do its only job: find the cluster that names your problem, open its entry page, and close this one. The 40-location map, the 19-coin checkout and the credential-only account are the three facts every page assumes, and everything else you will pick up in the terminal where it sticks. If you read nothing else today, read the payments entry and the limits page — between them, you will know what you are buying and what you are not. The map earns its keep when you arrive with half a task — you leave with the other half, priced and scheduled.

The typical failure mode of a knowledge base is horizontal reading: eleven tabs open, no box bought, no key rotated. Each page here ends with the action the page was about, and the honest use of the hub is one pass through the map, then execution in a terminal. With the reading rules set, the cluster tour starts where most purchases do — the invoice.

The payments cluster

The entry page is the crypto payment flow guide, because every coin-specific question dissolves once the shared mechanics are clear: an invoice in USD, a live-rate conversion, an exact-amount match by a server-side watcher, a single-use address, and a confirmation depth printed per chain. Read that page before any coin page — the recurring confusion in tickets is a flow question misread as a coin question, such as why an underpaid transfer credits nothing automatic.

The coin pages then answer one question each. GRAM (TON) covers the UQ address, the Jetton trap, and the 1–3 minute window; USDT-TRC20 covers the stable-dollar invoice and the cheapest cents-level fees; XRP covers the dollar-shaped quote that clears in seconds. The Monero walkthrough covers the rail that says least on-chain, and the Bitcoin-versus-Monero comparison puts the two philosophies side by side for buyers who want the trade stated, not implied. The Monero product page carries the plan pricing beside the coin.

What the cluster agrees on is worth stating once: the invoice binds one asset on one network, addresses never repeat, and the −20% annual term comes off the USD total before conversion — so the discount is coin-independent and the ledger verbosity is your only real choice. External grounding stays primary: the Monero project's own explanation of RingCT and one-time addresses is the reference for why that rail differs structurally.

You can watch the flow's rules do real work in the coin pages once you know them: when the GRAM guide tells you a Jetton never credits, you are reading the single-use rule from the token side; when the Monero walkthrough prices your privacy in XMR, you are reading the ledger-verbosity rule as a number. Keep UQ… for TON, TRC-20 for the stable dollar figure, and the exact-amount rule for all of them — three tokens that settle most payment questions you will ever raise in a ticket.

The cluster's typical mistake is sequence: picking a coin from a comparison table before understanding the flow, then blaming the coin for an underpayment the flow rules explained. Flow first, coin second, and the whole cluster compresses into one habit — pay the printed figure once. The next cluster covers what those invoices buy besides servers: the shortest file the industry sells.

The anonymity cluster

This cluster is built around one honest sentence: the host's file is a credential and a bill, and everything else is yours. The conceptual entry is Is a VPS anonymous?, which splits the question into its three layers — the host file, the payment chain, the publication surface — and prices each layer's risk in operational terms. The mechanical entry is the minimum-data checkout guide, which walks the signup field by field with the token option.

Around that pair, the cluster covers the surfaces where identity leaks back in. Hosting a website anonymously and registering the domain handle the publication layer — WHOIS, certificates, headers — where a real-name registration undoes a quiet invoice. The no-email signup guide covers the token route, and onion service hosting covers serving without revealing the box's address at all, grounded in the Tor project's onion services documentation. The anonymous VPS page and the full OPSEC checklist roll the cluster into product and checklist form.

What keeps the cluster honest is its ceiling page: the limits of no-KYC anonymity states what no plan can do — upstream exchange records, your own operational slips, the law of the rack — and the cluster's guides repeat that framing instead of drifting into fantasy. A buyer who reads only the optimistic half of this cluster ends up surprised by exactly the records the ceiling page lists; read the ceilings first, then the mechanics.

You can audit your own three layers the same way the cluster teaches: Is a VPS anonymous? gives you the split, and the domain guides give you the fix for the layer most buyers get wrong. If your WHOIS shows a legal name, no checkout will repair it; if the RDAP answer mirrors it and your NS records point at a registrar that knows everything about you, the box's short file will not matter. Read the ceiling page last and you will find the cluster has told you the truth twice — once optimistically, once not.

The typical mistake is treating the cluster as a product feature: buying anonymity as if it shipped with the box. It ships as a division of records, and the guides are the audit procedure for your third of them. The next cluster covers the decision that sits underneath all of them — which country's law the disk wakes up under.

The jurisdiction cluster

Entry page: choosing a jurisdiction, which ranks forty locations by latency, retention posture and legal process instead of by brochure adjectives. Its core method transfers to every other page here — pick the threat model first, the flag second: Amsterdam answers milliseconds, Reykjavik answers speech, Zurich answers process. The jurisdiction hub carries the location table with each site's governing law.

The cluster's legal explainers separate commerce from content: is offshore hosting legal? walks why renting abroad is ordinary cross-border commerce while content answers to its own law, and jurisdictions and DMCA covers how copyright process is treated at flags where US templates arrive as mail, not orders. The 14 Eyes explainer defines the intelligence-sharing alliances buyers keep asking about, and the comparison pages — best privacy jurisdictions, outside the 14 Eyes, offshore VPS — turn the theory into product tables.

The facts that anchor the cluster: one list price covers all forty locations, with published premiums only where scarcity is real — Iceland and Norway +20%, Switzerland +35%, Luxembourg, Cyprus and Panama +15% — and the billing contract sits with WESTFALL AND CO in Nevis while the disks sit under local law in named cities. Those are two separate layers, and the cluster's guides never let them blur: the contract governs commerce, the facility country governs the disks.

You can feel the two-layers distinction in the prices themselves: the flag you pick costs you nothing extra at thirty-four of forty sites, and the premiums that exist are published — +20%, +35%, +15% — so the law question you actually care about is never hidden from you. What the flag does change is process: who must ask before your disks are read, how fast they must answer, and whether the templates arriving from abroad are orders or mail. You choose that once, deliberately; everything else about the box you can change next week.

The typical mistake is flag-shopping before threat-modelling, which produces a box in a famous privacy country that still runs a real-name domain and pays from a KYC exchange — the flag did nothing because the leak lived elsewhere. Choose the law last, after the payment and publication layers are quiet. The next cluster assumes both are settled and asks what to actually run on the disk.

The self-hosting cluster

This cluster is the build library: one guide per application, each with sizing against the plan ladder, the install path, and the traps that turn up in the first week. The canonical example is self-hosting Nextcloud — Warden at $19.00 list, $15.20 annual-eff as the preview-generation floor, the official manual's install chapter, snapshot-plus-Borg backups, and the storage tier for terabyte archives. The pattern repeats across the cluster, grounded each time in primary docs like the Nextcloud admin manual.

Network and identity infrastructure: self-hosting WireGuard replaces a subscription with an endpoint you control, and the VPN versus subscription comparison prices that trade honestly. Matrix on Synapse and the Mastodon guide cover federated social stacks, while the mail server guide walks the hardest self-host in the book — deliverability, PTR records, reputation — without pretending it is a weekend job.

Money and monitoring: BTCPay Server puts payment processing on your own rail, with the Bitcoin Core project as the reference implementation underneath; running a full node sizes the chain's disk and RAM honestly; Uptime Kuma is the smallest useful build in the catalog and the recommended first project. The Gitea guide covers private repositories, and mail's protocol layer is specified in RFC 5321 for readers who want the standard under the how-to.

You can climb the builds in difficulty order and each one teaches what the next assumes: Uptime Kuma shows you the deploy-configure-forget cycle on the cheapest rung, Nextcloud adds databases, previews and backups you must schedule, and mail hands you the reputation grind that RFC 5321 only begins to describe. When you reach BTCPay, you will be running infrastructure that other people's money depends on, which is why the cluster made you earn it first with bitcoind and a node you have pruned with prune at least once.

The cluster-wide rule is root-only: no managed layer exists at any tier, so every guide treats patching, backups and application security as operator duties and says so in its limits section. The typical mistake is starting with mail — the one application whose success depends on IP reputation built over months — instead of gaining the rhythm on Kuma or Nextcloud first. When the builds outgrow the rungs, the hardware cluster is next.

The hardware and product cluster

Entry page: VPS versus dedicated, which reduces the upgrade question to four measurable signals — CPU steal, resident memory, sustained disk queues, and the need for IPMI — instead of vibes. The plan ladder it prices: Scout, 1 vCPU and 2 GB ECC, at $5.49 list or $3.00 annual-eff; Sentry at $7.50/$6.00; Ranger at $12.50/$10.00; Warden at $19.00/$15.20; Vanguard at $26.50/$21.20; Sentinel, 12 vCPU and 32 GB, at $33.50/$26.80. Metal starts at Shield, a Xeon E-2388G with IPMI, at $38.50 list, $30.80 annual-eff, and runs to the dual-EPYC Citadel at $298.50/$238.80.

The foundations pages explain why the ladder looks the way it does: KVM versus OpenVZ covers the virtualization boundary that makes nested workloads and custom kernels possible, and shared hosting versus VPS marks the line where a slice becomes the right purchase. Storage is its own product line — the storage page lists Depot tiers from $30.00 to $70.00 list for 1–5 TB, $24.00 per terabyte on the annual term — and the anonymous storage guide pairs it with the privacy cluster.

Security and resilience complete the set: the hardening checklist is the first-hour drill for any new box, the full-disk encryption guide covers data at rest, and backup and restore rehearses the snapshot-plus-offsite drill until a restore is a tested fact. The VPS product page and the dedicated overview keep every spec beside its price for the moments the guides send you shopping.

You can read the whole ladder as four numbers you check on your own box before you shop: steal, resident memory, disk queue, and whether you need a console you cannot reach over SSH. The comparison pages turn those into tiers — 2 GB ECC at the bottom, 16 GB DDR5 where previews live, IPMI where metal begins — and every price beside them is list-and-annual side by side. If you measure first, you will buy once; if you skip the measurements, no table can save you from the rung you did not need. Bring a week of your own numbers and the tables will agree with you; arrive without them and you are shopping on hope.

The cluster's typical mistake is ladder anxiety: buying the top rung first, or upgrading on a hunch instead of a metric. The guides here all push the same discipline — measure for a week, move one rung, measure again — and the product pages make the move cost one click and a reboot. Before shopping, though, most people have operational questions, which is the ops desk cluster's territory.

The ops desk cluster

This cluster is the day-two library: everything that happens after the invoice credits. Entry pages: opening a support ticket — which wants money on the balance, a subject naming the affected object, and the invoice code or IP so a human can reproduce the case — and the crypto VPS FAQ, which absorbs the questions that do not deserve a full page. Tickets in English get the fastest replies; panel actions like reboots, reinstalls and rDNS changes are self-serve and never need a ticket at all.

Network operations: the rDNS and PTR guide walks setting the reverse record — the pointer that mail deliverability and reputation systems read first, defined for DNS in RFC 1035 and checkable with dig -x. DDoS and abuse tickets covers the two inbox flows an operator eventually meets: filtering on the platform side, and third-party abuse mail that routes to the abuse address rather than the support queue — mixing the two is the classic delay. The acceptable use policy is the shortlist behind those abuse mails.

Lifecycle operations round out the cluster: migrating without downtime rehearses the rsync-and-cutover drill between boxes, and DDoS protection explained covers what the included filtering does and does not absorb. The encryption guide and the hardening checklist cross-link from here because most incidents trace back to first-hour shortcuts rather than exotic attacks.

You can make your own 2 a.m. easier by rehearsing the pages you will need in daylight once: set the PTR record on a box that is not in production, run dig -x until the answer looks right, and open one harmless test ticket so you have seen the form yourself. When the real incident arrives you will be working from memory of the page instead of a description of it, and the difference is minutes. Every guide in this cluster ends in an action for exactly that reason — reading about the drill is not the drill.

The cluster's typical mistake is ticket hygiene: vague subjects, missing invoice codes, abuse reports pasted into support threads. The guides here exist to make the first ticket as efficient as the hundredth — named object, reproducible symptom, one thread per case. With all six clusters mapped, the only remaining question is where you should start, which is what the next section answers by task.

Picking a starting point by task

The map above is by cluster; most readers arrive by task. The shortest honest routes, from the commonest starting points:

• I have not bought anything yet. Read the crypto payment flow guide once — every later page assumes its mechanics, from exact-amount matching to single-use addresses.
• I want to pay with Telegram money. Go straight to buy a VPS with GRAM (TON) for the UQ address, the Jetton trap, and the one-transfer rule.
• I need files, calendars and share links. The Nextcloud guide is the build page, and its storage-tier section answers the photo-archive question before it becomes a support ticket.
• I want the smallest possible file about me. Start at the minimum-data checkout guide, then read is a VPS anonymous? for the layers the checkout does not control.
• My box is outgrowing its slice. The VPS versus dedicated decision page, then the storage line if the growth is bytes rather than cycles.
• Something is under attack or flagged. DDoS and abuse tickets covers both flows, and the AUP page states the shortlist behind third-party reports.
• I want a VPN endpoint I own. Self-hosting WireGuard, with the subscription comparison for the honest price math.

Treat the list as routes, not assignments: if your task is the archive row, the storage page will hand you the 1 TB figure, the sizing rules will hand you a rung, and the −20% annual math you watched decides whether the rung bills monthly or yearly. That loop is the base working as designed — you enter with a task, you leave with a decision, and the pages in between exist to carry you between the two. If a route dead-ends on you, the ops desk cluster is where the missing page belongs, and the ticket form is where you can say so. When you fill that form, name the object the way the ops cluster teaches — the invoice code, the IP, the symptom you saw — and you will get the fastest answer the queue can give you.

Two habits make the task list stick. Buy before you binge: a Scout slice at $5.49 list — $3.00 annual-eff — turns ten guide pages into one evening of practice on a real box, and practice is what the pages are for. And finish pages by their action: every guide here ends with something to run, and the reading that stops at the last heading has captured none of the value.

If the task is not on the list, the cluster sections above are the fallback: find the cluster that names your problem, and its entry page is one hop from the answer. The final section does the same service for the whole base — the order to read it if reading is genuinely the task.

The knowledge base, in the order to read it

For readers who want the full tour, this is the order that builds fastest on itself, and it mirrors how the product actually unfolds. First, the payment flow guide, because every invoice on any page of this site runs through its mechanics — exact amounts, single-use addresses, confirmation depths. Second, no-KYC hosting explained, which inventories the file the host keeps and the records that stay upstream; it is the base's load-bearing definition.

Third, is a VPS anonymous?, which extends that inventory to the payment chain and the publication layer — the two thirds you control. Fourth, the jurisdiction pair: choosing a jurisdiction for the method, then is offshore hosting legal? for the boundary between commerce and content. At this point you can buy a box deliberately: you know what the invoice writes, what the file holds, and what the flag changes.

Fifth, the product cluster in ladder order: VPS versus dedicated, then KVM versus OpenVZ if the virtualization question is live, then the storage page when the workload counts in terabytes. Sixth, the first build: Nextcloud or Uptime Kuma for the rhythm of install, secure, back up — with the hardening checklist and the backup drill as the two companions no build skips.

Seventh, the ops desk: rDNS and PTR, tickets, DDoS and abuse — the pages you will actually need at 2 a.m., read in daylight once so they are familiar at 2 a.m. Eighth, back to the anonymity cluster's ceiling page, the limits of no-KYC anonymity, which reads differently once you have operated a box and closes the loop this hub opened.

Two of the nine steps you can compress if your evening is short: the payment pair and the anonymity pair overlap at the invoice, so reading the flow guide and no-KYC explained back to back costs you one context switch instead of two — the invoice fields and the 24 h metadata window appear in both. Do not compress the middle, though: the product cluster is where you decide what to buy, and decisions you rush there you will pay for every month after. If you keep the order, you will notice the base has stopped explaining and started confirming, which is how you know the reading is done. If you finish the order tonight, put the FAQ page and the limits page in your bookmarks, because they are the two you will want when a question arrives that no cluster page was sized to answer.

Nine clusters, one pass, and the base is installed in your head in roughly the time one guide's worth of practice takes in a terminal. After that, this page's job is done: the hub is a map, maps are for the first journeys, and every guide here was written to be the last page you needed — not the next one.