Bitcoin Guides

Guides for running Bitcoin and Lightning on your own hardware with StartOS — from choosing a wallet to managing channels to migrating from another node platform.

Why Run Your Own Node?

When you use a Bitcoin wallet without your own node, you are trusting someone else’s server to tell you your balance, broadcast your transactions, and report on the state of the network. That server operator can see which addresses belong to you, track your transaction history, and potentially censor or delay your transactions.

Running your own Bitcoin node means your wallet talks directly to the Bitcoin network through your own verified copy of the blockchain. No one can see your addresses, censor your transactions, or lie to you about your balance. It is the difference between trusting and verifying.

StartOS makes this practical. Install a Bitcoin node from the StartOS Marketplace and it handles the configuration, networking, and storage — no command line required. Add an Electrum server (such as Fulcrum) and most wallets can connect to your node with a single address. Add LND or Core Lightning and you have a full Lightning node for instant, low-fee payments.

What’s in This Guide

• Archival vs Pruned Nodes — The trade-offs between archival and pruned nodes, and how StartOS makes pruned nodes work seamlessly with multiple downstream services.

• Electrum Servers — What an Electrum server is, why you need one, and which implementations are available on StartOS.

• Bitcoin Wallets — An index of on-chain wallets that connect to your own Bitcoin node or Electrum server, with platforms, connection methods, and links to upstream docs.

• Lightning Wallets — Native apps and self-hosted web tools for managing your LND or Core Lightning node, including RTL, ThunderHub, Zeus, Alby Hub, and more.

• Migrating LND to StartOS — How to transfer your LND node from Umbrel, RaspiBlitz, myNode, or another platform to StartOS without closing channels.

Supported Implementations

StartOS supports multiple Bitcoin and Lightning node implementations. You are not locked into a single stack — choose the implementation that fits your needs.

Bitcoin Nodes

Both implementations provide the same RPC interface used by wallets and Electrum servers.

Lightning Nodes

Learn More

• StartOS Documentation — Installing StartOS, user manual, networking, backups
• Contact Support — Get help from the Start9 team

Archival vs Pruned Nodes

A Bitcoin node can store the entire blockchain (archival) or only a subset of it (pruned). Both modes fully validate every block and transaction — the difference is how much historical data the node keeps on disk after validation. StartOS supports both modes and includes a feature that makes pruned nodes more capable than they are on other platforms.

Archival Nodes

An archival node keeps every block ever produced, from the genesis block to the current tip. Nothing is deleted after validation.

Advantages:

• Serves any historical block — Other software that needs old blocks (block explorers, chain analysis tools) can fetch them directly from your node.
• Supports block explorers — Services like Mempool require access to the full blockchain history and only work with archival nodes.
• Reindex without re-download — If you need to rebuild internal databases, the node can reindex from its local copy of the chain.

Trade-offs:

• Disk usage — The full blockchain is over 600 GB and growing. You need a drive large enough to hold it plus room for continued growth.

Pruned Nodes

A pruned node validates every block but discards block data after processing, keeping only a subset of blocks rather than the full chain. The node retains the full UTXO set (the record of all unspent coins), so it can still validate new blocks and transactions.

Advantages:

• Much less disk space — A pruned node can run with as little as 5-10 GB of block data, compared to 600+ GB for an archival node.
• Same security — Pruned nodes validate everything. They enforce the same consensus rules as archival nodes.

Trade-offs:

• Cannot serve old blocks — On most platforms, if a service requests a block the node has already pruned, the request fails. StartOS solves this with on-demand block fetching.
• No block explorers — Services like Mempool that need full blockchain history will not work with a pruned node, even on StartOS.

Pruned Nodes on StartOS

On most platforms, running a pruned node introduces a practical limitation: downstream services like LND or BTCPay Server need to control which blocks are kept and which are pruned. Each service tells the node “don’t prune blocks newer than X” to ensure the blocks it cares about remain available. This works fine with a single downstream service, but breaks down when multiple services each want to control pruning — they can conflict over which blocks to keep.

StartOS solves this with on-demand block fetching. The Bitcoin package on StartOS integrates btc-rpc-proxy, which intercepts block requests from downstream services. If a service asks for a block the pruned node has already discarded, btc-rpc-proxy fetches that block from the Bitcoin peer-to-peer network on the fly and serves it to the requesting service. From the service’s perspective, it appears to be talking to an archival node.

