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 most wallets need one, and whether you can do without.

• Connecting a Wallet — The steps every wallet has in common: getting the address, why every connection is SSL, and how to make your wallet trust your server’s certificate.

• Bitcoin Wallets — On-chain wallets that connect to your own Bitcoin node or Electrum server, with the platforms each supports and where its connection settings live.

• Lightning Wallets — How LND and Core Lightning hand a wallet its connection, and the apps and dashboards that take it — Zeus, BitBanana, RTL, LNbits, Alby Hub, and more.

• Migrating LND to StartOS — How to transfer your LND node from Umbrel, myNode, or another StartOS server 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

The Bitcoin service on StartOS is available in multiple flavors (implementations). The service is called Bitcoin regardless of which flavor you install — the flavor determines the underlying software.

Both follow the same blockchain and expose the same RPC interface used by wallets and Electrum servers, so switching between them keeps the chain you have already synced. Both registries ship with StartOS — click “Switch” beneath the current registry title in the Marketplace sidebar to move between them. Community Registry services are not maintained, recommended, or supported by Start9.

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, for services that read blocks over Bitcoin’s RPC interface, with on-demand block fetching.
• Not every service is covered — Electrum servers and block explorers still need an archival node, even on StartOS. See What on-demand fetching does not cover.

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.

A fetched block is not taken on trust. Before it is served, the proxy checks that it hashes to the block that was asked for, that its merkle root commits to the transactions it carries, and that its witness commitment is satisfied — so a peer can neither substitute a different block nor strip data out of one.

This means:

• Multiple downstream services work simultaneously — LND, Core Lightning, BTCPay Server, and any other service that reads blocks over Bitcoin’s RPC interface 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. Recently fetched blocks are held in memory, so asking for the same one again is answered without going back out to the network. In practice this is rare — most services only need recent blocks during normal operation.

What on-demand fetching does not cover

The proxy answers over Bitcoin’s RPC interface. Three things read the chain some other way, and all of them need an archival node on StartOS — each raises a task on the Bitcoin service asking you to turn pruning off.

• Fulcrum — it finds transactions through Bitcoin’s transaction index, which records where in a block file each one sits. A pruned node cannot keep that index; Bitcoin refuses to run the two together. Fulcrum’s author requires it deliberately: without it the node reads and searches an entire block for every transaction a wallet asks for, which does not hold up when several wallets are syncing at once.
• electrs — it pulls whole blocks over Bitcoin’s peer-to-peer interface rather than its RPC, so the proxy is not in that path. Upstream has kept it that way partly on privacy grounds: on a pruned node, the blocks the server went out to fetch would track which addresses your wallet had asked about.
• Block explorers — Mempool answers arbitrary queries across the whole chain and needs it on disk.

Note

A community-maintained fork of electrs, electrs-pruned, routes the reads the proxy can answer through it and does work against a pruned node. It is not a Start9 package — not in the marketplace, not audited by us, and installed by sideloading. It carries the privacy trade-off above, and its first index build against an already-pruned node takes over a day, considerably longer if Bitcoin reaches the network only over Tor.

Managing Pruning on StartOS

Pruning is controlled from the Bitcoin service’s Actions menu: Services > Bitcoin > Actions > Other. From there you can enable or disable pruning and set the prune target (the amount of block data to retain, in MB).

Automatic pruning on small disks

If your server’s total disk capacity is under 900 GB, StartOS enables pruning by default and enforces it — you cannot disable it. The full blockchain (600+ GB and growing) would consume too much of the available space, leaving insufficient room for other services and system operations. On these drives, pruning is not optional.

If your disk is 900 GB or larger, pruning is off by default and you can enable or disable it freely.

Which Should You Choose?

For most StartOS users, a pruned node is the best choice. Thanks to on-demand block fetching, a wallet that talks to Bitcoin directly and a Lightning node beside it both work against a pruned node exactly as they would against an archival one, at a fraction of the disk usage.

Choose an archival node if:

• You want to run an Electrum server — Fulcrum or electrs. Most wallets reach a node through one, so this is the common reason to need an archival node.
• You want to run a block explorer like Mempool.
• You have the disk space (900 GB or more) 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, indexing the blockchain so wallets can look up balances, history, and unspent outputs for an address instantly. Most Bitcoin wallets reach a self-hosted node this way rather than over Bitcoin RPC.

