Self-Hosting BTCPay Server on a No-KYC VPS: Specs, Storage and Sync Reality

If you want to accept Bitcoin without handing a payment processor your identity, bank details and customer list, BTCPay Server on your own VPS is the realistic path — but it is not a €4/month project. Plan on 2 vCPU and 4 GB RAM as a comfortable floor, 120–240 GB of NVMe if you run a pruned Bitcoin node, and 600 GB+ of inbound traffic during the initial blockchain sync. Everything else in this article is about why those numbers are what they are, and how to pick a plan that won't run out of disk six months in.

The short answer: what BTCPay actually needs

BTCPay Server isn't one program. The standard Docker deployment brings up a stack: a Bitcoin Core node, NBXplorer (the block indexer that watches your addresses), a PostgreSQL database, the BTCPay web app itself, and usually nginx with Let's Encrypt in front. Optionally a Lightning node on top.

The web app, database and indexer are all small — a few hundred megabytes of RAM and a handful of gigabytes of disk between them. Bitcoin Core is what drives the hardware requirements.

A workable baseline:

• CPU: 2 vCPU. Initial sync is CPU-bound for signature validation; after that, usage drops to near-idle.
• RAM: 4 GB is the realistic minimum for a smooth install. BTCPay's own documentation treats 2 GB as the absolute floor, and people do run it there with swap — but you're one plugin or one Postgres vacuum away from an OOM kill.
• Disk: 100–120 GB with aggressive pruning, 700 GB+ for an unpruned archival node. NVMe matters here, not just capacity — initial block download on spinning disks or network storage is painful.
• Bandwidth: the chain is downloaded once in full even if you prune afterwards.

Why storage is the hard part

The full Bitcoin blockchain is past 600 GB and grows every year. No affordable VPS tier makes that comfortable, so most self-hosters set Bitcoin Core's prune option: the node validates every block from genesis, then discards old block data and keeps only the UTXO set plus a rolling window. BTCPay's Docker setup exposes this directly (BTCPAYGEN_PRUNE_SIZE), commonly set to something like 100 GB.

Pruning works, and for a merchant who only cares about payments arriving from now on, it's the right call. But be honest about what you give up:

• You can't rescan the distant past. Import an xpub from a wallet you've used for years and BTCPay will only find transactions inside your prune window. Addresses you generate going forward are fine; history isn't.
• You can't serve blocks to other peers. Your node takes from the network and gives nothing back. Not a problem for you, mildly antisocial for the network.
• Lightning on a pruned node is less forgiving. It's supported in current releases, but channel-related edge cases are easier to resolve with full block data. If Lightning is central to your business, budget for more disk rather than less.
• Changing the prune size later usually means resyncing. Pick a number you can live with before you start.

Against that, a 120 GB NVMe plan with a 100 GB prune target leaves very little slack for the OS, Docker images, Postgres, logs and snapshots. 240 GB is where a pruned BTCPay install stops feeling tight.

The initial sync nobody budgets for

This is the single most common surprise. Pruning saves disk, not bandwidth. Your node still downloads and validates every block ever mined — currently 600 GB+ of inbound traffic — before it discards anything. On a 2 vCPU VPS with NVMe, expect that to take somewhere between a day and several days depending on peers and dbcache settings.

Two practical consequences:

1. Check how your provider counts traffic. Bandwidth allowances on IronBalkans plans run from 1 TB on Iron 1 up to 16 TB on Iron 4. A one-time 600 GB+ download is a meaningful chunk of a 1 TB allowance and a rounding error on 8 TB. If you're unsure how inbound is treated on the plan you're eyeing, ask before you sync rather than after — and in general it's worth understanding how far your monthly bandwidth actually goes before committing.
2. Give Bitcoin Core more cache during sync. On a 4 GB box, raising dbcache to ~450 MB while syncing and lowering it afterwards shortens initial block download noticeably. On 8 GB you can be more generous.

Steady-state traffic after sync is modest: a few tens of gigabytes a month of peer-to-peer gossip, plus whatever your storefront serves.

Mapping BTCPay to no-KYC VPS plans

Using real plan specs rather than hand-waving:

Iron 1 (€3.99/mo — 1 vCPU, 1 GB RAM, 25 GB NVMe): not suitable for a Bitcoin node. It's a fine box for a BTCPay front end pointed at an external node, a store website, or a monitoring host — not for the full stack.

Iron 2 (€7.99/mo — 2 vCPU, 4 GB RAM, 60 GB NVMe): the right CPU and RAM, not enough disk for a node. Workable only if you connect BTCPay to a Bitcoin node you already run elsewhere, or if you're running a non-Bitcoin setup.

