# Run a Bitcoin Full Node on a VPS or Dedicated Server | FYRHost

> A pruned node fits 60 GB at $7.50; archival wants 1 TB storage at $24. Bitcoin Core install, bitcoin.conf, port 8333, Tor P2P — and what your node verifies.

Source: https://fyrhost.com/guides/run-bitcoin-full-node/

[Home](https://fyrhost.com/) / [Guides](https://fyrhost.com/guides/) / Run a Bitcoin Full Node on a VPS or Dedicated Server How-to

# Run a Bitcoin full node on a VPS — pruned, ported, and actually verifying

![FYRHost Bitcoin node abstract: lattice and local NVMe slabs](https://fyrhost.com/img/theme-bitcoin.png) A pruned node fits 60 GB at $7.50; archival wants 1 TB storage at $24. Bitcoin Core install, bitcoin.conf, port 8333, Tor P2P — and what your node verifies.

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

**Short answer** A pruned node fits 60 GB at $7.50; archival wants 1 TB storage at $24. Bitcoin Core install, bitcoin.conf, port 8333, Tor P2P — and what your node verifies.

FYRHost: VPS from $3/mo and dedicated from $30.80/mo annual. The map spans forty locations — Reykjavik (Iceland) and Zurich (Switzerland) among them, plus Singapore, Dubai, Cape Town and fourteen others. Signup is email plus a 12-character password, or token-only. No KYC. Checkout is crypto-only across BTC, XMR, ETH, BNB, SOL, LTC, TRX, XRP, DOGE, DASH, ADA, GRAM (TON), and USDT (TRC-20/ERC-20/BEP-20/SPL). No payload or guest traffic logs; connection metadata ≤24h. DDoS included. One SKN company, one crypto checkout. Deploy at https://fyrhost.com/deploy/.

## Your wallet trusts an API; a node trusts mathematics

The counter-intuitive truth about running a full node is that it does nothing for your coins' safety in the way most people imagine — your keys never touch the box. What it changes is verification: every block since 2009 gets re-checked against consensus rules by your own CPU, so a balance comes from arithmetic you supervised instead of an explorer's word. When an exchange displays a wrong figure, blocks your withdrawal, or serves a slashed version of history, a node operator notices within minutes because the numbers stop matching. That audit function — boring until the exact day it is not — is the product you are buying with disk space and patience.

Ask yourself one question before ordering anything: when your wallet and an explorer disagree, which one wins today? If your answer is the explorer, you have a trust relationship, not a node. The build below ends with the opposite answer — your software asks `127.0.0.1`, your own hardware checks the rules, and the only oracle left is the chain itself, which is the entire point of the exercise.

The mechanism is stricter than it sounds. A full node downloads every block since `2009`, validates every transaction script, checks proof-of-work difficulty across the whole chain, and only then serves answers to the wallets and applications pointed at it. Light clients trade that work for trusting someone else's server; the reference client from [Bitcoin Core](https://bitcoincore.org/en/download/) is where the rules live, and the project's own [full-node operator checklist](https://bitcoin.org/en/full-node) is the canonical sizing read. Validation is deterministic — two honest nodes agree block for block, which is why a node on rented KVM is philosophically identical to one under your desk.

Where it breaks: the API shortcut dressed up as a node. Software that merely queries someone else's RPC endpoint gives you the vocabulary of self-sovereignty with none of the verification — if you cannot point your wallet at `127.0.0.1` (or your own box over an SSH tunnel) and watch it reject a bad chain, you do not yet have a node. The rest of this guide is the shortest honest path to that state: pick a disk size, install the client, open one port, and read four health numbers a week.

VPS from $3* (fund $50+), storage 1–5 TB NVMe from $24/mo annual-eff, dedicated with IPMI from $30.80/mo. Crypto invoice, no KYC.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)

## Prune, archival, or in between: pick by disk, not faith

The sizing folklore says a node needs terabytes; the mechanism says otherwise. Pruning keeps full validation while throwing away old block files after they are spent on verification — the chainstate that answers every balance query stays complete, only the historical raw blocks thin out. `-prune=550` is the minimum floor (values are MiB), and at that setting a node retains roughly `25 GB` of data on disk. Every consensus rule still gets checked; what you lose is the ability to re-serve ancient blocks to other peers and to run an index that scans all history.

The three honest tiers line up like this. Pruned-and-done: `prune=550` on any modern disk, verification identical to archival, wallet support intact — this is the right answer for most people, and the [operating modes reference](https://developer.bitcoin.org/devguide/operating_modes.html) documents exactly which RPC calls a pruned node declines. Middle ground: a deeper prune of a few hundred GB, chosen when you want more block serving for peers without archival ambitions. Archival: everything since the genesis block on disk, `700 GB` and climbing, justified mainly by Lightning routing nodes, explorers and indexers that must answer questions about old blocks on demand.

Where it breaks: turning pruning on after years of archival operation, or expecting `txindex` to coexist with it. Pruning and a full transaction index are mutually exclusive — the index needs every raw block on disk forever, which is the definition of what pruning deletes — and the client will refuse the combination rather than corrupt itself. Decide the mode before the initial block download, because the IBD is where your disk choice either pays off or hurts.

Test your own answer before you commit disk: if you cannot name the query you would need old blocks for, you are buying archival capacity to solve a problem you do not have. Pruned-and-done is the honest default; the deeper modes are upgrades you can choose later, with data in front of you instead of vibes.

That decision — disk class — is exactly where rented infrastructure beats the spare laptop in a closet, and the next section runs the numbers on why storage, not CPU, is the whole sizing question.

## Initial block download is a storage benchmark

Ask a room of node operators what limits the initial block download and the CPU people lose: IBD is overwhelmingly a storage and RAM choreography. The client pulls blocks from peers, decompresses and validates them, then rewrites chainstate in random-access patterns that torture spinning rust and glide on NVMe. On a local NVMe volume the whole sync measures in hours; the same sync pointed at a network share or a SATA spinning disk multiplies into days, because the bottleneck never leaves the disk queue. This is the one setup mistake that no amount of later tuning undoes.

Concretely, on this catalog the arithmetic is short. A pruned node holding roughly `25 GB` of chainstate plus mempool headroom fits Sentry — 2 vCPU, 4 GB ECC, `60 GB` NVMe — at $7.50 list, $6.00 on the annual term, with room to spare for logs and a Lightning instance later. A deeper prune past 100 GB steps up to Ranger's `120 GB`. An archival node at `700 GB` and climbing belongs on the [storage line](https://fyrhost.com/storage/), where 1 TB NVMe lists at $24 on the annual term and the ladder runs to 5 TB. RAM helps IBD too: raising `dbcache` to a few gigabytes holds more of the UTXO set in memory between flushes, and 4 GB plans tolerate `dbcache=2500` comfortably.

Where it breaks: buying bandwidth and CPUs to fix a disk problem. Peer count barely notices geography and sync speed barely notices clock speed, while the wrong storage class punishes every single minute of the download. The second classic error is syncing against an ephemeral volume or a container overlay — chainstate files `blocks/` and `chainstate/` must live on persistent local NVMe, or every restart quietly restarts the pilgrimage.

Run your own arithmetic before the order: count your retention floor, add mempool headroom and logs, and leave a third of the disk empty — the sync you are protecting is your own, and a chainstate volume that fills mid-IBD costs more patience than the storage upgrade ever would.

Disk chosen, the install itself is twenty minutes of copy-paste — the next section walks it on a minimal Debian box, verification hashes included.

## Install Bitcoin Core on a minimal Debian box

Install from the official binary rather than a distribution package when you want current releases and deterministic behavior across rebuilds. The flow from [bitcoincore.org](https://bitcoincore.org/en/download/) is four commands long: fetch the tar.gz archive for x86_64 Linux, fetch the SHA256SUMS and SHA256SUMS.asc files beside it, verify the archive hash with `sha256sum --ignore-missing -c SHA256SUMS`, and only then unpack. The signature check against the release maintainers' keys is the step people skip and the one step that makes everything else meaningful — a checksum you downloaded from the same place as the binary proves nothing about the binary.

On the box itself the sequence stays boring, which is the point. Unpack with `tar -xzf bitcoin-*.tar.gz`, install the two binaries into `/usr/local/bin` with `install -m 0755 -o root -g root bitcoin-*/bin/{bitcoind,bitcoin-cli} /usr/local/bin/`, and confirm the client talks: bitcoind -version. Run it once manually as your service user to create the data directory at ~/.bitcoin/, then stop it and write the real configuration before the initial block download starts — re-planning mid-IBD wastes the sync. The hardened-session basics live in the [hardening checklist](https://fyrhost.com/guides/vps-security-hardening-checklist/); do that pass the same hour, not someday.

Where it breaks: running bitcoind as root. The node does not need privileged ports — `8333` is above 1024 — so a root-owned chainstate is pure liability with zero benefit. The second failure is process management by nohup and memory: an IBD is a multi-hour workload, and a dropped SSH session should not be a dropped sync. A small systemd unit (or a [crontab(5)](https://man7.org/linux/man-pages/man5/crontab.5.html) `@reboot` entry as the minimal variant) turns the node into infrastructure that survives reboots unattended.

Do the verification step in the order printed, not from memory: hash first, then signature, then unpack — the sequence exists so a tampered archive fails at the cheapest step, and so you learn the habit once on a server instead of learning its absence later on a wallet machine. Ten minutes here buys you a reproducible install you can re-run on any future box without re-deciding anything.

Binaries verified and the daemon owned by a service user, the file that decides everything else is about thirty lines long — `bitcoin.conf` is next.

## bitcoin.conf: the lines that decide behavior

One file at `~/.bitcoin/bitcoin.conf` separates a node that behaves from a node that merely runs. The pruned-and-serving baseline reads: `server=1` to switch the RPC interface on, `prune=550` to keep the disk at the retention floor, `dbcache=2500` to spend the plan's spare RAM on sync speed, `disablewallet=1` when the box verifies but never signs — a pure validation node has no business holding wallet keys, and the [RPC reference](https://developer.bitcoin.org/reference/rpc/index.html) shows how much attack surface that one line deletes. Add listen=1 to accept inbound peers and rpcbind on the loopback address with its matching allowlist to keep the RPC listener off the public interface entirely.

The mechanism worth internalizing is that these are not preferences sprinkled on top — each one is a lever on a real resource. dbcache trades RAM for IBD wall time; prune depth trades historical block serving for disk; script-verification parallelism controls how many cores validation uses; connection and upload caps (in MiB per day) shape how good a citizen your node is to the rest of the network. A pruned node should still upload recent blocks to peers — the network's health is the aggregate of its operators' generosity — which is why listen plus a sane upload cap beats a leeching silent node on every axis except guilt.

Where it breaks: cargo-culted snippets from forum posts, the most expensive of which is `txindex=1` on a pruned node (refused, as covered) and the second-most-expensive being an RPC listener bound to all interfaces with a weak password — an internet-scan-discoverable JSON-RPC endpoint is a wallet-drain primitive, not a config typo. If another machine needs RPC, tunnel it: `ssh -L 8332:127.0.0.1:8332 user@node` gives the remote client a localhost endpoint over authenticated, encrypted transport, and the port never appears in a scan at all.

Copy the block above into your own conf with intent rather than wholesale: if you sign transactions on this box, leave the wallet enabled and add the backup discipline from the next sections; if you never sign, the disable line is the cheapest hardening you will ever apply. Ten lines, each of which you can explain to yourself — that is the whole file.

Config settled, the node needs exactly one port reachable to become infrastructure rather than a client — network exposure and the health numbers are next.

## Port 8333 and the health numbers worth watching

The whole network story is one port. Mainnet peer-to-peer traffic speaks on `8333` (testnet uses `18333`, signet `38333`), and opening it converts your node from a taker into a giver: inbound peers receive validated blocks from you, and your own view of the network diversifies beyond your outbound choices. The check that matters is not a web port-scanner but the box itself — `ss -tlnp | grep 8333` shows the listener, and `bitcoin-cli getconnectioninfo` reports inbound peers climbing above zero once the port is truly reachable end to end.

Reachability has two halves, and the firewall is the one people forget. The provider side carries no port blocks here, but the box's own filter does the last mile: an [iptables(8)](https://man7.org/linux/man-pages/man8/iptables.8.html) rule accepting tcp/8333 (or the equivalent in your firewall of choice) finishes the path. Health, meanwhile, is four RPC answers on a weekly rhythm: `getblockchaininfo` for header-versus-block parity and the initial-download flag, getnetworkinfo for version and connections, getpeerinfo for sync peer quality, `getmempoolinfo` for the fee-market weather. A node you check with four commands is a node you will actually keep.

Where it breaks: the port that passes locally and fails remotely — a cloud firewall panel, a host-level filter and bitcoind's own binding can each say yes while the packet still dies in between, so test from outside the box (`nc -vz node-ip 8333` from any second machine) before blaming the daemon. The second classic is celebrating inbound peers while the port speed throttles them: on this catalog the ceiling is the plan's port — 1 Gbps at entry, 2.5 and 10 Gbps up the ladder — and block relay traffic never meters, so the honest cost of being a good peer is zero.

Make the rhythm yours: same four commands, same day of the week, scripted if you trust yourself to read a cron mail. A node you can describe in four numbers is a node you can defend in one paragraph when something looks wrong to you — and the week you skip the check is, historically, the week the disk fills.

A reachable node publishes its IP to every peer it meets. When that alone should stay quiet, the fix is not a firewall posture but a different transport — the Tor onion setup is next.

## A Tor onion for P2P when the IP should stay quiet

Every peer connection is mutual knowledge: a node you connect to learns your IP, and an inbound-capable node advertises its address across the network. Most operators do not care — an IP running stock software leaks little — but the option to decouple the node's location from its identity belongs in every setup notebook, and Bitcoin Core carries it natively. Point the client at a local Tor SOCKS proxy with `proxy=127.0.0.1:9050`, and add `onlynet=onion` when the node should speak Tor exclusively; the client then auto-generates an onion service and registers it with the Tor daemon, which is why [the Tor Project's operator docs](https://community.torproject.org/relay/) read as useful background even for this narrow use.

The mechanism splits cleanly. Outbound anonymity needs only the proxy line — every peer connection leaves through Tor and your VPS IP never touches the peer. Inbound anonymity needs the auto-onion path: `listen=1` plus the proxy, and Bitcoin Core announces the onion address (visible in `bitcoin-cli getnetworkinfo` under `localaddresses`) instead of your IPv4, letting other nodes dial you through the network without ever learning where the box racks. Peers pay a latency tax for the indirection — milliseconds that matter not at all to a block relay that runs minutes behind the tip anyway.

Where it breaks: half-measures. Running Tor for outbound while leaving the listener enabled on a public IPv4 advertises the clearnet address to exactly the peers you were hiding from, which inverts the goal; pick one posture and configure it deliberately. The second failure is bandwidth amnesia — Tor relays your upload through volunteers' hardware, so a generous upload cap that is neighborly on clearnet becomes rude over onion, and trimming it to a few hundred MiB per day is the polite default for Tor-only nodes.

Decide the posture before the first peer connects, not after: switching from clearnet to onion-only mid-life leaves your old address in peers' tables for days, so the clean sequence is proxy configured, only-net set, then the listener enabled — one restart, one identity, no history to un-publish.

Transport settled, the last plumbing question is who else talks to your node — wallets, applications, Lightning — and through which door. RPC and the wallet split are next.

## RPC, wallets, and pointing software at your node

A node earns its keep when software uses it, and every consumer speaks the same JSON-RPC dialect on `8332`. Authentication on a stock setup is a capability file, not a password in a config: bitcoind writes `~/.bitcoin/.cookie` at startup and `bitcoin-cli` reads it automatically, which is why the local flow is just `bitcoin-cli getblockchaininfo` with zero credentials typed. Remote consumers — an Electrum server, a [Lightning](https://docs.lightning.engineering/) node, a payment processor — should ride an SSH tunnel to that localhost listener, exactly the `-L 8332` pattern from the config section; credentials then cross the network inside SSH, not inside an HTTP basic-auth header a scanner can harvest.

The wallet decision is the fork in this section. A node that only verifies wants `disablewallet=1`: smaller attack surface, less memory, nothing to steal. A node that signs — your own spending wallet — keeps the wallet enabled and gains file-level duties in exchange: `backupwallet` writes a wallet.dat copy you then move off the box with rsync or an encrypted upload, and the [backup playbook](https://fyrhost.com/guides/vps-backup-and-restore/) gives the retention pattern. The two postures are not exclusive across machines; the common pro pattern is a walletless validator that a Lightning node rides and a separate signing wallet on hardware at home.

Where it breaks: pointing a wallet at an explorer's public RPC because the tunnel felt like ceremony — that recreates the trust you built the node to remove, one API call at a time. The second classic is a signing wallet on the same box as a public-facing service: the web app and the keys share a kernel, and one vulnerable plugin later the keys belong to the plugin. Memory pressure is the quieter third: wallet rescans on 4 GB plans want `dbcache` trimmed while scanning, or the OOM killer picks bitcoind for you, usually mid-rescan; a 120 GB Ranger with 8 GB of RAM is the point where scanning, mempool and Lightning coexist without arithmetic.

All plumbing covered, the remaining risks are the four failures that fill node-support threads — disk, memory, config drift and false economy — and they close the technical half before the recap.

## The four ways a node box breaks first

Failure one is the disk filling silently. A pruned node's footprint is stable by design, but logs, a Lightning instance's channel backups, and an unwatched `debug.log` rotated by nothing will eat the headroom you left; `getmempoolinfo` plus a weekly `df -h` catches the trend, and logrotate (or the [newsyslog-style pattern](https://man.openbsd.org/newsyslog.conf) it descends from) turns the fix into a non-event. Mempool spikes do the rest: a fee-market storm balloons the mempool past a small plan's tolerance, the client evicts by fee rate, and your wallet's unconfirmed transaction can drop — annoying, recoverable, and the reason mempool headroom is a sizing input, not a luxury.

Failure two is memory arithmetic done once and never revisited. `dbcache=2500` is comfortable on 4 GB until a wallet rescan, a Lightning gossip storm and a compaction coincide; the OOM killer's choice of victim is non-negotiable and usually the process with the biggest anonymous mapping. Failure three is config drift between what you believe and what `bitcoin.conf` says — someone adds `txindex=1` in March, the client refuses at next start, and the downtime is the time spent remembering why. Failure four is false economy: syncing the IBD on a $2 box with shared-storage I/O, then paying in week three the difference in patience.

The repair patterns are short. For disk: prune deeper or move archival ambitions to real storage hardware. For memory: cap `dbcache` at roughly half of plan RAM when Lightning shares the box, and let swap exist but stay small. For drift: keep the conf in a ten-line git repo with a one-line deploy, so changes are diffs and not folklore. For the IBD economy: start on the disk class that finishes in hours — the [Bitcoin node solution matrix](https://fyrhost.com/solutions/bitcoin-node/) maps plan to chain size so the choice is arithmetic, not vibes.

Where it breaks, final form: a node nobody watches. All four failures announce themselves in RPC output a monitoring cron can read — the [Uptime Kuma guide](https://fyrhost.com/guides/self-host-uptime-kuma-no-kyc/) wires those answers into alerts in an afternoon, which converts your fourth-weekend outage into a Tuesday-morning notification.

## The node, in the order to run it

The whole build compresses into a timeline you can run in an evening. Choose the retention mode first — `prune=550` for validation-only service, a deeper prune for generosity, archival on a 1 TB storage tier only when indexes demand old blocks — because every later step inherits that disk budget. Order the box against the budget: a `60 GB` class carries the pruned floor, `120 GB` carries mid-prune, storage tiers carry archival, and the port speed behind the plan decides how good a peer you will be. Provision the box, apply the security pass, and hold the root line at zero — bitcoind runs as its own user.

Install by verifying, not by trusting: tarball plus checksums plus signature, binaries into /usr/local/bin, config written before the first sync rather than after. The config is ten lines that each trade a real resource — server, prune depth, cache size, loopback-only RPC, wallet disabled unless you sign — and the RPC door stays SSH-tunneled for every remote consumer. Open `8333` in the box's own filter, confirm reachability from a second machine, and decide the Tor posture explicitly: proxy-only, onion-only, or clearnet by intention rather than by default.

Start the IBD and let NVMe do the work — hours locally, days on shares — then establish the watch rhythm: `getblockchaininfo` parity, connection counts, mempool headroom, `df -h` trend, weekly and scripted. Point real software at the node — wallets over the tunnel, Lightning if routing is the goal — and put the [BTCPay walkthrough](https://fyrhost.com/guides/self-hosted-btcpay-server-vps/) on the reading list the day invoices enter the picture. From first command to first verified balance the path is one screen long; the discipline that keeps it running is the four-command check, and the [dedicated ladder](https://fyrhost.com/dedicated/) waits only if the workload outgrows slices — whole-core sync, IPMI, terabytes — not before.

If you keep one line from this page, keep the rhythm: the weekly four-command check is what turns a node from a project into a fixture, and it is the difference you will actually feel in month six — not the install, which you will never repeat, but the knowing, every week, that your box still agrees with the chain.

Is a pruned node really a full node? Yes — pruning changes what the node stores, never what it verifies. Every block and script gets checked against consensus rules exactly as on an archival node; only old raw block files are deleted after validation, leaving roughly 25 GB of chainstate on disk. The honest limits are served-block history and full indexes, both documented rather than hidden.

How long does the initial block download take? On local NVMe, hours — the workload is disk-bound, and plan storage class decides the answer more than CPU count. Syncing against a network share or spinning disk multiplies the wait into days, which is why chainstate belongs on the box's own NVMe from the first start, with dbcache raised to spend spare RAM on the sync.

Can Lightning run on the same box? Yes — a Lightning daemon rides bitcoind comfortably once you budget memory: cap dbcache at about half of plan RAM, keep the RPC door on localhost, and back up channel state off the box on a schedule. Routing workloads reward the faster port tiers more than the bigger CPU tiers, since block relay is bandwidth before it is arithmetic.

Does my node need a static IP or a domain? No. Outbound sync works from any address, and inbound peers dial the network rather than your identity — a stable IPv4 is a convenience for port 8333 reachability, nothing more. If the IP itself should stay unlinkable, the Tor onion posture replaces the address question with a generated onion service instead of a DNS record.

Why not just run the node at home? You can, and a home node is a fine first node. Renting buys three things the closet lacks: unmetered multi-gigabit transit that makes your node a better peer, uptime independent of your ISP's evening, and an NVMe queue that shrugs off mempool storms. The pruned floor fits a plan whose annual price is dinner — the closet remains the premium option for signing wallets, not for serving blocks.

What does the node do that my exchange wallet does not? It verifies instead of trusting. Balances come from your own re-execution of every consensus rule, not from an API's current mood; a censorship event, a wrong number or a forged history becomes visible the moment your software disagrees with the server's. The node also answers privately — wallet queries never leave the box — which is a property no third-party endpoint can sell you honestly.

## Primary sources

- [Bitcoin Core downloads and verification](https://bitcoincore.org/en/download/)
- [Bitcoin developer guide: the block chain](https://developer.bitcoin.org/devguide/block_chain.html)
- [Bitcoin.org: running a full node](https://bitcoin.org/en/full-node)

## Related guides

- [Minimum-data no-KYC checkout](https://fyrhost.com/guides/anonymous-vps-crypto-no-kyc/)
- [Buy a VPS with crypto](https://fyrhost.com/buy-vps-with-crypto/)
- [No-KYC VPS: requirements and limits](https://fyrhost.com/no-kyc-vps/)
- [Pay with Monero](https://fyrhost.com/monero-vps/)
- [Offshore VPS](https://fyrhost.com/offshore-vps/)
- [VPS vs dedicated bare-metal](https://fyrhost.com/guides/vps-vs-dedicated/)
- [Best no-KYC VPS 2026](https://fyrhost.com/best-no-kyc-vps-2026/)
- [FAQ: crypto VPS](https://fyrhost.com/guides/faq-crypto-vps/)

## More ways to pay

[Pay with Bitcoin](https://fyrhost.com/bitcoin-vps/) · [Pay with Monero](https://fyrhost.com/monero-vps/) · [Pay with USDT (TRC-20/ERC-20/SPL)](https://fyrhost.com/usdt-vps/) · [Pay with XRP](https://fyrhost.com/xrp-vps/) · [Pay with TRX](https://fyrhost.com/tron-vps/) · [Pay with Dogecoin](https://fyrhost.com/dogecoin-vps/) · [Pick the jurisdiction first](https://fyrhost.com/jurisdiction/).

## Video walkthrough

![Video: How to run a full bitcoin node](https://i.ytimg.com/vi/XwTpA_mAvqo/hqdefault.jpg) ▶ How to run a full bitcoin node — YouTube tutorial (community). The player loads from youtube-nocookie.com on click; [watch on YouTube](https://www.youtube.com/watch?v=XwTpA_mAvqo).

## Checkout facts

- **Price** VPS from $3/mo. Dedicated from $30.80/mo.
- **Identity** No KYC. Token-only (no email) or email plus a 12-character password. No passport, phone, or card.
- **Payment** Nineteen ways to settle, none of them a card: XMR and BTC lead, ETH, SOL, LTC, BNB and TRX follow, then XRP, DOGE, DASH and ADA, GRAM (TON) for Telegram-adjacent rails, and USDT on seven networks — TRC-20, ERC-20, BEP-20, SPL, Polygon, Arbitrum, Optimism. Live-rate invoice.
- **Logs** No payload / no guest traffic logs. Billing and panel actions retained. Connection metadata ≤24h.
- **Platform** KVM on ECC and local NVMe. DDoS filtering included. Facilities in 40 cities across four continents — the locations table lists each one's tier, uplink and governing law. Need Iceland or Switzerland plus no KYC? Those two carry a published premium (+20% / +35%); every other flag stays at base list. Pay BTC, USDT, XMR, BNB, XRP, GRAM (TON) or 10 more. Open deploy to pick a plan.

## Ready to launch?

Build the box — VPS, storage or bare metal — create the password, pay the invoice that follows.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)[Dedicated](https://fyrhost.com/dedicated/)