This means:

• Multiple downstream services work simultaneously — LND, BTCPay Server, Fulcrum, and any other service can all connect to a single pruned node without conflict.
• No manual pruning management — You don’t need to coordinate which blocks each service needs. btc-rpc-proxy handles it transparently.
• Significant disk savings — You get most of the benefits of an archival node with a fraction of the disk usage.

Note

On-demand block fetching adds a small delay when a service requests a pruned block, since the block must be downloaded from the network before it can be served. In practice this is rare — most services only need recent blocks during normal operation.

Which Should You Choose?

For most StartOS users, a pruned node is the best choice. Thanks to on-demand block fetching, you get compatibility with all major downstream services while using a fraction of the disk space.

Choose an archival node if:

• You want to run a block explorer like Mempool — this is the one major use case that requires full historical block data and cannot be served by on-demand fetching.
• You have the disk space and prefer having a complete local copy of the blockchain for its own sake.

Electrum Servers

An Electrum server sits between your Bitcoin node and your wallet. It indexes the blockchain so wallets can quickly look up balances, transaction history, and unspent outputs for any address — without scanning the entire chain themselves. Most Bitcoin wallets connect to your self-hosted infrastructure through an Electrum server rather than directly via Bitcoin RPC.

Why You Need One

A Bitcoin node stores every block ever produced, but it does not maintain an index of which addresses own which coins. When a wallet asks “what is the balance of this address?”, the node would have to scan the entire blockchain to answer. This is slow and impractical for everyday use.

An Electrum server solves this by building a persistent index that maps addresses to their transactions and unspent outputs. Once the index is built, lookups are instant. The server speaks the Electrum protocol, a lightweight client-server protocol that wallets already know how to use.

The result: your wallet connects to your own Electrum server, your Electrum server talks to your own Bitcoin node, and you get fast address lookups without trusting anyone else’s infrastructure.

How It Works

┌──────────┐      Electrum       ┌─────────────────┐       RPC        ┌──────────────┐
│  Wallet  │ ──── protocol ────▶ │ Electrum Server  │ ──────────────▶  │ Bitcoin Node  │
└──────────┘                     │ (Fulcrum)        │                  │              │
                                 │ address index    │                  │ full chain   │
                                 └─────────────────┘                  └──────────────┘

1. Your Bitcoin node downloads and validates every block on the network.
2. Your Electrum server reads blocks from the node and builds an address-level index.
3. Your wallet connects to the Electrum server and queries balances, history, and UTXOs instantly.

The initial index build requires scanning the full blockchain, which can take hours or days depending on the implementation and your hardware. After that, the server stays in sync incrementally as new blocks arrive.

Options on StartOS

Fulcrum (Recommended)

• Author: Calin Culianu (cculianu)
• Language: C++
• StartOS: Available on the StartOS Marketplace

Fulcrum is a high-performance Electrum server written in C++. It is the recommended Electrum server for StartOS.

Why Fulcrum:

• Fast queries — Once indexed, address lookups and UTXO queries are consistently fast, even for addresses with large transaction histories.
• Full address index — Fulcrum builds a complete index of all addresses, so every wallet query is served from local data.
• Mature and stable — Actively maintained, widely deployed across the Bitcoin self-hosting community.
• Broad wallet support — Every wallet that speaks the Electrum protocol works with Fulcrum. See Bitcoin Wallets for a full list.

Trade-offs:

• Disk usage — The full address index requires significant disk space (roughly 60-100 GB on top of the blockchain itself).
• Initial sync time — Building the index from scratch takes time, typically several hours on modern hardware. Plan to let it run overnight after installation.

electrs

• Author: Blockstream
• Language: Rust

electrs is a lightweight Electrum server written in Rust. It takes a different approach than Fulcrum — instead of building a full persistent index, electrs uses a compact index and fetches some data from the Bitcoin node on demand.

Advantages:

• Lower disk usage — The compact index uses significantly less disk space than Fulcrum’s full index.
• Faster initial sync — The lighter index builds faster than a full address index.

Disadvantages:

