Crypto · no KYC
Host Bitcoin Core (bitcoind) on an Offshore VPS
Running your own Bitcoin Core full node is the only way to verify the chain yourself instead of trusting someone else's server, and an offshore no-KYC VPS lets you do it without tying your identity to it.
What it is
Bitcoin Core (bitcoind) is the reference implementation of the Bitcoin protocol: it downloads and independently validates every block and transaction, relays them to peers, and exposes a JSON-RPC interface your wallet or apps can trust. A full node gives you self-custody-grade validation, privacy from public block explorers, and a backend for wallets, Lightning nodes, Electrum servers (Fulcrum/electrs), or BTCPay Server.
Why host it offshore
Your node's IP address is visible to every peer it connects to, so running it from a paid-with-crypto, no-identity VPS keeps it decoupled from your home connection and your name. ChainVPS is no-KYC with unmetered bandwidth, which matters because the initial block download and ongoing peer relay move hundreds of gigabytes that would blow a metered cap.
The deploy
A working reference setup
Copy this onto a fresh ChainVPS instance. Replace the placeholders, then bring it up.
# docker-compose.yml — Bitcoin Core full node (pruned by default for a small VPS)
# 1) Generate an RPC credential first (do NOT store a plaintext password):
# curl -sSL https://raw.githubusercontent.com/bitcoin/bitcoin/master/share/rpcauth/rpcauth.py \
# | python3 - bitcoin
# It prints an rpcauth=... line and a matching password. Paste the rpcauth line below.
# 2) docker compose up -d then follow IBD: docker compose logs -f
services:
bitcoind:
image: bitcoin/bitcoin:28.1
container_name: bitcoind
restart: unless-stopped
stop_grace_period: 2m
user: "1000:1000"
ports:
- "8333:8333" # P2P — public, lets you serve/accept peers
- "127.0.0.1:8332:8332" # RPC — bound to localhost ONLY, never expose
volumes:
- ./bitcoin-data:/home/bitcoin/.bitcoin
command:
- -printtoconsole
- -server=1
- -listen=1
- -prune=10000 # ~10 GB of blocks; set -prune=0 -txindex=1 for a full archival node
- -dbcache=1024 # MB; raise to 2048-4096 on bigger boxes to speed IBD
- -maxmempool=300
- -maxconnections=40
- -rpcbind=0.0.0.0 # binds inside the container; host mapping keeps it on 127.0.0.1
- -rpcallowip=172.16.0.0/12 # docker bridge range, so host-side tools can reach RPC
- -rpcauth=bitcoin:REPLACE_WITH_GENERATED_HASH # <-- paste rpcauth output here
- -disablewallet=1 # node-only; drop this line if you want the built-in wallet
# First run needs ./bitcoin-data owned by uid 1000: mkdir -p bitcoin-data && sudo chown 1000:1000 bitcoin-dataFirewall
Ports to open
| Port | Protocol | Purpose |
|---|---|---|
| 8333 | TCP | Bitcoin P2P — accept and serve peers; the only port that should be publicly reachable |
| 8332 | TCP | JSON-RPC control interface — bind to 127.0.0.1 only, reach it over SSH tunnel or a private network |
| 28332/28333 | TCP | Optional ZMQ block/tx notifications for a Lightning node or Electrum server; localhost only |
| 9050 | TCP | Optional local Tor SOCKS proxy if you run bitcoind over Tor for peer-level privacy |
Right-sizing
Which plan you need
VPS Small (2 vCPU / 4 GB RAM / 60-80 GB NVMe)
prune=10000 keeps ~10 GB of blocks plus the ~10 GB chainstate; validates the full chain, ideal as a wallet/Lightning backend where you do not need historical block data.
VPS Pro or Storage VPS (4 vCPU / 8 GB RAM / 1 TB disk)
prune=0 stores every block (~650 GB and growing in 2026); Storage plans give the cheap large-disk headroom, unmetered bandwidth covers the full IBD and peer relay.
Dedicated or large Storage VPS (8+ vCPU / 16-32 GB RAM / 1.5-2 TB NVMe)
txindex=1 plus Fulcrum/electrs adds a large address index and serves many wallet clients; needs fast NVMe and RAM for the dbcache and index rebuilds.
Best locations: Any of the 15 locations work since ChainVPS bandwidth is unmetered, which is what a node's multi-hundred-GB IBD and continuous relay actually need. For no-identity operation choose the privacy-tier locations — Iceland, Switzerland, Moldova, Netherlands, Romania, or Luxembourg — where the node has no link to your name; jurisdictions like Iceland and Switzerland are also good picks if you plan to run it over Tor and want a stable, privacy-friendly home for a long-lived node.
Lock it down
Hardening checklist
- Never expose port 8332 to the internet. Keep the RPC mapping on 127.0.0.1 as shown and reach it via `ssh -L 8332:127.0.0.1:8332 user@server`; a reachable RPC with weak/guessable creds is the classic way nodes get drained or hijacked.
- Use -rpcauth (a salted hash) instead of -rpcuser/-rpcpassword so no plaintext password sits in the compose file or process list; rotate it if the box is ever shared or snapshotted.
- Run over Tor for peer-level privacy: install tor on the host and add -proxy=127.0.0.1:9050 -listen=1 -bind=127.0.0.1 plus an onion service, so peers see a .onion instead of your VPS IP. Combine with -onlynet=onion if you want no clearnet peers at all.
- Lock the firewall with ufw: allow only 22 (SSH, ideally key-only + moved port) and 8333 inbound, deny everything else. bitcoind opens its own outbound peer connections regardless.
- Watch the disk. A pruned node is stable at ~20 GB, but an unpruned node grows continuously — set up a disk-usage alert and enough headroom, because a full disk halts validation and can corrupt the chainstate on a hard crash.
- Set stop_grace_period (2m above) and use `docker compose stop`, never a hard kill — bitcoind needs time to flush its LevelDB chainstate cleanly or you risk a slow reindex on next start.
Deploy it on
The right ChainVPS product
Questions
Hosting Bitcoin Core (bitcoind) — FAQ
How much disk do I really need?
A pruned node (prune=10000 in the config) stays around 15-20 GB and still validates the entire chain. A full archival node stores every block, which is roughly 650 GB in 2026 and grows about 50-70 GB per year, so plan for 1 TB+. Adding txindex=1 or an Electrum server pushes you toward 1.5-2 TB of fast NVMe.
How long does the initial block download (IBD) take?
On a modern VPS with unmetered bandwidth and dbcache=2048+, expect several hours to about a day to fully sync and validate from genesis, depending on CPU and disk speed. Raising -dbcache during the initial sync is the single biggest speedup. It is a one-time cost; after that the node only downloads new blocks.
Can I run a Lightning node or Electrum server against this?
Yes. Enable ZMQ (add -zmqpubrawblock and -zmqpubrawtx on ports 28332/28333) and point LND, Core Lightning, Fulcrum, or electrs at the RPC and ZMQ endpoints over the local Docker network. Note that Fulcrum/electrs need txindex=1, so you cannot pair them with a pruned node.
Is a pruned node less secure or less private?
No. A pruned node performs the exact same full validation of every block and transaction as an archival node — it simply discards old block data after verifying it. Your wallet's security and privacy are identical. You only lose the ability to serve historical blocks to other peers or rescan arbitrary old transactions.
Will my node's IP be visible?
Yes — every peer you connect to sees your node's IP by design. That is exactly why running it on a no-KYC offshore VPS helps: the IP belongs to a server with no link to your identity or home connection. For full peer-level privacy, run bitcoind over Tor as described in the hardening tips so peers see only a .onion address.
More to self-host
Other one-click stacks
Spin up Bitcoin Core (bitcoind)
in the next 60 seconds.
Unmetered bandwidth · DDoS included · 21 cryptocurrencies · no KYC.