On StartOS that server is Fulcrum. Once it is installed and synced, see Connecting a Wallet.

Why you need one

A Bitcoin node stores every block ever produced, but it keeps no index of which addresses own which coins. Asked “what is the balance of this address?”, it would have to walk the entire chain. An Electrum server solves that by building a persistent index from addresses to their transactions and unspent outputs, and serving it over the Electrum protocol — which wallets already know how to speak.

┌──────────┐    Electrum     ┌──────────────────┐      RPC       ┌───────────────┐
│  Wallet  │ ─── protocol ──▶│  Electrum server │ ──── + P2P ───▶│ Bitcoin node  │
└──────────┘                 │  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.

Building that index the first time means reading the whole chain, which takes hours. After that the server keeps up incrementally as blocks arrive.

Fulcrum

Fulcrum builds a complete address index, so every wallet query is answered from local data. Queries stay fast even for addresses with long transaction histories, which is where lighter Electrum servers struggle. It is actively maintained and widely deployed across the self-hosting community.

The cost is disk and patience: the index runs to hundreds of gigabytes on top of the chain itself, and the first build takes many hours. Install it, then leave it overnight. Fulcrum’s own instructions in StartOS carry its exact requirements and settings.

It also needs your Bitcoin node to be archival rather than pruned — see Archival vs Pruned Nodes. StartOS prompts you on the Bitcoin service if anything needs changing.

Wait for Fulcrum’s Sync Progress health check to report Synced before pointing a wallet at it. A wallet connected to a half-built index shows a partial balance, which is alarming and entirely temporary.

• Fulcrum source and documentation

Do you need one at all?

Not if your wallet talks to Bitcoin directly. Sparrow, FullyNoded, Wasabi and BTCPay Server all connect over Bitcoin’s RPC interface, with no indexer in the picture and no extra disk.

The difference shows up when you import an existing wallet. An Electrum server finds its history in seconds; a bare Bitcoin node has to walk the block range, which takes hours and cannot reach past a pruned node’s horizon. Day-to-day use of a wallet that is already imported is much the same either way.

See Connecting a Wallet for the full comparison.

Connecting a Wallet

Every wallet that talks to your own node needs the same four things: an address, a port, a way to trust your server’s certificate, and — if you are away from home — a route in. This page covers all four once, so the per-wallet pages only have to tell you where the settings live.

Start here, then look up your wallet in Bitcoin Wallets or Lightning Wallets.

Which connection do you need?

Two different things on your server can serve a wallet, and which one you want depends on the wallet.

Most wallets speak the Electrum protocol, so most people install Fulcrum and never think about RPC. Bitcoin RPC is the right answer when a wallet only supports it, or when you want to avoid the index’s disk cost and are not importing wallets with long histories.

Some wallets — Sparrow, Nunchuk, Liana — will take either. Prefer the Electrum server if you have one running: address lookups come from a purpose-built index instead of a chain scan.

Getting the address

On your server, open your Electrum server and copy an address from its Electrum (SSL) interface. Bitcoin’s RPC interface works the same way.

The address already contains the host and the port, in the form ssl://<host>:<port>. Copy it; do not retype it from memory.

Warning

Take the port from the address. StartOS assigns the external port when the service is installed and never changes it afterwards, so it is a property of your server rather than of the software. 50002 is a preference, not a guarantee. Wallet guides that tell you to enter 50001 or 50002 are describing a hand-configured server, not this one.

Which address you copy depends on where the wallet is:

• LAN IP (192.168.x.x) — a phone or laptop on your home network. The most reliable choice.
• .local hostname (adjective-noun.local) — the same, but it survives your router handing the server a new IP. Needs mDNS, which some networks and VPNs block.
• .onion — reachable from anywhere, no port forwarding, no domain. Requires Tor at both ends.
• Custom domain — reachable from anywhere and faster than Tor. Requires setting one up.

See Reaching your server from outside your home below for the last two.

Every address is ssl://

StartOS terminates TLS in front of the Electrum server and exposes only the encrypted endpoint. There is no plaintext port to connect to from off the server, on any address — LAN, .local, Tor, and custom domains alike.

