Lightning Network & Layer 2

How to Control Your Lightning Node From Your Phone

Dec 14, 2024 · 18 min read · Updated Latest correction
A hand holds a dark-screen phone beside a warm plaster doorway and stone sill.

Your phone can act as a remote control for a Lightning node you run at home: it sends and receives through the node’s channels while the keys and channel data stay on the node. The steps below use Zeus over Tor, which keeps your home IP address private and needs no port forwarding. Background on the trade-offs follows the steps.

Your phone with Zeus connects over Tor to the Lightning node in your home. The phone holds your node's address and a macaroon (a rune on Core Lightning) that sets what the phone may do, and no keys or channels; it asks, and the node answers. The node holds your keys and channels, makes every payment, runs the watchtower client once you turn it on, and writes channel.backup. Payments leave from the node to the Lightning network.
Your phone only asks; your node does the work. Losing the phone costs no money by itself, but whoever holds it can do what its macaroon allows. Losing the node’s disk is what your recovery words and copies of channel.backup are for.

Step-by-Step Guide

Connecting your mobile device to a self-hosted Lightning node requires careful setup to ensure both security and usability. Follow these steps to achieve reliable mobile access to your Lightning node.

Step 1: Ensure Your Lightning Node Is Fully Synced. Before configuring mobile access, verify that both your Bitcoin Core backend and your Lightning implementation (LND or Core Lightning) are fully synchronized with the network. Check sync status with lncli getinfo (for LND) and confirm synced_to_chain: true. A partially synced node will produce unreliable payment results and channel state information on your mobile device.

Step 2: Configure Tor for Remote Access. Install Tor on your node with sudo apt install tor. Enable a Tor hidden service for the node’s REST port by adding two lines to /etc/tor/torrc, for example HiddenServiceDir /var/lib/tor/lnd_rest/ and HiddenServicePort 8080 127.0.0.1:8080 (8080 is LND’s default REST port; on Core Lightning, use the port you set with clnrest-port, as CLNRest stays off until you set one). Restart Tor and note the generated .onion address from /var/lib/tor/<service-name>/hostname. Tor provides encrypted, NAT-traversing connectivity without exposing your home IP or requiring port forwarding on your router.

Zeus on your phone, with Tor turned on, connects out to the Tor network. Tor on your node also connects out through your router, which has no open port, and the two meet inside Tor. On the node, Tor hands the connection to LND's REST API at 127.0.0.1:8080. In torrc, HiddenServiceDir /var/lib/tor/lnd_rest/ is where Tor keeps the .onion's keys and the hostname file with its address; HiddenServicePort 8080 127.0.0.1:8080 sends what reaches the .onion on port 8080 to LND's REST port on the same machine.
Through Tor, nothing is opened on your router. Your node and your phone both connect out to Tor and meet there, so neither side learns the other’s IP address. The two torrc lines give the node its .onion address and point it at LND’s REST port.

Step 3: Generate Connection Credentials. For LND, create a macaroon with only the permissions the phone needs using lncli bakemacaroon. LND’s stock readonly.macaroon allows monitoring without spending, while admin.macaroon grants full control. Zeus accepts an lndconnect URI: the lndconnect tool prints one with lndconnect --host=<your-onion-address> --port=8080 -j, using the admin macaroon unless you add --readonly or --invoice (to embed a macaroon you baked, point --adminmacaroonpath at it). You can instead enter the .onion address, the port and the macaroon in hex, which xxd -ps -u -c 1000 /path/to/your.macaroon prints. Core Lightning works differently: Zeus connects through its CLNRest plugin and uses a rune instead of a macaroon.