• Slower queries — Some queries require on-the-fly lookups from the Bitcoin node, making them noticeably slower than Fulcrum, especially for addresses with many transactions.
• Not on the StartOS Marketplace — electrs is not currently available as a service on StartOS.

Comparison

For StartOS users, Fulcrum is the clear choice — it is the only Electrum server available on the StartOS Marketplace and provides the best query performance for everyday wallet use.

Connecting Wallets

Once Fulcrum is installed and synced on your StartOS server, wallets connect to it using an Electrum server address. Most wallets need just two pieces of information:

• Host — Your server’s address (local IP on your LAN, .local hostname, .onion address over Tor, or a clearnet address via VPN or reverse tunnel)
• Port — The Electrum protocol port (typically 50001 for TCP or 50002 for SSL)

For wallet-specific connection instructions, see Bitcoin Wallets.

Bitcoin Wallets

An index of Bitcoin wallets that support connecting to your own Bitcoin node (via RPC) or your own Electrum server (such as Fulcrum). Each entry lists supported platforms, connection method, Tor support, and links to upstream documentation.

For Lightning wallets that connect to your own LND or Core Lightning node, see Lightning Wallets.

Connection Methods

There are two ways a wallet can connect to your self-hosted Bitcoin infrastructure:

• Bitcoin RPC — The wallet connects directly to your Bitcoin node using its JSON-RPC interface. This gives the wallet full access to your node’s blockchain data without any additional indexing service.
• Electrum server — The wallet connects to an Electrum-protocol server (such as Fulcrum) that sits in front of your Bitcoin node. The Electrum server indexes the blockchain and provides fast address lookups. Most wallets use this method.

Summary

BitBoxApp

• Platforms: Android, iOS, Linux, macOS, Windows
• Connects to: Electrum server
• Tor: Yes — supports Tor proxy and .onion addresses natively

The BitBoxApp is the companion software for BitBox hardware wallets. It supports connecting to your own Electrum server via the app’s advanced settings.

• BitBoxApp downloads
• Connecting to your own full node

Bitcoin Keeper

• Platforms: Android, iOS
• Connects to: Electrum server
• Tor: Yes

Bitcoin Keeper is an open-source mobile wallet with multisig support. It provides an Electrum Server Management interface for connecting to your own server.

• Bitcoin Keeper website
• Source code

Blockstream App

• Platforms: Android, iOS, Linux, macOS, Windows
• Connects to: Electrum server
• Tor: Yes — built-in “Connect with Tor” toggle

Blockstream App supports connecting to your own Electrum server and has a built-in Tor toggle for private connections.

• Blockstream App downloads

BlueWallet

• Platforms: Android, iOS
• Connects to: Electrum server
• Tor: Yes — native Tor on both Android and iOS

BlueWallet is a popular mobile Bitcoin wallet that supports connecting to your own Electrum server. It can scan QR codes for Tor-based node connections.

• BlueWallet website
• Electrum server configuration

Bull Wallet

• Platforms: Android, iOS
• Connects to: Electrum server
• Tor: Yes

Bull Wallet by Bull Bitcoin is a privacy-focused mobile wallet that combines on-chain Bitcoin, Lightning (via Boltz atomic swaps), and Liquid support. It supports connecting to your own Electrum server and works as a companion app for hardware wallets with watch-only imports and air-gapped signing (Coldcard Q).

• Bull Wallet website
• Source code

BTCPay Server

• Platforms: Web (self-hosted)
• Connects to: Bitcoin RPC
• Tor: Yes — built-in Tor support in the Docker deployment

BTCPay Server is a self-hosted payment processor, but it also includes a full on-chain Bitcoin wallet backed by your Bitcoin node. The built-in wallet supports hot wallets, watch-only wallets (xpub import with external signing via PSBT), coin selection, and payment batching. BTCPay Server is also available as a service on the StartOS Marketplace.

BTCPay Server also supports Lightning — see Lightning Wallets.

• BTCPay Server website
• Wallet documentation

Electrum

• Platforms: Android, Linux, macOS, Windows
• Connects to: Electrum server
• Tor: Yes — supports SOCKS5 proxy for Tor connections

