Self-host BTCPay Server on a VPS

The pitch is usually “no fees”, which is the least interesting part of it. Four things change, and only one of them is about money:

• Nobody holds your funds in transit. A hosted processor receives the customer’s payment into its own wallet and credits you afterwards. That gap is where holds, reviews and freezes happen. BTCPay never receives anything: the customer pays an address derived from your key, and the coins are yours from the first confirmation.
• Nobody asks who you are. Onboarding to a processor is an identity process with a bank at the end of it. Installing software is not. That is the entire difference, and it is why the answer to “how do I take crypto without KYC” is always “run the processor yourself”.
• The cost stops scaling with you. A percentage is charged forever and grows with success. A VPS and a domain cost the same in a good month and a bad one.
• You inherit the operational work. Uptime, updates, backups, and being the person who gets the message when a customer says the invoice never settled. This is the real price, and it is paid in attention rather than in currency.

What you do not get is the one thing processors are genuinely good at: turning coins into bank-account money on your behalf. BTCPay holds what it was paid, in the coin it was paid in. Conversion, invoicing in fiat, accounting exports a tax authority recognises — all separate problems, and most of the ways to solve them reintroduce exactly the identified counterparty you just removed. Work out which half of that trade you actually wanted before you build anything.

The name is misleading in a useful way. “BTCPay Server” is not one program; the standard deployment is a small fleet of containers that come up together, and knowing which is which is the difference between sizing this correctly and guessing at it:

• Bitcoin Core. A real full node, validating from genesis. This is the component that costs you disk, most of the first day, and nearly all of the memory. Everything else is comparatively free.
• NBXplorer. The indexer between Core and BTCPay. You give it extended public keys; it tracks the derived addresses and tells BTCPay when money lands. It is also the piece that cares about pruning, for reasons the failure-modes section comes back to.
• BTCPay Server itself. The application: stores, invoices, the checkout page, the point of sale, webhooks, the Greenfield API. Modest by comparison — a few hundred megabytes of memory.
• PostgreSQL. Invoices, stores, settings, users, API keys. Small, and the thing your backups are actually for.
• nginx with automatic certificates. A reverse proxy plus a companion that issues and renews a certificate for your hostname. This is why ports 80 and 443 have to be genuinely reachable from the internet.
• Optionally a Lightning node (Core Lightning or LND) and a Monero daemon with a wallet RPC beside it — each bringing its own chain and its own appetite for disk.

So the sizing question is never “how big does BTCPay need to be”. It is “how much chain am I keeping, and how many chains”. Answer that and the plan chooses itself.

The project documents 2 GB of RAM with swap as a minimum and 4 GB as the recommendation, and the gap between those two numbers is the gap between an install that technically completes and one you are willing to point customers at. An application runtime, PostgreSQL and a syncing bitcoind sharing 2 GB will finish — slowly, with the swap file doing work it should not have to.

Disk is set by how hard you prune, and the deployment exposes that as a fragment you pass to the installer. The family runs roughly opt-save-storage at about 100 GB of block files, -s at about 50 GB, -xs at about 25 GB and -xxs at about 5 GB. That last one is a trap for anything meant to survive: it keeps so little history that ordinary maintenance starts failing. For a store, -s or -xs is the sensible band.

Concrete numbers from the grid, because “it depends” is not an answer:

• Bitcoin only, pruned, one store — Scout, 2 vCPU / 4 GB / 70 GB NVMe, $9.00/mo. The honest floor, and the right answer for most readers.
• Bitcoin and Lightning — Runner, 3 vCPU / 6 GB / 100 GB, $14.00/mo. A Lightning daemon is light on disk and insistent about staying online; the headroom is for the node underneath it.
• Bitcoin, Lightning and Monero — Alpha, 6 vCPU / 12 GB / 200 GB, $28.00/mo. A pruned Monero chain is around 85 GB by itself, so two chains and two indexers is where 8 GB gets thin. Hunter (4 vCPU / 8 GB / 140 GB, $19.00/mo) fits only if Bitcoin stays pruned hard and stays that way.
• An unpruned node behind the store — a different project with a different bill. The full-node guide has those numbers, and they start at Fenrir.

CPU matters exactly once. Signature verification during the initial block download parallelises, so two to four vCPU turns the first sync from days into about a day, then goes back to idling. Bandwidth is a one-time cost of the whole chain, on a 1 Gbps port with unlimited traffic and no overage invoice at the end of the month. Latency is irrelevant to a payment processor, so choose the location for jurisdiction rather than for milliseconds — Amsterdam, Paris, Bucharest and Sofia all sit at base price.

A short list, and one item on it is not technical.

• A domain, with an A record already pointing at the server. The certificate is issued over HTTP against that hostname, so DNS has to resolve before the installer runs, not during. A subdomain such as pay.example.com is the normal shape.
• Ports 80 and 443 open to the world. Port 80 is not optional even though nothing useful serves on it afterwards; the certificate challenge needs it.
• Debian 13 from the template library, on a machine that has already had the ten-minute hardening pass. Do it first — it is much harder to do politely once a stack is running.
• A wallet you already control, and its extended public key. Sparrow, Electrum or a hardware wallet. Have it in hand before you install, so you are never tempted to let the server generate one for you.
• An email address for the certificate authority. It receives expiry warnings and nothing else.
• A decision about pruning, made now. Changing your mind later means resyncing the chain from scratch, which is a day you will not enjoy spending twice.