A table of what the phone can do with each LND macaroon, which is what the connection QR code carries. The stock read-only macaroon can see channels, payments, invoices and the on-chain wallet, and do nothing else. The stock invoice macaroon can create invoices and on-chain addresses to receive and can see the node's invoices and on-chain wallet, but cannot pay or send on-chain. A pay-and-receive macaroon you bake yourself can see channels and payments, create invoices and pay invoices, which spends your channel balance, but cannot open or close channels or send on-chain bitcoin. The stock admin macaroon, the one in Umbrel's QR code, can do all of that, including emptying the node's on-chain wallet. Bake one for the phone with offchain:write to pay, invoices:write to receive and the read permissions it needs; without onchain:write it cannot open or close channels or send on-chain.
Whoever scans your QR code, or holds your phone, can do what its macaroon allows. A macaroon that can pay can still spend your channel balance. Bake each device’s macaroon with its own --root_key_id, so that lncli deletemacaroonid can cut off that device alone; the stock macaroons use ID 0, which can’t be deleted.

Step 4: Install and Configure Your Mobile Wallet. Download Zeus, which connects to LND and Core Lightning nodes. Zap, which older guides mention, is no longer maintained: its code has been archived since 2023. Open Zeus, add a node connection, then scan or paste the lndconnect URI from the previous step, or choose LND (REST) and fill in the host, port and macaroon by hand. On Core Lightning, choose Core Lightning (CLNRest) and enter the host, the CLNRest port and a rune made with createrune; give it restrictions, because a rune without any can drain the node. Turn on Tor for the connection (the Use Tor switch) and give the first connection time to open: a connection to an .onion address passes through six Tor relays, three picked by each side, so it is slower than a direct one.

Step 5: Test With a Small Payment. Before relying on the mobile connection for real transactions, send a small Lightning payment (100-1000 sats) to a test invoice. Verify the payment appears in both your mobile wallet and your node’s payment history via the command line. Test receiving a payment as well by generating an invoice from the mobile app and paying it from another wallet. This confirms bidirectional functionality through the Tor connection.

Step 6: Configure Watchtower Protection. A watchtower broadcasts the penalty transaction if a counterparty tries to close a channel with an outdated state while your node is offline. With a remote node you set this up on the node, not in the app: turn on LND’s watchtower client with wtclient.active=true in lnd.conf, restart LND so it reads the change, then register a tower that runs on another machine with lncli wtclient add <tower_pubkey>@<host>:9911. (watchtower.active=true does something else: it runs a tower for other people’s channels.)

Step 7: Optimize for Battery and Connectivity. Your node keeps working while the app is closed: it stays online, keeps its channels and still receives payments for invoices you created. The phone needs the connection only while you use the app, so nothing has to run in the background. If Tor is too slow, two alternatives keep the node’s API off the internet: a private VPN into your home network (WireGuard, for example, which needs one port on your router and ignores anyone without your key), after which the phone reaches the node’s REST port on its local address (plain LND listens only on localhost:8080 by default, so add a restlisten line for that address); or, for LND, Lightning Node Connect, which Zeus supports and which needs Lightning Terminal on the node.

Four ways for your phone to reach the node in your home. Tor: the phone and your node both connect out to Tor, so no port is opened on your router; it is slower to connect and works with LND and CLN. A VPN into your home, WireGuard for example: the phone joins your home network through a tunnel and reaches the node's local address; WireGuard needs one port on your router, and that port ignores anyone without your key. Lightning Node Connect: the phone and your node both connect out to a relay that passes the traffic without being able to read it; it needs LND with Lightning Terminal. Opening the node's API port, 8080, on your router lets anyone on the internet reach it, and is the one to avoid.
Three ways keep your node’s API off the internet. Tor needs nothing opened at home but is slower to connect. If it is too slow, a VPN into your home or Lightning Node Connect (LND only) are the alternatives. Forwarding the API port lets anyone reach it.

Common Mistakes to Avoid

1. Using Admin Macaroons on Mobile Devices. Granting full administrative access to a mobile wallet creates unnecessary risk. If your phone is lost, stolen, or compromised, an attacker gains complete control over your Lightning node — including the ability to close channels and withdraw all funds. Bake custom macaroons with only the permissions you need: invoice creation, payment sending, and channel monitoring are sufficient for most mobile use cases.