Electrum is the original Electrum-protocol wallet. Connecting to your own Electrum server is a core feature — simply specify your server address in the network settings.

• Electrum downloads
• Using Electrum through Tor

Envoy

• Platforms: Android, iOS
• Connects to: Electrum server
• Tor: Yes — built-in Tor toggle (“Improved Privacy” mode)

Envoy is the companion app for the Passport hardware wallet by Foundation Devices, but also works as a standalone wallet. It supports connecting to your own Electrum server with native Tor support.

• Envoy downloads
• Envoy setup documentation

FullyNoded

• Platforms: iOS, macOS
• Connects to: Bitcoin RPC
• Tor: Yes — integrated Tor support

FullyNoded connects directly to your Bitcoin node over Tor using the RPC interface. No Electrum server required. Connection can be configured via QR code or manual entry.

• FullyNoded website
• Connect your node

Liana

• Platforms: Linux, macOS, Windows
• Connects to: Both — Electrum server and Bitcoin RPC
• Tor: No — external Tor proxy required for remote connections

Liana is focused on timelocked recovery and inheritance use cases. It supports both Electrum server and Bitcoin RPC connections, and can install a pruned Bitcoin node automatically for local use.

• Liana website
• Source code

Nunchuk

• Platforms: Android, iOS, Linux, macOS, Windows
• Connects to: Both — Electrum server and Bitcoin RPC
• Tor: Yes

Nunchuk is a multisig-focused wallet available on all major platforms. It supports connecting to your own Electrum server or Bitcoin node.

• Nunchuk website
• Custom node connection (v0.9.7)

Sparrow

• Platforms: Linux, macOS, Windows
• Connects to: Both — Electrum server and Bitcoin RPC
• Tor: Yes — bundled internal Tor proxy that activates automatically for .onion addresses

Sparrow is a full-featured desktop wallet widely regarded as the power-user choice. It supports both Bitcoin RPC and Electrum server connections. When you enter a .onion address, Sparrow automatically routes through its built-in Tor proxy.

• Sparrow downloads
• Connect to your node

Trezor Suite

• Platforms: Linux, macOS, Windows
• Connects to: Electrum server
• Tor: Yes — desktop app supports .onion addresses for custom backends

Trezor Suite is the companion software for Trezor hardware wallets. The desktop app supports connecting to a custom Electrum server backend. The web app and mobile app (Trezor Suite Lite) do not support custom backends.

• Trezor Suite downloads
• Connect Trezor Suite to your own node
• Full node via Electrum server

Wasabi

• Platforms: Linux, macOS, Windows
• Connects to: Bitcoin RPC
• Tor: Yes — Tor is built-in and enabled by default for all network traffic

Wasabi Wallet is a privacy-focused desktop wallet. It routes all traffic through Tor by default and supports connecting to your own Bitcoin node via RPC.

• Wasabi downloads
• Bitcoin full node integration

Lightning Wallets

An index of Lightning wallets and management tools that support connecting to your own LND or Core Lightning node. This includes both native apps (mobile/desktop) and web-based tools that can be self-hosted or installed as services on StartOS.

For on-chain Bitcoin wallets that connect to your own Bitcoin node or Electrum server, see Bitcoin Wallets.

Node Implementations

The wallets and tools below connect to one or more of these Lightning node implementations:

• LND — The most widely supported implementation. Wallets connect via its REST or gRPC API using a macaroon for authentication. LND also supports Lightning Node Connect (LNC), a secure remote connection method that works without opening ports or using Tor.
• Core Lightning (CLN) — Blockstream’s implementation. Wallets connect via CLNRest (the built-in REST plugin) or gRPC.
• Eclair — ACINQ’s implementation. Fewer wallets support it directly.

Lightning Node Connect

Lightning Node Connect (LNC) is a connection protocol by Lightning Labs that lets you securely reach your LND node from anywhere without opening ports or configuring Tor. It works by establishing an end-to-end encrypted connection through a relay server using a short pairing phrase. LNC requires Lightning Terminal (litd) running alongside your LND node.

LNC is supported by Zeus and Lightning Terminal’s web UI.

• How LNC works
• Source code

Summary

Native Apps

Web-Based (Self-Hosted)

These tools run as web applications on your server. Several are available as services on the StartOS Marketplace.

