bitcoind process. You pick the network, the client version, and (optionally) a few tuning keys in the deploy wizard; everything else — data directory, RPC and P2P bindings, ports, and RPC credentials — is managed for you. The node ships with a full transaction index (txindex) enabled, so address and transaction lookups work out of the box.
Supported networks: mainnet and signet. The client is bitcoind, with versions 28.1, 28.0, and 27.0 offered in the wizard. The wizard only shows the networks and versions the chosen executor declares, so your options depend on where you deploy.
Networks and resources
Defaults are pre-filled in the deploy wizard. Lower them only if you know your workload fits — an under-resourced node syncs slowly or stalls.| Network | CPU | RAM | Disk |
|---|---|---|---|
mainnet | 2 cores | 4 GiB | 1200 GiB |
signet | 1 core | 4 GiB | 100 GiB |
RPC access
RPC access goes through the endpoint Novacula exposes for the node — see RPC exposure for the modes. The node binds the right RPC port per network for you (8332 on mainnet, 38332 on signet).
A Bitcoin node’s RPC authentication is not optional — bitcoind rejects any unauthenticated call and gives no way to turn auth off. Novacula provisions the same built-in credentials for every Bitcoin node — username nvcl, password nvcl — so each request must carry an Authorization: Basic header.
On a Direct endpoint, include the header on each request (the value below is nvcl:nvcl Base64-encoded):
Node type
Bitcoin offers two node types in the wizard’s Node type selector:- Full — keeps the complete block history and transaction index; serves the full historical RPC surface.
- Pruned — automatically drops old block data once it’s validated, so the node runs on a much smaller disk. Compute (CPU and RAM) is the same as Full; only the storage request is trimmed. Pick it when you only need a current-state RPC node and don’t serve historical block queries.
Config overrides
You can setbitcoin.conf overrides at deploy time or change them later — see Edit node configuration for the editing flow. The common tuning keys are offered with a type, description, and guided input:
| Key | Type | Description |
|---|---|---|
dbcache | number | Database cache size in MiB |
maxconnections | number | Maximum peer connections |
txindex | boolean | Maintain a full transaction index |
prune | number | Prune mode: target block-storage size in MiB |
blockfilterindex | boolean | Maintain block filter index |
peerblockfilters | boolean | Serve compact block filters |
coinstatsindex | boolean | Maintain coinstats index |
mempoolfullrbf | boolean | Accept full replace-by-fee in mempool |
assumevalid | string | Block hash to assume valid (skip script verification before it) |
par | number | Script verification threads |
maxmempool | number | Mempool size limit (MiB) |
bitcoin.conf key the client accepts — keys outside the list above are still applied. Settings the platform owns — the data directory, the chain selection, ports, RPC and P2P bindings, and RPC credentials — are protected: entering one flags the row as managed by Novacula and blocks the save until you remove it.
Metrics
The node reports block height, connected peers, sync progress, and more on its Monitoring and Overview tabs — see Node monitoring.Common patterns
- Pruned node — set
pruneto your target block-storage size in MiB (for example550for the minimum) to cap disk use. Lower the disk request in the wizard to match. - High-throughput RPC — raise
dbcacheandmaxconnectionsso the node keeps more of the UTXO set in memory and serves more concurrent peers. - Larger cache for an index rebuild — bump
dbcache(for example4096or higher) before enabling extra indexes likecoinstatsindex; expect heavier disk use while the index builds.