2. Opening Your Node’s API to the Internet. LND’s REST port (8080) and gRPC port (10009) listen only on the node itself by default. Making one of them reachable from the internet, by listening on all addresses and forwarding the port on your router, lets anyone find your node’s API and try to break in, and ties your node to your home IP address. LND already encrypts these connections with TLS by default, so keep it on (never set no-rest-tls); what matters is who can reach the port. Use Tor, a VPN into your home or Lightning Node Connect instead, as in Step 7.

3. Neglecting Channel Backup Procedures. Mobile access creates a false sense of security — if your node’s storage fails, having a mobile wallet connected to it does not protect your channel funds. Export your Static Channel Backup (SCB) file regularly and store it in multiple secure locations. LND generates this file at ~/.lnd/data/chain/bitcoin/mainnet/channel.backup. LND rewrites this file each time a channel is opened or closed, so automate a copy to another location after every open or close; the file is already encrypted with a key derived from your seed.

4. Ignoring Tor Connection Timeouts. Tor connections are inherently slower and less reliable than clearnet. If your mobile wallet times out during a payment, do not retry immediately — the first payment may still be in-flight through the Lightning network. Wait 60 seconds and check your payment history before attempting again: retry only if it shows the payment failed, and keep waiting while it is still in flight. LND will not pay the same invoice twice unless it is a reusable AMP invoice, so the usual risk is paying a second, new invoice for the same purchase.

You tap Pay on your phone and the phone asks your node to pay. Tor drops and the app shows a timeout, but your node keeps the payment going through the network to the shop. Wait a minute, then check the payment's status in your payment history. Succeeded: it is paid, so don't pay again. In flight: it is still on its way, so wait and check again. Failed: nothing was paid, so it is safe to try again. Retrying the same single-use invoice is safe because LND won't pay one already paid or in flight; a new invoice for the same purchase gets paid too, so you would pay twice.
A timeout on the phone is not a failed payment. The phone only asked; your node carries on. Retry only once the payment history shows it failed, and retry the same invoice, never a new one for the same purchase.

Frequently Asked Questions

Which mobile wallet works best with a self-hosted Lightning node?

Zeus is the main option: it connects to LND and Core Lightning (CLN) nodes, over Tor if you want, and offers channel management, on-chain transactions and LNURL support from a single app. Zap, which older guides recommend, is no longer maintained: its code has been archived since 2023, so do not give it a macaroon. BlueWallet can only reach your node through an LNDHub server that you run in front of it, which adds a software layer between your wallet and node. For most self-hosted setups, Zeus provides the best balance of features and direct node connectivity.

How do I fix slow or failed connections over Tor?

A connection to an .onion address passes through six Tor relays, three picked by each side, so it is slower than a direct one, and a busy relay on the path slows it further. Restarting your node’s Tor service with sudo systemctl restart tor makes it build new circuits. If connections fail every time, check that Zeus has the address from the hostname file of Step 2 (sudo cat /var/lib/tor/lnd_rest/hostname) with port 8080, that the HiddenServicePort line points at the port LND’s REST API listens on, and that LND is running. If lncli getinfo lists an .onion address, that is your node’s address for other Lightning nodes (port 9735); Zeus needs the REST address from the hostname file.

Can I use my Lightning node from multiple mobile devices simultaneously?

Yes, LND and CLN both support multiple concurrent client connections. You can connect Zeus on your phone and on a tablet to the same node simultaneously. Both only send requests: the node makes every channel update itself, and LND refuses to pay an invoice that is already paid or still in flight, so two devices cannot pay the same invoice twice; a reusable AMP invoice is the exception. For security, bake a separate macaroon for each device, each with its own root key ID (lncli bakemacaroon --root_key_id 1 …); lncli deletemacaroonid 1 then cuts off that device alone. The stock macaroons use root key ID 0, which cannot be deleted.

Is it safe to open and close Lightning channels from a mobile device?

