Run a Bitcoin full node that nobody signed up for.
A pruned bitcoind fits the smallest plan here and an archival node fits nothing: this page has the numbers either way, a Tor-only config, and encrypted memory if the node carries a wallet.
Why here
Disk you can plan around01
Pruned at the 550 MiB minimum lands near 7 to 11 GB, and a 100 GB window still fits a 200 GB plan.
Encrypted memory for a hot wallet02
An unlocked Core wallet keeps its decryption key in RAM. On a Blackbox the CPU encrypts guest memory and the hypervisor sees ciphertext.
Bandwidth for the first sync03
Roughly 740 GB comes down the first time, then about 20 GB a month. Blackbox is 10 Gbps unmetered.
Nothing asked at signup04
A 32-character credential is the whole account. No email, no phone, no KYC. Pay in BTC, LTC or XMR.
Three node shapes, and which ones fit
Sizing decides the plan, so decide it first.prune=550, the minimum, keeps about 288 blocks, roughly two days. bitcoin.org puts the total near 7 GB, and the chainstate grows on top of it. Blackbox Core, 2 vCPU / 4 GB / 50 GB, $9.99 a month.
A prune target of 100000 keeps about 100 GB of recent blocks, enough to serve peers and rescan a wallet months back. Blackbox Max, 6 / 16 / 200, $39.99.
Does not fit. The chain alone was about 756 GB in July 2026 and electrs adds roughly 7 to 14 percent on top, so 810 to 860 GB together. The largest disk here is 400 GB. Use signet, or a pruned node with your wallet talking to Core over an SSH tunnel.
Quick start: pruned, Tor-only bitcoind on Debian 13
Bitcoin Core 31.1, verified, under systemd. Run as root on a fresh 4 GB machine; every step cites its source.# 1. Dependencies, including the Tor daemon the node will speak through.
apt update && apt install -y wget gnupg git tor
# 2. Fetch the release, the checksums, and the signatures on the checksums.
# https://bitcoincore.org/en/download/
cd /tmp
wget https://bitcoincore.org/bin/bitcoin-core-31.1/bitcoin-31.1-x86_64-linux-gnu.tar.gz
wget https://bitcoincore.org/bin/bitcoin-core-31.1/SHA256SUMS
wget https://bitcoincore.org/bin/bitcoin-core-31.1/SHA256SUMS.asc
# 3. Hash first, then the signatures over the hash file. Builder keys live at
# builder-keys/<signer>.gpg: https://github.com/bitcoin-core/guix.sigs
sha256sum --ignore-missing --check SHA256SUMS
git clone https://github.com/bitcoin-core/guix.sigs
gpg --import guix.sigs/builder-keys/*.gpg
gpg --verify SHA256SUMS.asc # want lines reading "gpg: Good signature"
# 4. Install. The upstream systemd unit calls /usr/bin/bitcoind.
tar xzf bitcoin-31.1-x86_64-linux-gnu.tar.gz
install -m 0755 -o root -g root -t /usr/bin bitcoin-31.1/bin/*
# 5. Let Bitcoin Core create its own onion service through the Tor control
# port. https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md
cat >> /etc/tor/torrc <<'TORRC'
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1
TORRC
adduser --system --group --home /var/lib/bitcoind bitcoin
usermod -a -G debian-tor bitcoin # so bitcoind can read Tor's auth cookie
systemctl restart tor
# 6. Config: pruned, and reachable over onion only.
mkdir -p /etc/bitcoin
cat > /etc/bitcoin/bitcoin.conf <<'CONF'
# MiB of raw block and undo data to keep. 550 is the minimum allowed and is
# what the 50 GB Blackbox Core plan wants; 100000 keeps a ~100 GB window and
# needs the 200 GB Max plan instead. Pruning is incompatible with -txindex.
prune=550
# 1024 MiB is the 31.0 default where at least 4096 MiB of RAM is detected.
dbcache=1024
# Outbound through the local Tor SOCKS proxy, onion peers only.
proxy=127.0.0.1:9050
onlynet=onion
# listen defaults to off behind a proxy; bind the inbound side to loopback
# so the onion service is the only way in.
listen=1
bind=127.0.0.1:8334=onion
# Target for outbound traffic per 24h in MiB; historic blocks are cut first.
# 144 MiB/day is the recommended minimum: https://bitcoin.org/en/full-node
maxuploadtarget=5000
CONF
chown root:bitcoin /etc/bitcoin/bitcoin.conf && chmod 640 /etc/bitcoin/bitcoin.conf
# 7. Upstream systemd unit. It runs as the bitcoin user and creates
# /etc/bitcoin, /var/lib/bitcoind and /run/bitcoind itself. Locally
# installed units go in /etc/systemd/system; /lib/systemd/system is
# package-owned territory and gets overwritten.
# https://github.com/bitcoin/bitcoin/blob/v31.1/contrib/init/bitcoind.service
wget -O /etc/systemd/system/bitcoind.service \
https://raw.githubusercontent.com/bitcoin/bitcoin/v31.1/contrib/init/bitcoind.service
systemctl daemon-reload && systemctl enable --now bitcoind
# 8. Watch it sync. verificationprogress runs 0 to 1, and
# initialblockdownload flips to false once the node is caught up.
bitcoin-cli -datadir=/var/lib/bitcoind getblockchaininfo
# 9. Prove the isolation: only onion should be reachable, and localaddresses
# should hold one .onion address.
bitcoin-cli -datadir=/var/lib/bitcoind getnetworkinfo
# 10. Reach the RPC from your own machine over SSH, never over the internet.
# This config sets no rpcauth, so the only credential is the .cookie file
# bitcoind writes into /var/lib/bitcoind. Copy it to the datadir your
# wallet reads, or add an rpcauth= line to bitcoin.conf, before a remote
# wallet can authenticate. Run this locally, then point Sparrow or
# Specter at 127.0.0.1:8332:
# ssh -N -L 8332:127.0.0.1:8332 root@YOUR_SERVER_IPHow much VPS a Bitcoin node needs, and where the ceiling is
A Bitcoin node VPS is a rented machine running bitcoind so a wallet can verify its own transactions instead of asking someone else's server for its balance. One decision drives every other: prune it. A pruned node validates every block and every signature from genesis and keeps the entire UTXO set; all it discards is raw block files it already checked, and those are where the disk goes.
Disk. The prune=N option prunes old blocks "if a target size in MiB is provided", in Core's own help text (init.cpp), and "The minimum allowed is 550MB", enough for about 288 blocks or two days (Bitcoin Core 0.11.0 release notes). bitcoin.org says that takes disk usage "from over 750GB to around 7GB" (Running A Full Node), with the chainstate growing on top of that floor; and Coin Bureau's July 2026 archival figure is "approximately 756GB", growing "roughly 82GB" a year (Coin Bureau). The largest disk here is 400 GB, so pruned fits every plan and archival fits none.
Memory and time. bitcoin.org asks for 2 GB of RAM and a disk doing at least 100 MB/s. Bitcoin Core 31.0 raised the default -dbcache to "1024 MiB from 450 MiB on systems where at least 4096 MiB of RAM is detected" (31.0 release notes), and a lower dbcache "makes initial sync time much longer" (reduce-memory.md), which makes 4 GB the sensible floor. Sync time is a range: bitcoin.org says "at least several days", while Jameson Lopp's 2025 tests took Core 30.0 to block 928,000 in "12 hours 7 minutes" with dbcache=24000 and a local peer (2025 node performance tests). Core 26.0 added loadtxoutset, which loads a UTXO snapshot and gives "a usable bitcoind instance that is current with the network tip in a matter of minutes rather than hours" while the original chainstate validates behind it (26.0 release notes). Bandwidth is the 740 GB first sync, then "200 gigabytes upload or more a month" and "around 20 gigabytes" down; Blackbox is 10 Gbps unmetered.
Electrs. The Electrum server people usually want needs an unpruned node: its usage guide starts bitcoind with -prune=0, says the index "should be ~7% of the blocks/*.dat files, but it may increase to ~14% at the end of the initial sync", and shows "56G" for its own reference run (electrs usage guide); its example config wants "at least 70GB of free space" for the index directory (electrs config_example.toml). That is roughly 810 to 860 GB together. What fits is a pruned node with a wallet pointed straight at Core through an SSH tunnel: Sparrow says "Running a pruned node is fine", with rescans limited to the blocks you kept (Sparrow docs).
Why the host matters. walletpassphrase "Stores the wallet decryption key in memory" for the timeout you give it (Core RPC docs), and on an ordinary VPS the host can read it. Blackbox encrypts guest RAM with AMD SEV-SNP, ships no guest agent, and takes a LUKS2 passphrase you set over SSH into the initramfs (SEV-SNP page). Two limits: no line here has DDoS protection, and cryptocurrency mining is prohibited by the terms, so a node is welcome and a miner is not. A Tor-only node is also not a Tor relay: it carries only its own traffic. Pay in BTC from the Bitcoin VPS page, or start at the order page.
What the machine gives you
Same servers, whichever way you pay.Blackbox, Montreal, hardware Servury owns01
Core 2 vCPU / 4 GB / 50 GB $9.99, Plus 4 / 8 / 100 $19.99, Max 6 / 16 / 200 $39.99, Ultra 8 / 32 / 400 $89.99. EPYC 7543, ZFS mirror, 10 Gbps unmetered, IPv4 plus a routed /64.
Standard VPS and VDS in 8 locations02
Blackbox Core from $9.99, a standard VPS from $15.59 with 4 vCPU and 4 GB, or a VDS-150 with 2 dedicated cores and DDR5 at $17.99. IPv4 only on this line.
Encrypted memory, no guest agent03
Blackbox guests launch under SEV-SNP with debug disabled and expose /dev/sev-guest for attestation. No virtio-serial channel means the panel has no path into a running guest, and cannot reset the root password.
A disk key Servury never holds04
LUKS2 set from inside the VM over SSH into the initramfs. The passphrase never reaches Servury, so losing it loses the machine.
Terms from 7 to 365 days05
Run a node for a week or a year. Under 31 days the standard line is prorated plus a 10% short-term fee; Blackbox is pure pro-rata.
No logs, and a canary that says so06
No access logs, no analytics, no third-party scripts on public pages. A PGP-signed canary at /canary/, live per-node uptime at /status/, 99.9% availability in the terms.
Your own node, on a machine with no name on it.
Pruned bitcoind on a 4 GB plan from $9.99 a month. Pay in Bitcoin, sign up with nothing.
Fair questions
How much disk does a Bitcoin node need on a VPS?
A pruned node needs very little: bitcoin.org puts prune=550, the minimum, at around 7GB, with the chainstate growing on top of it. An archival node was about 756 GB in July 2026 and grows roughly 82 GB a year. The largest disk here is 400 GB, so pruned fits every plan and archival fits none.
What does a pruned node give up?
Nothing about validation: it checks every block and every signature and keeps the full UTXO set. It gives up history. A pruned node cannot serve old blocks to peers, cannot rescan a wallet past the oldest block it kept, and cannot run -txindex, which Core refuses to combine with pruning.
Can I run electrs on a Servury VPS?
Not on mainnet. The electrs usage guide starts bitcoind with -prune=0, and its index adds roughly 7 to 14 percent on top of the block files, 56 GB in the project's own reference run. That is 810 to 860 GB together against a 400 GB maximum here. On signet or testnet it fits easily.
How long does the initial block download take?
A range. bitcoin.org still says at least several days on modest hardware, while Jameson Lopp's 2025 test synced Bitcoin Core 30.0 to block 928,000 in 12 hours and 7 minutes on a 6-core desktop with dbcache=24000 and a local peer. Core 26.0 added loadtxoutset, which loads a UTXO snapshot and gives a node current with the network tip in minutes rather than hours.
Can the node talk only over Tor?
Yes. Bitcoin Core documents proxy=127.0.0.1:9050 for outbound connections, onlynet=onion to keep them on .onion peers, listen=1 because listening is off by default behind a proxy, and bind=127.0.0.1:8334=onion inbound. Core makes its own onion service when tor runs with ControlPort 9051 and cookie authentication.
Is it safe to keep a wallet on a hosted node?
Know what you are trusting. The walletpassphrase RPC stores the wallet decryption key in memory for the timeout you set, and an ordinary host can read guest RAM. Blackbox runs AMD SEV-SNP with no guest agent in the VM. Large balances still belong on hardware you hold.
Can I mine on the same server?
No. Cryptocurrency mining of any kind is prohibited by the terms and leads to suspension. Running a node, a wallet or a signing service is fine; pointing a miner at the CPU is not.
Debian 13
Ubuntu 26.04 LTS
Rocky Linux 9
AlmaLinux 10
FreeBSD 15
OpenBSD 7.9