So in your wallet, SSL/TLS has to be on. How you say that varies:

Note

Getting this wrong rarely produces an error that says so. Sparrow reports “Retries exhausted”; most wallets just show a spinner or a red dot. If a connection fails and you have not explicitly turned SSL on, that is the first thing to check.

This also means older walkthroughs no longer apply. Guides that tell you to append :t (plain TCP) or connect to port 50001 were written when StartOS exposed a plaintext Electrum port. It does not.

Making your wallet trust the certificate

The certificate StartOS serves is issued by your server’s own root certificate authority — one it generated for itself when you set it up. It is a real certificate and it is doing real work, but no wallet has heard of the authority that signed it, so every wallet has to be told to trust it once.

There are four ways that happens, and which one applies is a property of the wallet:

1. The wallet uses your device’s trust store. Install the StartOS Root CA on the device, exactly as you did to reach the dashboard in your browser — see Trusting Your Root CA. Nothing further in the wallet.

2. The wallet offers to fetch and pin the certificate. The BitBoxApp does this: it shows a Download remote certificate step before it will check the connection. Accept it.

3. The wallet keeps its own certificate store. Sparrow has a certificate field in its server settings; Electrum reads a file you place on disk. See The Electrum desktop wallet below.

4. You attached a custom domain with an ACME certificate. Then the certificate is signed by a public authority, every wallet already trusts it, and there is nothing to do.

Note

Tor does not exempt you from this. A web interface reached at a .onion address is served over plain HTTP, because Tor already encrypts and authenticates the connection — which is why the Root CA guide says you don’t need it for Tor. The Electrum interface is different: it is TLS on every address, including .onion, so a wallet connecting over Tor still has to trust the certificate.

The Electrum desktop wallet

Electrum is the one wallet that needs a file placed by hand, and it is worth understanding why, because the failure is silent.

Electrum checks a server against a bundled list of public certificate authorities, and when that check fails it looks at how it failed. A server presenting a self-signed certificate is one Electrum pins on the spot and connects to. Your server presents something different — a certificate signed by an intermediate, which is signed in turn by your server’s own root authority — and that is a different failure, which Electrum treats as a server it cannot use. It never gets as far as offering to pin anything. The behaviour is tracked upstream as spesmilo/electrum#7459.

The fix is to give Electrum the authority instead of the certificate. Electrum loads the file at certs/<host> as a trust anchor, so putting your root CA there makes the whole chain verify — and keeps working when your server renews its certificate, which pinning would not.

1. Download your root CA from http://<your-server>/static/local-root-ca.crt — plain HTTP, and the same file the browser guide gives you.

2. Delete any file already sitting at <data-dir>/certs/<host>. A leftover from an earlier attempt stops everything below from working and reports nothing. An empty file is the worst case: to Electrum it means “this server is publicly signed”, so it goes back to the public authority list and fails again.

3. Save the certificate as <data-dir>/certs/<host>, with no file extension. <host> must match exactly what you type into Electrum — reaching the same server at 192.168.1.5 and at my-server.local needs one file under each name.

4. In Electrum, go to Tools → Network. Set Connection mode to Connect only to a single server so Electrum cannot fall back to a public one, and enter the server as <host>:<port>:s, taking the port from the interface address.

<data-dir> is:

To connect over Tor as well, switch to the Proxy tab, enable the proxy, and point it at 127.0.0.1 port 9050 (or 9150 if you are using Tor Browser’s).

Tip

Do this once per address you use, not once per session. If Electrum stops connecting after a while, check whether your root CA has expired — Electrum deletes the pinned file when the certificate in it is out of date, and then falls back to failing against the public authority list.

Reaching your server from outside your home

On your home network, the LAN IP or .local address is all you need. To reach your node while away, pick one:

• Tor. Install the Tor service from the marketplace, then add an onion address to the Electrum interface. No port forwarding, no domain, no static IP — but Tor is slow, and the wallet needs its own Tor connection: a SOCKS proxy on desktop (127.0.0.1:9050), or Orbot on mobile. Some wallets bundle their own Tor and need no proxy setup at all. See Tor.