Native Apps

BitBanana

• Platforms: Android
• Connects to: LND, Core Lightning
• Tor: Yes — native Tor support

BitBanana is the actively maintained successor to the Zap Android wallet. It connects to LND via lndconnect URI (REST) and to Core Lightning via cln-grpc. Supports BOLT 12, coin control, and NFC.

• BitBanana website
• Connect a Lightning node

BlueWallet

• Platforms: Android, iOS
• Connects to: LND (via LNDHub)
• Tor: Yes — available in network settings

BlueWallet connects to LND through LNDHub, a middleware layer that sits on top of your LND node and provides account-based access. This makes it good for multi-user setups where one node serves several wallets. LNDHub requires LND and Redis as dependencies.

Note

BlueWallet shut down their hosted custodial LNDHub service in 2023, but the self-hosted open-source LNDHub software still works. You can also use the LNDHub extension in LNbits as an alternative backend.

• BlueWallet website
• LNDHub documentation

FullyNoded

• Platforms: iOS, macOS
• Connects to: LND, Core Lightning
• Tor: Yes — Tor is a core design principle; all connections route through Tor

FullyNoded is primarily a Bitcoin wallet, but also supports connecting to LND (via REST over Tor) and Core Lightning. Apple ecosystem only.

• FullyNoded website
• Lightning documentation

Zeus

• Platforms: Android, iOS
• Connects to: LND, Core Lightning, Eclair, LNDHub
• Tor: Yes — native on Android; experimental on iOS

Zeus is the most versatile mobile Lightning wallet, supporting three node implementations plus LNDHub accounts. It connects to LND via REST or Lightning Node Connect (LNC), Core Lightning via CLNRest, and Eclair via REST. Zeus can also run an embedded LND node on-device without a remote connection.

• Zeus website
• Remote connection guides

Web-Based (Self-Hosted)

Alby Hub

• Platforms: Web (self-hosted), also available as a desktop app on Linux, macOS, Windows
• Connects to: LND (external node via REST), or runs an embedded LDK node
• Tor: Yes — works with Tor hidden services when self-hosted
• StartOS: Available on the StartOS Marketplace

Alby Hub bridges Lightning to the Nostr ecosystem via the Nostr Wallet Connect (NWC) protocol. It can connect to your existing LND node or run its own embedded LDK node. Useful for connecting Lightning payments to Nostr clients, podcasting apps, and web applications.

• Alby Hub website
• Setup guide
• Source code

BTCPay Server

• Platforms: Web (self-hosted)
• Connects to: LND, Core Lightning, Eclair
• Tor: Yes — built-in Tor support in the Docker deployment
• StartOS: Available on the StartOS Marketplace

BTCPay Server is a self-hosted payment processor for merchants. Its Lightning integration supports all three major node implementations. Use it to accept Lightning payments through invoices, point-of-sale, e-commerce plugins (WooCommerce, Shopify), and more.

BTCPay Server also has a built-in on-chain wallet — see Bitcoin Wallets.

• BTCPay Server website
• Lightning documentation

CLN Application

• Platforms: Web (self-hosted)
• Connects to: Core Lightning only
• Tor: Depends on host platform configuration
• StartOS: Included with Core Lightning on the StartOS Marketplace

The CLN Application is the official Blockstream-maintained web dashboard for Core Lightning nodes. It connects via CLNRest and provides a clean interface for channel management, payments, and node monitoring. On StartOS, it is bundled with the Core Lightning service.

• Source code

Lightning Terminal

• Platforms: Web (self-hosted and hosted)
• Connects to: LND only
• Tor: Yes
• StartOS: Available on the StartOS Marketplace

Lightning Terminal (LiT) is Lightning Labs’ web dashboard for LND nodes. It bundles Loop (Lightning-to-on-chain swaps), Pool (liquidity marketplace), and Taproot Assets into a single interface. The underlying daemon (litd) also enables Lightning Node Connect (LNC), allowing secure remote access to your node without opening ports or using Tor.

Lightning Labs also hosts a web UI at terminal.lightning.engineering that connects to your node via LNC.

• Lightning Terminal documentation
• Source code

LNbits