Iron 3 (€14.99/mo — 4 vCPU, 8 GB RAM, 120 GB NVMe): the realistic entry point for a self-contained pruned BTCPay install. Set the prune target around 60–80 GB rather than 100 GB so you keep headroom for Postgres growth, Docker image churn and logs. 8 GB RAM means Lightning and a couple of plugins won't fight for memory.

Iron 4 (€29.99/mo — 8 vCPU, 16 GB RAM, 240 GB NVMe): comfortable. A 150 GB prune window, Lightning, plugins, and room to add a second service without re-architecting. Still nowhere near enough for an archival node, which is fine — almost nobody needs one.

The privacy logic behind running this yourself only holds if the hosting account isn't itself an identity document. IronBalkans accounts are created with no email, name, phone or ID — a random account ID plus a recovery key — paid in Monero, Bitcoin or Litecoin, with the server live in under a minute once payment confirms. That matters specifically here: a merchant who self-hosts to avoid a processor's KYC file, then signs up for the VPS with a verified card, has moved the identity record rather than removed it. If you want the full plan-by-plan reasoning for other workloads too, the no-KYC VPS sizing guide covers it.

Beyond Bitcoin: Lightning, Monero and altcoins

Lightning (LND or Core Lightning) adds roughly 1–2 GB RAM in practice and a few gigabytes of disk, plus an operational burden: channel backups, liquidity management, and the fact that losing your channel state is a real way to lose money. Treat it as a second project, not a checkbox.

Monero support in BTCPay runs through a plugin that needs its own monerod instance. That's another 100 GB+ of chain data and another initial sync — and on a VPS it deserves its own treatment; see running a Monero node on a VPS for the setup, systemd hardening and the privacy limits of querying a node you host remotely. Realistically, Bitcoin + Monero on one box means Iron 4 territory.

Other altcoins each add a daemon and its chain. The disk arithmetic gets unpleasant fast. Decide which coins you actually need to accept.

Common mistakes

• Starting on too small a disk and resyncing twice. Resyncing costs you days and another full chain download. Size for 12 months ahead.
• Exposing everything. Only 80 and 443 should be reachable from the internet. Bitcoin RPC (8332), NBXplorer, Postgres and Lightning RPC should be bound to localhost or the Docker network only. A baseline nftables ruleset takes ten minutes and closes the most common foot-gun — note that published Docker ports can bypass naive firewall rules, so verify with an external port scan rather than trusting your config file.
• No backup of the BTCPay database and store keys. The blockchain is replaceable; your Postgres database, store configuration and any hot wallet keys are not.
• Running a hot wallet on the server. Use xpub-only watch-only wallets where possible so a server compromise can't drain funds.
• Assuming self-hosting is anonymous to buyers. Your store's domain, TLS certificate and public IP are visible. Self-hosting removes a processor from the middle; it doesn't make a public storefront private.

Pros and cons, honestly

In favour: no processor account to be frozen or closed, no third party holding your sales data, payments go to addresses only you control, no per-transaction cut, and you can accept coins a processor won't touch.

Against: you are now the operator. Updates, disk monitoring, node resyncs after a crash, Lightning liquidity and backups are your problem. Third-party BTCPay hosts exist and are cheaper to start, but they reintroduce exactly the trust and data-exposure you were trying to remove. And a self-hosted node doesn't change the law that applies to what you sell — hosting in Romania/EU means Romanian and EU rules still govern the content and commerce on the server.

FAQ

Can I run BTCPay without a full Bitcoin node? Yes — BTCPay can connect to an external node you control, which lets the BTCPay app itself live on a small VPS. You still need that node somewhere, and trusting someone else's node reintroduces a privacy and reliability dependency.

How long does the initial sync take on a VPS? Expect roughly one to several days on 2–4 vCPU with NVMe. CPU and peer quality dominate; a generous dbcache helps.

Does pruning reduce the download? No. Pruning only reduces what's kept on disk after validation. The full chain is still downloaded.

Will a 60 GB plan work if I prune to 50 GB? Technically it can boot, but you'll be managing disk pressure constantly once Postgres, Docker and logs grow. 120 GB or more is the sane choice for a self-contained install.

Is this legal to run? Running a node and accepting crypto payments for a lawful business is normal activity in the EU. Your obligations come from what you sell and where your customers are, not from the node itself.

Get started

If BTCPay is your plan, start at Iron 3 and size the prune window to leave real headroom — or go to Iron 4 if Lightning or a second coin daemon is on the roadmap. You can compare the tiers at ironbalkans.com/#pricing and have the server running in under a minute with no email, no ID and payment in XMR, BTC or LTC at ironbalkans.com/register. Sync the chain first, build the store second — the hard part is the 600 GB, not the checkout page.