• A custom domain. Attach one to the interface and, if you request an ACME certificate, every wallet trusts it with no further setup. Faster and more reliable than Tor. See Public Access.

• A VPN back to your home network. Then the LAN address keeps working as though you were home — though .local names often do not survive a VPN, so use the IP. See Remote Access.

Connecting over Bitcoin RPC instead

A wallet that talks to Bitcoin directly needs an address from Bitcoin’s RPC interface plus a username and password, which the Bitcoin service’s Generate RPC User Credentials action mints for you. (Services running on the server never need this — they configure themselves.)

StartOS serves that interface over TLS on LAN and clearnet addresses with the same certificate as everything else, so the trust step above applies here too. Onion addresses are served over plain HTTP and need no certificate.

Expect wallet imports and rescans to be slow: a Bitcoin node keeps no per-address index, so finding an existing wallet’s history means walking the block range. On a pruned node, history older than the prune horizon cannot be rescanned at all. Day-to-day use of a wallet that is already imported is unaffected.

When it doesn’t connect

If the service itself is unhealthy, start there rather than in the wallet — an Electrum server still building its index answers slowly or not at all, and that looks exactly like a connection problem.

Bitcoin Wallets

Bitcoin wallets that can be pointed at your own node — either through an Electrum server such as Fulcrum or directly over Bitcoin RPC. Each entry gives the platforms, the connection method, and where the setting lives in that wallet.

Read Connecting a Wallet first: the address, the port, the SSL requirement, and the certificate step are the same for every wallet on this page, and are not repeated in each entry. For Lightning, see Lightning Wallets.

Summary

Apps you run on your own devices

Wallets that run on your server

These install from the StartOS Marketplace and reach Bitcoin over the server’s internal network, so there is no address, port, or certificate to configure — and no wallet traffic leaving your house at all. Each one’s own instructions in StartOS cover its setup.

Apps you run on your own devices

BitBoxApp

• Platforms: Android, iOS, Linux, macOS, Windows
• Connects to: Electrum server
• Certificate: Handled in-app — it offers to fetch your server’s certificate

The companion app for BitBox hardware wallets, and usable on its own. Of the wallets here it has the smoothest path to a private server: it fetches and trusts the certificate itself, with no OS-level or file-level step.

To connect:

1. Go to Settings → Advanced settings → Connect your own full node.
2. Paste the host and port from your Electrum (SSL) interface address as host:port. Upstream warns not to substitute 50001 or 50002 for the port your node reports — on StartOS that warning is exactly right.
3. Choose Download remote certificate when prompted, then Check to test, then Add.

For Tor, enable the Tor proxy under Advanced settings first (127.0.0.1:9050, or 127.0.0.1:9150 for Tor Browser’s), restart the app fully, then add the .onion endpoint. If the check fails immediately after enabling Tor, the proxy has not finished connecting — restart and retry.

• BitBoxApp downloads
• Connecting to your own full node

Bitcoin Keeper

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

An open-source mobile wallet built around multisig and inheritance, with an Electrum server management screen for pointing it at a server of your own. Add your Electrum (SSL) address there; Keeper requires SSL, which is what StartOS serves.

• Bitcoin Keeper website
• Source code

Blockstream App

• Platforms: Android, iOS, Linux, macOS, Windows
• Connects to: Electrum server

Formerly Blockstream Green. It supports a personal Electrum server and has a built-in Tor toggle, so no separate proxy is needed.

To connect (desktop):

1. Open App Settings (the gear icon) and choose Network.
2. Turn on Connect with Tor if you are using a .onion address.
3. Go back, then open Custom servers and validation and turn on Choose the Electrum servers you trust.
4. Paste your address into Bitcoin Electrum Server.

To connect (mobile): open App Settings, turn on Connect with Tor if needed, turn on Personal Electrum Server, paste the address into Bitcoin Electrum server, and Save.

Note

Recent versions expose a TLS toggle for personal Electrum servers — leave it on, since StartOS serves TLS only. Whether the app will accept a certificate signed by your server’s own authority has not been verified against a StartOS server; if it refuses, a custom domain with an ACME certificate sidesteps the question entirely.

• Blockstream App downloads

BlueWallet

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