Yes: the phone only sends the request, and your node does the work. Opening channels from mobile works well since it is a simple on-chain transaction from the node’s wallet. Prefer cooperative closes: your balance is back on-chain as soon as the closing transaction confirms. Avoid force-closing channels unless the other node is unreachable: a force close locks your side of the channel for the waiting period your peer set (up to 2,016 blocks, about two weeks, with LND’s defaults), costs more in fees, and needs your node online to sweep the funds and settle any payments still in flight.

Background: convenience against sovereignty

The evolution of Bitcoin’s Lightning Network has brought unprecedented opportunities for scaling and improving user experience, while simultaneously introducing new challenges in maintaining the core principles of sovereignty and privacy. As the ecosystem matures, the intersection of self-hosted nodes, mobile applications, and user-friendly interfaces has become a critical frontier in the advancement of Bitcoin’s second layer technology.

The fundamental tension between convenience and sovereignty has long been a central theme in Bitcoin’s development. This dynamic becomes particularly apparent when examining the architecture of Lightning Network implementations, especially in the context of mobile integration and remote node access. While the promise of instant, low-cost transactions has been realized through Lightning, the technical complexities of maintaining full node sovereignty while enabling seamless mobile access present significant challenges.

The architecture of Lightning node management systems typically falls into three distinct models: fully custodial solutions, hybrid approaches utilizing middleware services, and completely self-sovereign setups. Each model presents its own set of tradeoffs between accessibility, privacy, and security. The fully custodial model sacrifices sovereignty for convenience, while complete self-sovereignty often comes at the cost of user experience and mobile accessibility.

When examining the technical requirements for remote node access, the role of networking protocols becomes crucial. Traditional clearnet connections, while offering superior performance and reliability, often introduce security vulnerabilities and privacy concerns. Tor-based connections, alternatively, provide enhanced privacy but may impact performance and reliability. The implementation of these networking protocols must be carefully considered in the context of mobile integration.

The concept of middleware services in Lightning node management deserves particular scrutiny. While these services can bridge the gap between mobile applications and self-hosted nodes, they introduce potential privacy and security considerations. The architecture of such services must be examined for potential points of centralization or data leakage, as well as their impact on the overall sovereignty of the Lightning node operation.

Privacy considerations in Lightning node management extend beyond simple connection methods. The metadata generated through node operations, including channel management and routing information, can potentially reveal significant information about user behavior and financial patterns. Implementation of privacy-preserving features must be considered at both the protocol and application layers.

Authentication mechanisms represent another critical aspect of remote node management. The implementation of secure authentication systems must balance the need for robust security with user experience considerations. Modern approaches often utilize macaroons or similar capability-based security systems, which provide granular control over permissions while maintaining usability.

The integration of Lightning Network functionality with mobile devices raises important questions about key management and custody models. The security of private keys and channel states must be maintained while enabling practical mobile access. Various technical approaches exist, from simple remote signing to more complex multi-signature arrangements, each with its own security and usability implications.

Looking toward the future of Lightning Network mobile integration, several key developments show promise. The emergence of new protocols for secure remote access, improvements in Tor integration, and advanced authentication mechanisms all contribute to the evolution of more robust and user-friendly solutions. The continued development of these technologies will be crucial in achieving the ideal balance between sovereignty and accessibility.

The broader implications for Bitcoin’s ecosystem are significant. As Lightning Network adoption grows, the solutions developed for mobile integration and remote node access will play a crucial role in shaping user behavior and expectations. The success of these implementations will influence not only technical development but also the broader adoption of Bitcoin as a payment system.

In conclusion, the challenge of integrating Lightning Network nodes with mobile applications while maintaining sovereignty represents a critical frontier in Bitcoin’s technical development. The solutions emerging in this space must carefully balance security, privacy, and user experience considerations. As the ecosystem continues to mature, the development of robust, privacy-preserving solutions for mobile integration will be essential for the broader adoption of Bitcoin’s Lightning Network.

Related Resources

Part of our free Bitcoin course: This topic is covered in Running a Lightning Node: Earning Sats and Supporting the Network, from the Lightning Network & Bitcoin Nodes course.
Filed under: Lightning Network & Layer 2

Continue Reading

← Back to All Articles