To run a bitcoin node over Starlink, plan for a one-off download of around 740 GB, then control ongoing traffic with blocks-only mode or a daily upload limit.
This setup guide belongs to the wider crypto satellite coverage. It suits anyone who wants a validating node on a rural or off-grid connection and is prepared to budget data before the first start.
Prerequisites
A node on satellite internet is mostly a data-budgeting exercise. Settle these points before installing anything.
- Software choice. Spark’s node guide calls Bitcoin Core the right default for most users, so the steps below assume it.
- Disk space. Bitcoin Core’s published minimums, as summarised by BaCloud, are 750 GB of disk space and 2 GB of RAM. An external SSD is the usual way to meet the disk requirement on a small computer.
- A known data allowance. Look up what your satellite plan allows per month and whether speeds are reduced after a threshold. The figures in this guide are the numbers to compare it against.
- A decision on full or pruned. This changes disk use, not download volume, and some features cannot be added later without a rebuild. Step 2 covers it.
Setting up the node, step by step
Step 1: Install the indoor equipment and confirm a stable link
Mount the dish with a clear view of the sky, connect the router indoors and give the node computer a wired connection to it where possible. A node keeps many peer connections open for months, so a cable removes one variable when you later judge whether slow progress is the satellite link or the Wi-Fi.
Step 2: Choose full or pruned before the first sync
A full archival node needs approximately 800 GB of storage, made up of 756 GB of blockchain plus indexes, and that figure grows by 60-80 GB per year. A pruned node needs approximately 10 GB of total disk in 2026, and the minimum pruning setting is prune=550, which keeps 550 MiB of recent block data.
Pruning does not shrink the download. BaCloud notes that pruning saves disk space, not downloads, so the initial sync still pulls the whole chain. A pruned node also cannot run txindex, a block explorer or an Electrum server.
Choose full if you plan to serve an explorer or Electrum server. Choose pruned if the goal is to validate your own transactions on a small drive. Settle this now: Start9’s Bitcoin Core instructions warn that adding txindex after sync starts a rebuild from the first block. The same document says StartOS prunes automatically on disks under roughly 900 GB.
Step 3: Set the bandwidth limits before the node connects
Apply limits in the configuration file or the package settings before the first launch, so the node never runs unrestricted on a metered link.
- Blocks-only mode. Spark’s guide says the -blocksonly option limits total bandwidth to roughly 5 GB/month on a metered connection. The trade-off is that the node stops relaying loose transactions and receives only new blocks.
- Daily upload limit. The Start9 settings list a daily upload limit alongside mempool options. In Bitcoin Core this is the maxuploadtarget option, which caps how much the node uploads to peers per day.
- Listening port. Spark states that listening nodes with port 8333 open can upload 200+ GB/month serving blocks to peers. On a capped plan, leave the port closed or combine an open port with the upload limit.
Step 4: Start the initial block download
On launch, Bitcoin Core begins its Initial Block Download, fetching and verifying the entire chain. Start9 adds that the sync runs with a temporarily larger database cache, which reverts once it completes, so expect higher memory use at first rather than permanently.
Download size is the priority on satellite internet. BaCloud puts the one-off figure at around 740 GB, and the chain was about 759 GB in early August 2026. Check your plan’s allowance before starting. If it cannot cover that volume within one billing period, wait until it can or arrange the first sync another way.
Step 5: Monitor progress and let it finish
Check progress in the node’s interface or terminal rather than restarting when it looks slow. Restarts add little and interrupt peer connections. Steady forward movement of the block height is the sign the link is healthy, and total time depends heavily on the computer as well as the connection.
If progress stalls for long stretches, test the link first and the storage second. A slow disk can look like a slow connection, and the hardware times in the FAQ show how widely they differ.
Step 6: Switch to steady-state operation
After the sync, Spark puts steady-state download at about 20 GB/month. Upload is the variable part, which is why the limits from Step 3 matter. BaCloud suggests planning for at least 150 GB of upload every month for a node that serves peers.
Review your usage after the first full billing month. If the total sits close to the plan allowance, tighten the daily upload limit or move to blocks-only mode.
Data budget checkpoints
Use this table to compare the node’s data needs with the satellite plan before and after the sync.
| Item | Figure | Planning use |
|---|---|---|
| One-off initial download | Around 740 GB | Must fit inside the plan’s data allowance, or be spread across billing periods. |
| Full node storage with indexes | Approximately 800 GB, growing 60-80 GB per year | Size the external drive with room for growth. |
| Pruned node total disk | Approximately 10 GB | Cuts disk cost only, not download volume. |
| Steady-state download | About 20 GB/month | The baseline monthly cost of staying in sync. |
| Listening node upload | 200+ GB/month | Exceeds most capped plans, so limit or close the port. |
| Blocks-only mode total | Roughly 5 GB/month | The lowest-traffic option for a metered link. |
Figures come from Spark’s node comparison and BaCloud’s server sizing guide.
Pruned node or full node on satellite
A pruned node is a good fit for most satellite users who only need to validate. Spark says a pruned node still validates every block before discarding old data, so the security model is the same as a full node’s. The cost is lost features: no txindex, explorer or Electrum server.
A full node suits those who want to serve other software. A node fed by Start9’s package can expose a JSON-RPC interface on port 8332 for other services, which is the usual route for wallets and explorers. If that is the plan, choose full storage from the start. Anyone pairing a node with signing hardware may also want to read about a space based crypto wallet before deciding what the node will serve.
Latency and block relay on satellite internet
Download volume is the main constraint on a satellite link, and a node’s work is mostly receiving blocks and verifying them locally. The one latency cost named in the supplied documentation is on pruned nodes: Start9 says the only cost is a little latency whenever an old block is needed, because that block must be fetched again.
For a node that mostly follows the tip of the chain, that is rarely a problem. If you later want to rescan old wallet history, a full node avoids those re-fetches. Operators who also want to contribute hash power should read about bitcoin mining over satellite internet, since mining has different latency needs from validation.
Frequently asked questions
How long does the initial sync take on small hardware?
Spark gives about 12 hours on an i7 with NVMe, 24-48 hours on an Intel N100 with NVMe and 3-5 days on a Raspberry Pi 5. A satellite link can only add to those hardware-based figures.
Can a pruned node run an Electrum server?
No. BaCloud states that a pruned node cannot run txindex, a block explorer or an Electrum server. Choose a full node if you need any of them.
Is Bitcoin Core the right software for a satellite node?
Spark’s guide calls Bitcoin Core the right default for most users. Its settings cover the upload and pruning controls this guide relies on.
Does the larger sync cache stay in place afterwards?
No. Start9 says the initial sync runs with a temporarily larger database cache that reverts after completion.