A popular and approachable mobile wallet. Set the server under Settings → Network → Electrum server — either type the host and port, or use Scan or import a file to scan the QR code from your Electrum interface. Save, then restart the app.

Warning

BlueWallet over Tor has a long history of connecting once and then dropping, with no error that explains why. Orbot must be installed and running before it will work at all, and even then StartOS users report repeat disconnections. If you are connecting from outside your home and BlueWallet will not stay up, that is a known rough edge rather than something misconfigured on your server — Sparrow and Nunchuk are the usual fallbacks.

• BlueWallet website
• Electrum servers pool

Bull Wallet

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

Bull Bitcoin’s mobile wallet, combining on-chain Bitcoin, Lightning (via Boltz swaps), and Liquid. It supports a custom Electrum server and works as a companion for hardware wallets, with watch-only imports and air-gapped signing for the Coldcard Q.

• Bull Wallet website
• Source code

Electrum

• Platforms: Android, Linux, macOS, Windows
• Connects to: Electrum server
• Certificate: Needs a file placed by hand

The original Electrum-protocol wallet, and the one wallet here that will not connect to a StartOS server until you give it your root CA on disk. The reason and the full procedure are on Connecting a Wallet — do that first, then set the server under Tools → Network as <host>:<port>:s with Connection mode set to Connect only to a single server.

• Electrum downloads
• Using Electrum through Tor

Envoy

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

The companion app for Foundation’s Passport hardware wallet, also usable standalone, with a built-in Tor toggle. Add your Electrum (SSL) address in Envoy’s settings; a red shield in the app means it cannot reach the custom server you configured.

• Envoy downloads
• Envoy settings

FullyNoded

• Platforms: iOS, macOS
• Connects to: Bitcoin RPC
• Certificate: None needed over Tor

Talks to Bitcoin directly over its RPC interface, with Tor integrated — no Electrum server involved. Because it connects to a .onion address, which StartOS serves without TLS, there is no certificate step.

To connect: run Generate RPC User Credentials on the Bitcoin service, then add a node in FullyNoded with Bitcoin’s .onion RPC address and those credentials.

• FullyNoded website
• Connect your node

Liana

• Platforms: Linux, macOS, Windows
• Connects to: Electrum server or Bitcoin RPC

Built around timelocked recovery and inheritance — spending paths that unlock after a period of inactivity. It takes either backend, and will install a pruned node of its own if you have none; on StartOS, point it at the node you already run instead. Tor needs an external proxy.

• Liana website
• Source code

Nunchuk

• Platforms: Android, iOS, Linux, macOS, Windows
• Connects to: Electrum server or Bitcoin RPC

A multisig- and inheritance-focused wallet on every major platform, and one of the more reliable choices for a private server.

To connect: open Network Settings — under your profile on mobile, and on desktop under Settings → Network settings, reached from your profile picture — then put your address in Mainnet server, keeping the ssl:// prefix:

ssl://adjective-noun.local:50002

For a .onion address, also turn on Enable TOR proxy on the same screen, and make sure Tor is running on the device. Save and restart Nunchuk.

• Nunchuk website
• Source code

Sparrow

• Platforms: Linux, macOS, Windows
• Connects to: Electrum server or Bitcoin RPC
• Certificate: Accepts one, or takes a .crt file in its server settings
• Tor: Bundled — .onion addresses work with no proxy setup

The power-user desktop wallet, and the least painful of the desktop options to point at a StartOS server: it will connect to an unrecognised certificate, and it routes .onion addresses through its own Tor daemon automatically.

To connect:

1. Go to File → Preferences → Server (on first run Sparrow takes you straight there).
2. Choose Private Electrum.
3. Enter the host in URL and the port from your Electrum interface address.
4. Turn Use SSL on.
5. Click Test Connection.

Optionally supply your root CA in the certificate field on the same screen. Sparrow will connect without it, but pinning the authority means a swapped certificate is caught rather than silently accepted.

If you are using your own Tor daemon rather than Sparrow’s — or routing through a proxy for another reason — enable Use Proxy with localhost and port 9050. Leave it off otherwise.

To use Bitcoin RPC instead, choose Bitcoin Core on the same screen and supply the RPC address with the credentials from Generate RPC User Credentials.