• Platforms: Web (self-hosted)
• Connects to: LND, Core Lightning, Eclair
• Tor: Yes — can be exposed as a Tor hidden service
• StartOS: Available on the StartOS Marketplace

LNbits is an accounts and extensions platform that sits on top of your Lightning node. It creates isolated wallet accounts (useful for multi-user setups) and has a rich extension system including paywall, point-of-sale, tipping, and an LNDHub extension that lets you serve BlueWallet and Zeus users from your node.

• LNbits website
• Backend wallet configuration
• Source code

RTL

• Platforms: Web (self-hosted)
• Connects to: LND, Core Lightning, Eclair
• Tor: Yes — can be exposed as a Tor hidden service
• StartOS: Available on the StartOS Marketplace

RTL (Ride The Lightning) is the most widely supported web UI for Lightning node management. It supports all three major implementations and provides full channel management, payment tracking, routing fee configuration, and Loop/Pool integration.

• RTL website
• Source code

ThunderHub

• Platforms: Web (self-hosted)
• Connects to: LND only
• Tor: Yes — can be exposed as a Tor hidden service
• StartOS: Available on the StartOS Marketplace

ThunderHub is a modern web UI for LND nodes with strong channel balancing tools, multi-account support, and a polished interface. If you run LND, ThunderHub is a strong alternative to RTL.

• ThunderHub website
• Documentation
• Source code

Migrating LND to StartOS

How to transfer your LND node — including on-chain funds and open Lightning channels — from another platform to StartOS without closing channels.

Warning

After migrating your LND wallet to StartOS, never restart your old node. Turning on your old node can broadcast old channel states and result in loss of funds.

Supported Source Platforms

StartOS’s LND service can pull wallet and channel data directly from the following platforms over your local network:

• Umbrel (1.x and 0.5.x)
• RaspiBlitz
• myNode

If your source platform is not listed, you may still be able to migrate by manually copying the LND data directory. See Manual Migration below.

Prerequisites

• Both devices (source node and StartOS server) must be on the same local network.
• Your source node must be running and accessible at the time of migration.
• You need your source node’s local IP address (check your router’s admin page if unsure).
• You need your source node’s password(s) for SSH or API access, depending on the platform.

Migration Steps

1. Install LND on StartOS

Install LND from the StartOS Marketplace, but do not start it. Starting the service creates a new wallet, which prevents the migration action from running. If you have already started LND, uninstall it and install a fresh copy.

2. Run the Migration Action

Open LND on your StartOS server and go to Actions. Select the migration action that matches your source platform:

• Migrate from Umbrel 1.x
• Migrate from Umbrel 0.5
• Migrate from RaspiBlitz
• Migrate from myNode

Enter your source node’s local IP address and any required passwords when prompted.

3. Wait for the Migration to Complete

The migration will copy your LND wallet, channel database, and configuration from the source node. This may take several minutes depending on the size of your channel database and network speed.

4. Disconnect the Old Node

Once the migration is complete, shut down and disconnect your old node before proceeding. This is critical — running two nodes with the same channel state will result in force-closures and potential loss of funds.

5. Start LND on StartOS

With the old node safely shut down, start LND on your StartOS server. It will begin syncing and reconnecting to your peers with the migrated channel state.

Warning

Never restart your old node after the migration has completed. If you need to go back to your old node for any reason, do not start LND on StartOS first.

Manual Migration

If your source platform is not listed above, you can migrate by manually copying the LND data directory. The key files are:

• wallet.db — Your on-chain wallet
• channel.backup — Static channel backups (SCB)
• data/graph/mainnet/channel.db — Channel state database

Note

Manual migration carries more risk than the built-in actions. If you are unsure about the process, consider closing your channels on the old node first, then restoring from seed on StartOS. This is safer but requires re-opening channels.

Troubleshooting

“Import action not available” — LND has already been started and a wallet exists. Uninstall LND and install a fresh copy from the StartOS Marketplace.

Migration times out or fails — Ensure both devices are on the same local network and that the source node is running. Double-check the IP address and passwords.

Channels force-close after migration — This usually means the old node was restarted after migration, or the channel database was corrupted during transfer. Unfortunately, force-closed channels cannot be recovered — the funds will be returned to your on-chain wallet after the timelock expires.