Almost every bad outcome with a self-hosted processor traces back to a single decision made early and casually: letting the server hold something that can spend. It is worth being explicit about the three cases, because they are genuinely different.

• On-chain Bitcoin: watch-only, always. BTCPay holds an extended public key and nothing else. If the box is compromised, the attacker learns what you were paid and can change where future invoices point — a real attack, and the reason to re-check your store’s wallet after any incident — but cannot touch a coin already received.
• Lightning: hot by definition. Channels are funded with coins the server can spend, because that is what a channel is. This is the deliberate exception, and the section above sizes it.
• Monero: view-only, structurally. The private view key reveals every incoming payment and authorises none of them. There is no equivalent on the Bitcoin side.

The one feature that breaks this model on purpose is Payjoin. It lets your server contribute an input to the customer’s transaction, which meaningfully degrades the common-input heuristic chain analysis leans on and is a genuine privacy gain for both parties — but a receiver has to be able to sign, so it needs a hot wallet inside BTCPay. That is a real trade rather than a free feature. Take it knowingly, and fund it the way you fund the Lightning wallet: with an amount, not with everything.

And if you let the setup wizard generate the store wallet because it was the fastest path through: write down the seed it showed you, verify it in an offline wallet, then plan the migration to a watch-only setup. A seed that has ever been on an internet-facing server is a seed with a countdown running on it.

Sort the state by what it would take to recreate, because the answers are very different:

• The chain. Not a backup problem. It is public data and it resyncs, slowly and for free. Never back it up.
• The database. Invoices, stores, settings, users, API keys. This is the real backup, it is small, and losing it costs you the accounting record of every sale — not the money, but the paperwork.
• Your on-chain wallet. Already safe, because the key was never here. That is the payoff for step five.
• Lightning channel state. The one that bites. A static channel backup lets you recover the funds in your channels after a total loss by forcing them closed; it does not restore the channels, and it is worthless if it is stale. It changes every time a channel opens or closes, so it belongs in an automated off-site copy rather than a folder you remember quarterly.
• The Monero view-only wallet. Rebuildable from the address and view key you still hold offline. Back up those and treat the wallet files as a cache.

The deployment ships helpers that do this correctly:

btcpay-backup.sh    # stops the stack, dumps Postgres, tars the config, restarts
btcpay-restore.sh   # puts one of those archives back

That pause is the point — a hot copy of a running database can restore into something interesting. Encrypt whatever leaves the machine, and remember that the weekly snapshot included with every plan is a convenience rather than a backup: a snapshot lives with the thing it is protecting.

In rough order of how often they cost somebody an evening:

• The certificate never issues. Nine times in ten the A record was created after the installer ran, or port 80 is filtered. Fix DNS, confirm the name resolves from somewhere that is not your own laptop, then re-run the setup script. Retrying blindly against the certificate authority earns a rate limit and a week of waiting, so change something between attempts.
• An imported extended key with history shows no balance. This is the pruning trap. The indexer finds new payments by watching new blocks, but reconstructing an existing wallet’s past means reading blocks a pruned node has deleted. Use a fresh account for the store and the problem does not exist; if you must import history, you need an unpruned node and a rescan.
• “The customer paid and the invoice is still open.” Usually underpayment by the sending wallet’s fee, an invoice that expired while the payment sat unconfirmed, or a confirmation policy stricter than you remember choosing. All three are settings, and all three are why you test with your own money first.
• The node quietly falls behind. A stalled bitcoind hands out addresses and misses payments without complaining. Compare your block height against any public source on a timer and alert on the gap; this is not something to learn from a customer.
• An update at the wrong moment. btcpay-update.sh is well behaved, but it restarts everything. Run it deliberately, never automatically, and never during a sale.
• The address acquires a reputation. A checkout page on a blocklisted IPv4 is a checkout page some corporate networks and mail filters quietly refuse. Every plan here ships a dedicated address with no history, and it is worth checking it before you print the domain on anything.

The software removes a counterparty. It does not remove the rest of the surface, and being honest about that is more useful than another list of features.

The domain is the weak point. It is registered somewhere, it resolves publicly, and it is the first thing anyone looks at. A processor self-hosted on a hostname registered in your own name at a registrar in your own country has moved the money out of a third party’s hands and left the identity precisely where it was. If that matters for what you sell, the registrar deserves at least as much thought as the host.

The jurisdiction is a real variable. Where the machine sits decides whose court order reaches it and how much process stands in the way. That is friction and distance, not immunity — a point the offshore hosting entry makes at length, and worth reading before choosing a flag over a network.

The account is the last link. Renting the server with an email address and paying in Monero means no card statement ties the checkout page to a bank — a strange thing to overlook while building a system whose entire point is not needing one. Every plan here is no-KYC by default, and every location ships a dedicated clean IPv4 with custom reverse DNS.

And the boundary is stated rather than implied. Nodes, processors and stores are ordinary infrastructure and welcome here; the acceptable-use policy is short, public, and has a floor under it. Whether you need a licence to take payments is a question about what you sell and where you are, not about the software — and it is a question for someone qualified, not for a hosting guide.