• Sparrow downloads
• Connect to Bitcoin Core

Trezor Suite

• Platforms: Linux, macOS, Windows (desktop), Android, iOS (mobile)
• Connects to: Electrum server

The companion software for Trezor hardware wallets. A custom Electrum backend replaces Trezor’s own servers, so your addresses stop being queried against them.

To connect: go to Settings → Networks, click the sliders icon next to Bitcoin, and enter your server in host:port:protocol form with s for SSL:

adjective-noun.local:50002:s

For a .onion address, turn on Tor in Trezor Suite first — it will prompt you if you have not.

• Trezor Suite downloads
• Full node via Electrum server

Wasabi

• Platforms: Linux, macOS, Windows
• Connects to: Bitcoin RPC
• Tor: Built-in and on by default for all traffic

A privacy-focused desktop wallet built around coinjoin. It finds your transactions using BIP158 block filters rather than an address index, so it wants Bitcoin’s RPC rather than an Electrum server — and it needs block filters turned on, which is an option under Bitcoin’s Other Settings.

• Wasabi downloads
• Using a Bitcoin full node

Wallets that run on your server

BTCPay Server

• Connects to: Bitcoin RPC

A self-hosted payment processor with a capable on-chain wallet attached: hot wallets, watch-only wallets from an xpub with PSBT signing elsewhere, coin selection, and payment batching. Install it and it wires itself to Bitcoin — there is nothing to configure.

BTCPay also handles Lightning; see Lightning Wallets.

• BTCPay Server website
• Wallet documentation

Jam

• Connects to: Bitcoin RPC

A web interface for JoinMarket: collaborative transactions that break the common-input heuristic, and the option to earn fees by offering liquidity to other traders. Tor runs inside it, so market connectivity needs no setup.

Jam imports its wallet into Bitcoin and rescans the chain, so it needs an archival node — see Archival vs Pruned Nodes.

• Jam documentation

Lightning Wallets

Wallets and management tools that drive a Lightning node you run yourself — LND or Core Lightning on StartOS. Some are apps on your phone or laptop; others install onto the server and are reached in a browser.

Connecting to a Lightning node is not like connecting to an Electrum server: instead of a host and a port, your node hands you a single URI that already contains its address and a credential. Start with Connecting to your node below, then find your wallet. For on-chain wallets, see Bitcoin Wallets.

Node implementations

• LND — the most widely supported. Wallets connect over its REST or gRPC API, authenticating with a macaroon. Also supports Lightning Node Connect, which reaches your node without opening ports or using Tor.
• Core Lightning (CLN) — Blockstream’s implementation. Wallets connect over CLNrest (its built-in REST plugin) or gRPC, authenticating with a rune. Ships with its own web dashboard on StartOS.
• Eclair — ACINQ’s implementation. Not packaged for StartOS; a couple of the tools below support it if you run one elsewhere.

Connecting to your node

LND

LND publishes two connection interfaces, REST and gRPC LND Connect. Each carries an lndconnect:// URI that you copy or scan as a QR code, and which already contains the address, the certificate details the client needs, and your credential — so there is nothing else to fill in.

Warning

That URI embeds your admin macaroon, which is full control of the node and its funds. Treat it exactly like a password: never paste it into a chat, a screenshot, or a support ticket. LND’s own instructions cover what to do if one is exposed.

Which interface to use depends on the wallet:

• REST — what most mobile wallets want. StartOS serves it with your server’s own certificate, so leave certificate validation on in the wallet and install the StartOS Root CA on the device, exactly as you did for the dashboard in your browser. A custom domain with an ACME certificate needs no such step.
• gRPC LND Connect — for clients that speak gRPC. LND serves its own certificate here and the URI carries it, so the client can verify with nothing installed. That makes the URI long — copy it rather than scanning the QR, which will be dense and slow to read.

To reach your node from outside your home, add an onion address or a custom domain to the interface first, then take the URI: it is only as reachable as the address inside it, so a LAN address in a wallet you carry around stops working the moment you leave.

Core Lightning

Core Lightning authenticates with a rune rather than a macaroon, and its CLNrest interface publishes a URL with one already embedded — that single URL is usually all a wallet needs. If an app wants a rune supplied separately instead, the Create Rune action mints one.

