You still rely on public APIs for Bitcoin transactions? Rate limits, exposed IP, centralized points of failure — we face these issues in every payment processing project. A full Bitcoin Core node gives you independence, privacy, and full control. With over 5 years of experience, we've deployed nodes for 50+ projects — from custodial services to DeFi protocols.
Why a Bitcoin Node Is a Production Necessity
Without your own node, you depend on public APIs: they can go offline, change pricing, or throttle requests. Public APIs average around 99% uptime, while a self-hosted node on reliable hosting can achieve 99.99% — 100x less downtime. A node provides: your own transaction validation, full history via txindex, real-time notifications through ZMQ, and privacy — your addresses stay hidden from third-party providers. Running your own node saves up to $2,000 per month in API fees for an average payment processing project.
Hardware Requirements
| Mode | Disk | RAM | CPU | Description |
|---|---|---|---|---|
| Pruned | 10–15 GB | 2 GB | 2 cores | Stores only UTXO set + last N blocks |
| Full | 650+ GB | 4 GB | 4 cores | Full transaction history |
| Full + Electrum (Fulcrum) | 1 TB+ | 8 GB | 4+ cores | For wallets and address search |
SSD is mandatory — HDD makes initial block download 3–5 times slower due to random reads during UTXO set verification. We use only NVMe in production. Server hardware costs from $80 per month, which pays for itself in 2–3 months.
Installing Bitcoin Core
# Ubuntu 22.04 wget https://bitcoincore.org/bin/bitcoin-core-27.0/bitcoin-27.0-x86_64-linux-gnu.tar.gz # Always verify the signature! wget https://bitcoincore.org/bin/bitcoin-core-27.0/SHA256SUMS wget https://bitcoincore.org/bin/bitcoin-core-27.0/SHA256SUMS.asc gpg --recv-keys 152812300785C96444D3334D17565732E08E52E gpg --verify SHA256SUMS.asc SHA256SUMS sha256sum --check SHA256SUMS --ignore-missing tar xzf bitcoin-27.0-x86_64-linux-gnu.tar.gz sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-27.0/bin/* Configuration ~/.bitcoin/bitcoin.conf:
# Core server=1 daemon=1 txindex=1 # Index all transactions (needed for lookupByTxId) # RPC rpcuser=bitcoinrpc rpcpassword=STRONG_RANDOM_PASSWORD_HERE rpcbind=127.0.0.1 rpcallowip=127.0.0.1 # ZMQ — for real-time notifications zmqpubrawblock=tcp://127.0.0.1:28332 zmqpubrawtx=tcp://127.0.0.1:28333 zmqpubhashblock=tcp://127.0.0.1:28334 # Performance dbcache=1000 # Cache for initial sync, MB maxmempool=500 # Mempool size, MB # For pruned mode (remove txindex): # prune=10000 # Keep 10 GB of blocks txindex=1 is critical if you need to look up transactions by hash. Without it, only current UTXOs are available. Enabling it retroactively requires a full reindex (bitcoind -reindex). If your use case requires transaction lookup by hash, txindex=1 is mandatory. Without it, only current UTXOs are accessible. When enabled retroactively, the node reindexes all blocks — which can take extra time. Our engineers recommend enabling the index from the start if there is any potential need for historical data.
Initial Block Download
IBD on mainnet takes 1–5 days on SSD depending on hardware. To speed it up, start with dbcache=4000. Monitor progress via bitcoin-cli getblockchaininfo | jq '.verificationprogress'. We tune parameters to minimize sync time.
Using ZMQ for Real-Time Notifications
Polling via RPC every few seconds is primitive. ZMQ provides push notifications — up to 100x faster.
import * as zmq from 'zeromq'; const blockSocket = new zmq.Subscriber(); const txSocket = new zmq.Subscriber(); blockSocket.connect('tcp://127.0.0.1:28334'); blockSocket.subscribe('hashblock'); txSocket.connect('tcp://127.0.0.1:28333'); txSocket.subscribe('rawtx'); // New block for await (const [topic, message] of blockSocket) { const blockHash = message.toString('hex'); console.log('New block:', blockHash); await processNewBlock(blockHash); } // New transaction in mempool for await (const [topic, rawTx] of txSocket) { const tx = bitcoin.Transaction.fromBuffer(rawTx); await processPendingTransaction(tx); } Essential RPC Calls
import * as Client from 'bitcoin-core'; const client = new Client({ host: '127.0.0.1', port: 8332, username: 'bitcoinrpc', password: process.env.BITCOIN_RPC_PASSWORD!, }); // Transaction info const tx = await client.getRawTransaction(txHash, true); // UTXO info const utxo = await client.getTxOut(txHash, outputIndex); // Generate new address (for HD wallet use bitcoinjs-lib instead) const address = await client.getNewAddress('payment_label', 'bech32'); // Current fee rate (sat/vB for next block) const feeRate = await client.estimateSmartFee(1); // feeRate.feerate in BTC/kB, convert to sat/vB: const satPerVbyte = Math.ceil(feeRate.feerate * 100_000); Securing Your RPC and Node
Never expose RPC port (8332) externally. Access only via localhost or VPN:
# Firewall: block RPC from outside ufw deny 8332 ufw allow 8333 # P2P port — must be open for sync # Systemd unit for autostart cat > /etc/systemd/system/bitcoind.service << EOF [Unit] Description=Bitcoin daemon After=network.target [Service] User=bitcoin ExecStart=/usr/local/bin/bitcoind -conf=/home/bitcoin/.bitcoin/bitcoin.conf Restart=on-failure TimeoutStartSec=infinity [Install] WantedBy=multi-user.target EOF systemctl enable bitcoind systemctl start bitcoind A separate system user bitcoin without sudo — standard practice. Wallet files in /home/bitcoin/.bitcoin/wallets/ with a seed backup.
Common Deployment Pitfalls
One frequent issue is underestimating disk space. A full node with txindex requires 650+ GB, and many forget the blockchain grows. We recommend a 20–30% buffer. Another mistake is leaving the RPC port open. We configure the firewall immediately. Also, running the node as root — we always create a dedicated bitcoin user.
Setting Up Node Monitoring
For monitoring, we use Prometheus with bitcoin_exporter and configure alerts in Telegram. This allows timely response to node failures or disk space growth. We include basic monitoring in our turnkey deployment.
What Our Turnkey Deployment Includes
We provide the full cycle: Bitcoin Core installation, configuration tailored to your needs, ZMQ bridge for real-time data, security hardening (firewall, systemd, separate user), health monitoring, and documentation. Additionally, team training and 24/7 technical support. Our engineers bring 5+ years of experience and 50+ deployed nodes — ensuring stable operation. Contact us for a consultation on your project. Order a turnkey node deployment and get a stable infrastructure.
| Comparison of Modes | Pruned | Full | Full + Electrum |
|---|---|---|---|
| Disk | 10-15 GB | 650+ GB | 1 TB+ |
| Transaction history | Only recent blocks | Full | Full + address search |
| IBD time | 1-2 days | 2-5 days | 3-7 days |
| Recommended for | Lightweight apps | Payment processing | Wallets with search |







