# Can I run a Bitcoin node on a VPS?

> Run Bitcoin Core 32.1 on a Linux VPS: about 911 GB for a full node, pruned mode from 550 MiB, traffic figures, bitcoin.conf and LND notes. Pay in crypto.

- URL: https://vpswithcrypto.com/bitcoin-node-on-a-vps/
- Last updated: 2026-11-03
- Publisher: VPS With Crypto (https://vpswithcrypto.com)

How much disk, memory and bandwidth Bitcoin Core 32.1 needs, why a pruned node is the realistic choice on a VPS, how to install and configure it, which plan holds it, and what Lightning adds.

**Quick answer — Can I run a Bitcoin full node on a VPS?**

Yes, as a pruned node. Bitcoin Core 32.1, current on 3 November 2026, assumes 897 GB of block files plus 14 GB of chain state for a full copy, more than any VPS With Crypto plan holds. With `prune=10000` the node still verifies every block but keeps only about 10 GB of old blocks, so it fits on Kilo (2 vCPU / 4 GB / 65 GB) or Mega (2 vCPU / 6 GB / 120 GB).

## How much disk, memory and bandwidth does Bitcoin Core need?

**About 911 GB of disk for a full copy of the chain, far less when pruned, and a one-time download of the whole chain either way.** Two official sources give the figures. Bitcoin Core's own code carries the size each release assumes for mainnet, the number its setup screen uses to warn about disk space. The bitcoin.org requirements page gives bandwidth and memory, but it was written for version 31.0, so its disk figure trails the chain. Plan disk from the release's number.

*Read on 3 November 2026 in the Bitcoin Core 32.1 source and documentation and on bitcoin.org.*

| Figure | Value | Source |
| --- | --- | --- |
| Block files of a full node | 897 GB | Bitcoin Core 32.1, mainnet assumed size |
| Chain state (UTXO database) | 14 GB | Bitcoin Core 32.1, mainnet assumed size |
| Smallest automatic prune target | 550 MiB | Bitcoin Core 32.1, `-prune` help |
| First download of the chain | About 740 GB, once | bitcoin.org requirements (Bitcoin Core 31.0) |
| Download after the first sync | 500 MB a day, 15 GB a month | bitcoin.org, minimum recommended |
| Upload with default settings | 5 GB a day, 150 GB a month | bitcoin.org, minimum recommended |
| Memory | 2 GB recommended | bitcoin.org, minimum recommended |
| Default UTXO cache (`dbcache`) | 450 MiB below 4,096 MiB of RAM, else 1,024 MiB | Bitcoin Core 32.1, reduce-memory.md |

## Should I run a full node or a pruned node?

**Pruned, on any VPS sold here.** A full copy needs about 911 GB, and the largest plan, Tera, is 8 vCPU / 24 GB / 400 GB. A pruned node downloads and verifies every block like a full node, then deletes old block files to stay under its target. What you give up:

- It cannot serve old blocks to peers that are syncing.
- It cannot rescan a wallet's history past the blocks it kept.
- It cannot run `-txindex`: Bitcoin Core states that pruning is incompatible with it, which rules out tools that need a full transaction index.
- Going back to an unpruned node means downloading the whole chain again.

## How do I install Bitcoin Core 32.1 on Linux?

**Download the release from bitcoincore.org, check it against `SHA256SUMS`, check that file's signatures, then install the binaries.** The checksum line must end in `OK` for the tarball you downloaded, and `gpg --verify` must print several `Good signature` lines from builder keys you imported from the bitcoin-core/guix.sigs repository and chose to trust. Run the node as an ordinary user, not root. For systemd, the source tree ships a sample unit, `contrib/init/bitcoind.service`; adjust its paths to `/usr/local/bin`.

*Download, verify and install (x86_64)*

```bash
cd /tmp
wget https://bitcoincore.org/bin/bitcoin-core-32.1/bitcoin-32.1-x86_64-linux-gnu.tar.gz
wget https://bitcoincore.org/bin/bitcoin-core-32.1/SHA256SUMS
wget https://bitcoincore.org/bin/bitcoin-core-32.1/SHA256SUMS.asc
sha256sum --ignore-missing --check SHA256SUMS
# import a few builder keys from github.com/bitcoin-core/guix.sigs first
gpg --verify SHA256SUMS.asc SHA256SUMS
tar xzf bitcoin-32.1-x86_64-linux-gnu.tar.gz
sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-32.1/bin/*
```

## What goes in bitcoin.conf on a small VPS?

**A prune target, an upload cap, and the defaults for the rest.** `prune` is in MiB. `maxuploadtarget` is a daily target, not a hard limit: when it is close, the node stops serving blocks older than a week. Below 4,096 MiB of RAM the default `dbcache` drops to 450 MiB; Bitcoin Core notes that a lower value makes the first sync much longer, so raise it during that sync if the plan has memory to spare.

`getblockchaininfo` then shows `"pruned": true` and a `verificationprogress` that climbs toward 1. Peers reach the node on TCP 8333; open it to serve recent blocks, or set `listen=0` to accept no inbound peers. `blocksonly=1` cuts traffic further, but it turns off fee estimation, and Bitcoin Core warns that broadcasting your own transactions from such a node stands out.

*~/.bitcoin/bitcoin.conf*

```ini
# keep about 10 GB of recent blocks; every block is still verified
prune=10000
# aim to upload at most about 5 GB a day
maxuploadtarget=5000
# needed by bitcoin-cli and by LND
server=1
# during the first sync, if RAM allows:
# dbcache=2000
```

*Start and watch the sync*

```bash
bitcoind -daemon
bitcoin-cli getblockchaininfo
```

## How much traffic will the node use?

**About 740 GB in, once, then roughly 15 GB in and up to 150 GB out a month with default settings,** going by bitcoin.org's figures. A pruned node uploads less, because it can only serve the blocks it kept, and `maxuploadtarget` caps the rest. Each VPS comes with a dedicated IPv4 address and a routed IPv6 /64. Every plan lists its outbound traffic per month in TB, and going over it never triggers an automatic charge. Kilo includes 2 TB and Mega 6 TB of outbound traffic a month, well above what the node sends. Plans connect through a 1 Gbit/s port that the VPS on the same host share.

## Which plan fits a Bitcoin node?

**Kilo for a node alone, Mega or Giga when Lightning or other services share the VPS.** The prune values below leave room for the chain state, which grows, and for the system. The vCPU of every plan are shared: they are scheduled on physical cores that neighbouring VPS also use. The RAM and NVMe space of your plan are reserved for your VPS only. The first sync checks every block since 2009 and keeps the vCPU busy for a long stretch; it runs slower on shared vCPU than on dedicated cores, and no timing is published here.

*Sizes are vCPU / RAM / NVMe. Prune values are in MiB.*

| Plan | Size | Node setup |
| --- | --- | --- |
| Byte | 1 vCPU / 2 GB / 40 GB | Pruned node, `prune=10000`, default `dbcache`; a single vCPU makes the first sync slow |
| Kilo | 2 vCPU / 4 GB / 65 GB | Pruned node, `prune=30000`, default `dbcache` |
| Mega | 2 vCPU / 6 GB / 120 GB | Pruned node, `prune=40000`, with room for LND |
| Giga | 4 vCPU / 8 GB / 160 GB | Pruned node, `prune=100000`, larger `dbcache` for the first sync |
| Tera | 8 vCPU / 24 GB / 400 GB | Pruned node, `prune=300000`; still short of a full copy |

## What changes if I add Lightning?

**You add a hot wallet and channel state that must survive the loss of the server.** LND's documentation says it can run on a pruned Bitcoin Core, and that aggressive pruning costs performance because LND then fetches some blocks from peers. It needs RPC and ZMQ on the node: add `zmqpubrawblock=tcp://127.0.0.1:28332` and `zmqpubrawtx=tcp://127.0.0.1:28333` to bitcoin.conf.

Recovery rests on the 24-word seed and the static channel backup, `channel.backup`, which lets you ask former peers to force-close your channels. Lightning Labs says to back up `channel.db` but not to rely on it for recovery. No plan includes backups, so keep your own copy of anything that matters. For Lightning that means the seed, kept offline, and a copy of `channel.backup` taken off the VPS whenever channels change. Before putting real funds on any server, read [what your VPS host can see](https://vpswithcrypto.com/what-your-vps-host-can-see/ "What can your VPS host see?").

**Run your node on a VPS paid in bitcoin** Kilo and Mega hold a pruned Bitcoin Core with room to spare, at one price in all six cities. Pay in BTC, USDT, USDC, ETH, SOL, LTC, XMR. No KYC: signing up and paying take no identity document, no selfie, no card and no phone number. [See plans and prices](https://vpswithcrypto.com/pricing/ "How much does a VPS With Crypto server cost per month?")

## Questions about Bitcoin nodes on a VPS

### Can any VPS With Crypto plan hold a full, unpruned Bitcoin node?

No. Bitcoin Core 32.1 assumes 897 GB of block files plus 14 GB of chain state, and the largest plan, Tera, is 8 vCPU / 24 GB / 400 GB. Run the node pruned.

### Does a pruned node verify the chain like a full node?

Yes. It downloads and checks every block and transaction, then deletes old block files. It cannot serve those old blocks to other nodes or rescan wallet history beyond what it kept.

### Can I run an Electrum-style server on a pruned node?

Not one that needs `-txindex`: Bitcoin Core says pruning is incompatible with the transaction index. That needs the full chain, which no plan here holds.

### How long does the first sync take?

No figure is published here. It depends on CPU, `dbcache` and the peers you find; on shared vCPU it takes longer than on dedicated cores. `bitcoin-cli getblockchaininfo` shows the progress.

### Can I pay for the VPS with bitcoin?

Yes: payments are accepted in BTC, USDT, USDC, ETH, SOL, LTC, XMR. [Buying a VPS with Bitcoin](https://vpswithcrypto.com/buy-vps-with-bitcoin/ "How do I buy a VPS with Bitcoin, step by step?") walks through it, from the top-up to the confirmations.

## Sources

1. [Bitcoin Core 32.1 chain parameters: mainnet assumed blockchain and chain state sizes](https://github.com/bitcoin/bitcoin/blob/v32.1/src/kernel/chainparams.cpp) — Bitcoin Core (read 2026-11-03)
2. [Bitcoin Core 32.1 options (-prune, -maxuploadtarget, -blocksonly)](https://github.com/bitcoin/bitcoin/blob/v32.1/src/init.cpp) — Bitcoin Core (read 2026-11-03)
3. [Reduce Memory (dbcache defaults, blocksonly)](https://github.com/bitcoin/bitcoin/blob/v32.1/doc/reduce-memory.md) — Bitcoin Core (read 2026-11-03)
4. [Reduce Traffic (maxuploadtarget, listen, blocksonly)](https://github.com/bitcoin/bitcoin/blob/v32.1/doc/reduce-traffic.md) — Bitcoin Core (read 2026-11-03)
5. [Download Bitcoin Core 32.1 and Linux verification instructions](https://bitcoincore.org/en/download/) — bitcoincore.org (read 2026-11-03)
6. [Bitcoin Core requirements (version 31.0)](https://bitcoin.org/en/bitcoin-core/features/requirements) — bitcoin.org (read 2026-11-03)
7. [Running a full node](https://bitcoin.org/en/full-node) — bitcoin.org (read 2026-11-03)
8. [Run LND (backends, pruning, ZMQ)](https://docs.lightning.engineering/lightning-network-tools/lnd/run-lnd) — Lightning Labs (read 2026-11-03)
9. [Recovery: planning for failure (seed, channel.backup, channel.db)](https://docs.lightning.engineering/lightning-network-tools/lnd/recovery-planning-for-failure) — Lightning Labs (read 2026-11-03)

---

VPS With Crypto: VPS With Crypto sells Linux KVM VPS in New York, Dallas, Los Angeles, London, Amsterdam and Frankfurt, paid in crypto with no ID upload. The business behind it is DomaineGoat LLC, registered in Panama. A plan costs the same in all six cities, and on a 12-month term it is priced at least 25% under a named comparable plan, chosen among 34 no-KYC crypto hosts and read on 3 November 2026.