The URL’s scheme tells the wallet which protocol to use:

As with LND’s URI, the embedded rune is a credential — anything holding it can spend.

Lightning Node Connect

Lightning Node Connect (LNC) is a Lightning Labs protocol that reaches your LND node through a relay using a short pairing phrase, end-to-end encrypted so the relay sees nothing. No port forwarding, no domain, no Tor.

It requires Lightning Terminal running alongside LND: generate a session with Admin permissions on Lightning Terminal’s Connect page, then pair the wallet with the phrase or QR it shows. Zeus and Lightning Labs’ own web terminal both support it.

• How LNC works

Summary

Apps you run on your own devices

Tools that run on your server

These install from the StartOS Marketplace and wire themselves to your node over the server’s internal network — no URI to paste, no certificate to trust, and no credential leaving the machine. Each one’s own instructions in StartOS cover its setup.

Apps you run on your own devices

BitBanana

• Platforms: Android
• Connects to: LND, Core Lightning
• Tor: Native

The actively maintained successor to the Zap Android wallet, connecting to LND by lndconnect:// URI over REST, and to Core Lightning over gRPC. Supports BOLT 12, coin control, and NFC.

To connect: open LND’s REST interface on your server and scan the QR into BitBanana.

• BitBanana website
• Connect a Lightning node

BlueWallet

• Platforms: Android, iOS
• Connects to: LND, through LNDHub

BlueWallet does not talk to LND directly. It talks to LNDHub, an account layer in front of a node — which makes it a reasonable choice when one node serves several people, and a poor one if you want the wallet to be your node.

Note

BlueWallet’s hosted LNDHub service shut down in 2023; the self-hosted software still works. On StartOS the practical route is LNbits, whose LNDHub extension serves BlueWallet from your own node.

• BlueWallet website
• LNDHub documentation

FullyNoded

• Platforms: iOS, macOS
• Connects to: LND, Core Lightning
• Tor: Integrated; everything routes through it

Primarily a Bitcoin wallet — see Bitcoin Wallets — with Lightning support alongside. Because it connects over Tor to a .onion address, there is no certificate step.

• FullyNoded website
• Lightning documentation

Zeus

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

The most capable mobile Lightning wallet, and the one with the most ways in. It can also run an embedded node on the phone itself, with no remote connection at all.

To connect, in Zeus go to Settings → Connect a node → +, choose your implementation, and take the matching credential from your server:

Enable Tor in Zeus only if you are actually using a .onion address. For a LAN or clearnet address, leave certificate validation on and install the StartOS Root CA on the phone.

• Zeus website
• Connecting Zeus to StartOS

Tools that run on your server

Alby Hub

• Connects to: LND, or its own embedded LDK node

Bridges Lightning to the Nostr ecosystem through Nostr Wallet Connect (NWC), letting Nostr clients, podcasting apps, and web apps spend from your node under permissions you set per app. Also available as a desktop app if you would rather not self-host it.

• Alby Hub website
• Setup guide

BTCPay Server

• Connects to: LND, Core Lightning, Eclair

A self-hosted payment processor: invoices, point-of-sale, and e-commerce plugins for WooCommerce, Shopify and others. Its Lightning integration supports all three implementations, and it also has a full on-chain wallet — see Bitcoin Wallets.

• BTCPay Server website
• Lightning documentation

CLN Application

• Connects to: Core Lightning only

Blockstream’s official web dashboard for Core Lightning. It is part of the Core Lightning service rather than a separate install, and is reached through that service’s Web UI interface.

• Source code

Lightning Terminal

• Connects to: LND only

Lightning Labs’ dashboard for LND, bundling Loop (swaps between channel and on-chain funds), Pool (a liquidity marketplace), and Taproot Assets. Its daemon also provides Lightning Node Connect, which is reason enough to install it even if you prefer another dashboard: LNC is what lets Zeus reach your node without an onion address or a domain.

• Lightning Terminal documentation

LNbits

• Connects to: LND, Core Lightning, Eclair

An accounts-and-extensions layer over your node. It carves out isolated wallets — useful for a household, a business, or anything you would rather not hand the admin macaroon — and its extensions cover paywalls, point-of-sale, tipping, and an LNDHub backend that serves BlueWallet and Zeus from your own node.

