Why run your own node
The point of a full node is a single word: verification. Instead of asking someone else’s server whether a payment is valid, bitcoind checks every rule itself — signatures, block subsidy, no double-spends — against a copy of the chain you control. “Don’t trust, verify” stops being a slogan the moment your wallet talks to your own node.
A VPS is a natural home for this. A node wants to be online continuously, keep a stable set of peers, and stay synced so it’s ready when you are. That’s awkward on a laptop that sleeps and roams; it’s exactly what an always-on server does well. And because the host is no-KYC and paid in crypto, renting the machine doesn’t tie your node back to your identity.
Choose your disk footprint
The big decision is pruned versus full, because it decides how much disk you rent.
- Pruned (
prune=550and up): bitcoind validates the whole chain during sync but only keeps the most recent blocks, discarding the rest. You get full validation in a few gigabytes — perfect for backing a wallet or a Lightning node. - Full + index (
txindex=1): keeps the entire chain and a transaction index so you can look up any historical transaction. This is what a BTCPay server or an explorer needs, and it’s why we recommend our disk-heavy Pro plan for it.
The full chain is large — hundreds of GB — and grows steadily, so size the volume with headroom. Pruning cuts that requirement dramatically.
Install bitcoind
The commands below install Bitcoin Core from the release tarball on a fresh Ubuntu server. Always verify the release signatures against the Bitcoin Core maintainers’ keys before running anything — the project publishes them for exactly this reason.
# on a fresh VPS (Ubuntu 24.04), as a non-root user
sudo apt update && sudo apt install -y wget gnupg
# download the release + checksums (set VER to the current version)
VER=27.0
wget https://bitcoincore.org/bin/bitcoin-core-$VER/bitcoin-$VER-x86_64-linux-gnu.tar.gz
# VERIFY signatures/hashes before extracting — see bitcoincore.org
tar -xzf bitcoin-$VER-x86_64-linux-gnu.tar.gz
sudo install -m 0755 bitcoin-$VER/bin/* /usr/local/bin/Create a minimal ~/.bitcoin/bitcoin.conf. This example runs a pruned node bound to
localhost, which is the safe default for a node that feeds services on the same box:
# ~/.bitcoin/bitcoin.conf
server=1
daemon=1
# pruned: keep ~5 GB of recent blocks. Use txindex=1 instead for a full node.
prune=5000
# only accept RPC from this machine; use a cookie or rpcauth for real credentials
rpcbind=127.0.0.1
rpcallowip=127.0.0.1Start it and watch the initial block download progress:
bitcoind
bitcoin-cli getblockchaininfo | grep -E 'blocks|headers|verificationprogress'verificationprogress climbs toward 1.0 as the node validates history. The
initial block download runs once and is the slow part; after that the node stays
in sync on its own.
Put it behind Tor
Running over Tor gives the node a stable, IP-free identity and lets it accept inbound peers without exposing a public port on your VPS. Install Tor, grant bitcoind access to the control port, and it handles the rest:
sudo apt install -y tor
sudo usermod -aG debian-tor "$USER" # allow control-port accessThen add to bitcoin.conf:
proxy=127.0.0.1:9050
listen=1
onlynet=onion
torcontrol=127.0.0.1:9051With onlynet=onion, bitcoind talks only to other nodes over Tor and publishes its
own v3 onion service automatically. Check bitcoin-cli getnetworkinfo to confirm
the onion address is live.
Secure the box
Because RPC is bound to localhost, nothing node-related needs to face the public
internet — Tor handles peer connectivity. Keep it that way: disable password SSH in
favour of keys, run a firewall that denies inbound by default, and never expose the
RPC port to 0.0.0.0. If you must reach the node remotely, tunnel over SSH rather
than opening the port.
What this pairs with
A validating node is the foundation other privacy infrastructure sits on. Point a Lightning daemon or a self-hosted BTCPay server at it so your payments are verified against your own source of truth. Running a Nostr relay on the same host is a natural companion for a sovereign, self-hosted setup — different service, same principle of owning your own infrastructure.
We rent you a reliable, private, disk-heavy server; the node — and the trust that comes from verifying for yourself — is yours.