• LNbits website
• Backend wallet configuration

RTL

• Connects to: LND, Core Lightning, Eclair

Ride The Lightning: the broadest node-management web UI, and the only one here that covers all three implementations. Channel management, payment history, routing fee configuration, and Loop/Pool integration.

• RTL website
• 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
• myNode
• another StartOS server

If your source platform is not listed, see Other Platforms below.

Prerequisites

• Both devices (source node and StartOS server) must be on the same local network.
• Your source node must be running and reachable when you schedule the migration and when you start LND — the copy happens at startup.
• You need your source node’s local IP address or .local hostname (check your router’s admin page if unsure).
• You need the password the migration signs in with:

You do not need your source node’s LND wallet password. The migration reads it from the origin and carries it across, so StartOS can unlock the wallet you already have.

Migration Steps

1. Install LND on StartOS

Install LND from the StartOS Marketplace, but do not start it. LND posts two critical tasks on install and cannot be started until both are done — leave them for now.

The migration refuses to run if a wallet already exists on this server, so if you have already created one with Start Fresh, uninstall LND and install a fresh copy.

2. Schedule the Migration

Open LND on your StartOS server and run its Initialize Wallet task. Under Initialization Method, choose the option matching your source platform:

• Migrate from Umbrel
• Migrate from myNode
• Migrate from StartOS

Enter your source node’s address and password, then submit. The task signs in to your source node to verify the address and password work — a wrong password or unreachable node fails here, within seconds, and you can correct the details and run the task again. On success the migration is scheduled: nothing has been copied yet, and your source node is still running.

3. Choose a Bitcoin Backend

Complete LND’s second task by running Bitcoin Backend: pick Bitcoin if you run a Bitcoin node on this server (recommended), or Neutrino to use the built-in light client.

4. Start LND — This Runs the Migration

Start LND. The migration runs as part of startup: it stops the services on your source node, copies LND’s wallet and channel database across your local network, converts the database to LND’s current SQLite backend (Umbrel, myNode and pre-0.21 StartOS nodes all run the older bolt format), and then brings LND online. Watch its progress under Health Checks — first Wallet Import, then Database Conversion.

The copy and conversion together can take anywhere from a few minutes to several hours, depending on the size of your channel database and the speed of your network and the source node’s disk. Leave LND running until it comes online. Stopping LND mid-migration is safe — it picks up where it left off on the next start.

5. Disconnect the Old Node

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

The migration stops the source node’s services before copying — and on a StartOS source that stop persists across reboots — but only powering the device down guarantees it stays off. In particular, rebooting a migrated Umbrel or myNode brings its LND back.

LND will then sync and reconnect 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.

Other Platforms

There is no built-in migration for platforms outside the list above — including RaspiBlitz, which earlier StartOS releases supported and current ones do not.

The safe route from an unsupported platform is to close your channels on the old node first, letting the balances settle on-chain, and then recover the on-chain funds on StartOS. Run Initialize Wallet → Start Fresh on StartOS and send the funds over from your old wallet, or restore your old node’s seed into an on-chain wallet of your choice. This costs you your channels and the fees to re-open them, but it carries none of the force-close risk of moving channel state by hand.

Copying an LND data directory across by hand is possible — it is what the built-in migrations do — but there is no supported path for it, and a partial or inconsistent copy of a channel database force-closes channels rather than failing safely. If you intend to try it anyway, the source and destination paths each migration uses are documented in the LND package README.

Troubleshooting

The migration option is missing, or the task refuses to run — LND already has a wallet, or the service has been started. Uninstall LND and install a fresh copy from the StartOS Marketplace.

The task fails when submitted — StartOS could not sign in to your source node. Ensure both devices are on the same local network and the source node is running, then double-check the address and password and run the task again. Nothing has been copied at this point.

Wallet Import shows failure after starting LND — the source node stopped being reachable between scheduling and starting (powered off, address changed, or its services shut down by hand). The migration retries a few times on its own; if it keeps failing, LND stops itself and re-posts the Initialize Wallet task — bring the source node back online, run the task again with the corrected details, and start LND to retry.

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.