How to Reach Your Node's Apps on Your Home Network

Your Bitcoin node runs several apps: a block explorer and a mempool viewer you open in a browser, a wallet backend your wallet connects to and, if you use Lightning, a dashboard. This guide makes them easy and safe to reach from every device in your home. You will open each web app by a name such as umbrel.local instead of an IP address that can change, over HTTPS without browser warnings, and through a single entry point. Everything stays inside your home network; from outside, you come in through a VPN. To secure the rest of the machine, see our node security guide.

Two protocols do the finding. Multicast DNS (mDNS) lets a device ask the whole home network for a name, and the device with that name answers with its address. DNS-SD (DNS Service Discovery) lets your node also announce which services it offers. On Linux, Avahi provides both. macOS and Linux typically find .local names out of the box; Windows and some Android phones may need an extra step, which Step 5 covers.

Step-by-Step Guide

Steps 1 and 2 make your node findable by name, Step 3 removes the browser warnings, Step 4 puts every web app behind one entry point, Step 5 covers devices that can’t use .local names, and Step 6 limits access to your home network and your VPN.

Step 1: Install and configure Avahi for mDNS on your node. On Linux-based Bitcoin node platforms (including Raspberry Pi setups running Umbrel, RaspiBlitz, or Start9), install the Avahi daemon if it is not already present. On Debian/Ubuntu systems, run sudo apt install avahi-daemon avahi-utils. In the Avahi configuration at /etc/avahi/avahi-daemon.conf, check that publish-addresses=yes (the default). This lets your node answer for its hostname (e.g., umbrel.local) on the local network, so other devices can find it without knowing the IP address. (publish-workstation only adds a _workstation._tcp service entry; the name works without it.) Restart the daemon with sudo systemctl restart avahi-daemon.

Inside your home network, your laptop sends one question to every device at once: who is umbrel.local? The printer and the TV stay silent. Only your node, whose name is umbrel.local, answers: that's me, 192.168.1.50. Your browser then opens that address. No server is asked: the device that has the name answers for itself, and the question stays inside your home network, so umbrel.local works only at home. — **A .local name is a question asked of your whole home network.** Only the device with that name answers, with its current address, so the name keeps working even when the router gives your node a new one.

Step 2: Configure DNS-SD service advertisements. Create service definition files in /etc/avahi/services/ for each Bitcoin service you want to advertise. For example, create bitcoin-explorer.service with XML specifying the service type (_http._tcp), port (typically 3002 for BTC RPC Explorer or 8080 for mempool), and a human-readable name. Apps that browse these announcements, such as service-browser apps, then list your services automatically. Create separate service files for your Electrum server (the port it actually listens on: commonly 50001 for plain TCP or 50002 for TLS, but node platforms differ), Lightning dashboard, and any other web interfaces. Once the reverse proxy from Step 4 is in place, point each web entry at the proxy’s port 80, set up to redirect to HTTPS (an _http._tcp entry at 443 sends plain HTTP to the encrypted port), and give it a host-name such as explorer.local so the proxy opens the right app.

Step 3: Set up proper TLS certificates for local HTTPS access. Generate a local Certificate Authority using OpenSSL or a tool like mkcert. Create a root CA certificate and install it in the trust stores of all devices that will access your node’s services. Then generate TLS certificates signed by your local CA for each service hostname (e.g., umbrel.local, explorer.local). Only the root certificate goes onto other devices: the CA’s private key stays on the computer that made it, because anyone holding it can create certificates your devices will trust. Configure your reverse proxy (Nginx or Caddy) to use these certificates. This eliminates browser security warnings while maintaining encrypted connections to your node’s web interfaces.

Set up once: your local CA, made with mkcert or OpenSSL on one computer, signs a certificate for explorer.local and umbrel.local, which your node shows to browsers. You copy the CA's root certificate, without its private key, to each device. The private key stays on that computer: anyone with it could fake websites to your devices. Every time you open https://explorer.local, your device checks two things: is the certificate signed by a CA this device trusts, and is it made for the name in the address bar? Both yes: a padlock and no warning. With no CA on the device, a security warning appears on every visit; an attacker's fake certificate looks the same, so clicking through trains you to accept it. — **Install your CA’s root certificate once on each device, and every name it signs opens without a warning.** StartOS works this way out of the box: it creates its own root CA during setup, and you install that certificate on each device.

Step 4: Configure a reverse proxy for unified service access. Install Nginx or Caddy on your node to serve as a reverse proxy routing requests to different backend services. Map subdomains or URL paths to each service: for example, explorer.local routes to your block explorer, mempool.local to your mempool viewer, and lightning.local to your Lightning dashboard. Publish each extra name on your network the way Avahi publishes the node’s own, for example with avahi-publish -a -R explorer.local 192.168.1.50 kept running as a service. Keep each name to one word before .local: Linux devices reject longer .local names such as explorer.umbrel.local by default. The reverse proxy handles TLS termination and provides a clean, consistent access pattern for all your services through a single entry point. With each app listening only on the node itself (127.0.0.1, BTC RPC Explorer’s default), the proxy is the only way in. For an app in Docker, what counts is the address its port is published on: mempool’s official Compose file publishes its web app as 80:8080, open on every address, so change that to 127.0.0.1:8080:8080. Use Docker 28 or later; older versions still let other devices on your network reach ports bound to 127.0.0.1.

You type https://explorer.local, https://mempool.local or https://lightning.local. All three names point to your node, 192.168.1.50, at port 443, where the reverse proxy (Nginx or Caddy) is the one door. It shows your certificate, decrypts the request, reads the name you typed and passes it on: explorer.local to the block explorer at 127.0.0.1:3002, mempool.local to the mempool viewer at 127.0.0.1:8080, lightning.local to the Lightning dashboard, RTL, at 127.0.0.1:3000. The apps answer only the node itself. Each extra name must be published on your network too, the way Avahi publishes umbrel.local. — **The proxy is the only door: it picks the app by the name you typed.** Each app listens only on the node itself (127.0.0.1), so the network reaches it through the proxy and its certificate.

Step 5: Handle Windows and cross-platform compatibility. Windows machines on your network may not resolve .local hostnames without additional configuration. If your router lets you add local DNS names, add one for your node, such as node.home.arpa, and one for each app, such as explorer.home.arpa, all pointing to the node’s local IP address. home.arpa is set aside for home networks; keep .local out of your router’s DNS, because that ending belongs to mDNS. Add each new name to your certificate, and add each app’s new name to that app’s route in the proxy, next to its .local name: the proxy picks the app by the name you typed, so a name or bare IP it has no route for opens its default site or an error. Android’s built-in resolver has answered .local names since November 2021, on Wi-Fi but not over a VPN or mobile data; if a phone still can’t open a .local name, use the matching home.arpa one, such as explorer.home.arpa. Test access from every device type on your network to identify and resolve platform-specific issues.

Three ways to type your node's address. umbrel.local: your node answers for its own name through mDNS; it keeps working when the node's IP changes, but only on your home network, and some devices need extra software (Step 5). node.home.arpa: a name you add in your router's DNS settings; every device that uses your router's DNS finds it, but it needs a router that lets you add names, and a reserved IP. 192.168.1.50: the node's own address on your network; it works on every device with no lookup at all, but breaks when the router gives the node a new address. First, reserve the node's address on your router with a DHCP reservation; then put every name and address you type into your certificate. In your proxy, give each app its own name, such as explorer.home.arpa, or its own port. — **Reserve the node’s address first; then any of the three will reach it.** A name you add in your router belongs under home.arpa, which is set aside for home networks: names ending in .local are left to mDNS.

Step 6: Implement access controls and firewall rules. Restrict service access to your local network only. Configure your node’s firewall (using ufw or iptables) to accept connections to service ports only from your local subnet (e.g., 192.168.1.0/24) and, if you use a VPN, from the addresses it gives your devices. Ports that Docker publishes go around these rules: bind each web app’s port to 127.0.0.1 as in Step 4, and for a port your wallet must reach directly, such as the Electrum server’s, put the subnet rule in Docker’s DOCKER-USER chain instead. If you need remote access, use a VPN like WireGuard rather than exposing services directly to the internet. Set up authentication on sensitive interfaces—particularly your Lightning node dashboard and any services that can initiate transactions. Use strong, unique passwords and consider implementing HTTP Basic Auth or OAuth2 proxy for additional protection.

Away from home, your phone reaches your node through a VPN such as WireGuard or Tailscale: an encrypted tunnel across the internet into your home network that opens only for your devices' keys. WireGuard at home needs one UDP port on the router, and it stays silent to anyone without a key; Tailscale usually needs no open port at all. Forwarding your apps' ports instead puts them in front of everyone on the internet. Once connected, type the node's VPN address or name (with Tailscale, its own Tailscale IP or MagicDNS name) and the app's own proxy port, such as :4431; .local names stop at your home network. On the node's firewall, let in your home network (192.168.1.0/24) and your VPN's addresses, and refuse the rest. — **From outside, come in through a VPN; your apps stay inside your home.** Through the tunnel, use the node’s VPN address or name with each app’s own proxy port: .local names stop at your home network.

Common Mistakes to Avoid

Exposing node services directly to the internet. The most dangerous mistake is making your Bitcoin node’s web interfaces accessible from outside your local network without proper security measures. Opening firewall ports for services like your block explorer, Electrum server, or Lightning dashboard exposes them to automated scanning and exploitation attempts. Attackers specifically target known Bitcoin infrastructure ports. Always use a VPN for remote access rather than forwarding your apps’ ports, and never expose your node’s RPC interface to the public internet under any circumstances.

Ignoring mDNS hostname conflicts on the local network. mDNS doesn’t let two devices share a .local hostname: the one that starts second finds the name taken and renames itself (Avahi turns umbrel into umbrel-2), so umbrel.local keeps opening the old device while the new one answers as umbrel-2.local. This commonly occurs when users run multiple node setups (e.g., a test node and a production node) or when upgrading hardware without decommissioning the old device. Each device must have a unique hostname. To check, look up the name from another computer and compare the address with your node’s IP: run avahi-resolve-host-name -4 umbrel.local on Linux or dns-sd -G v4 umbrel.local on macOS (press Ctrl-C to stop). The node that lost the name also logs “Host name conflict, retrying with umbrel-2”, which sudo journalctl -u avahi-daemon shows.

An old node is already running as umbrel.local. A new node starts with the same name. 1: it asks the network whether umbrel.local is taken. 2: the old node answers that it is. 3: the new node renames itself umbrel-2.local. Your bookmark for umbrel.local still opens the old node. Give each node its own name before you start it, then update bookmarks and certificates. — **Two devices can’t share a .local name: whichever starts second renames itself.** Avahi adds -2 to the name, so a replacement node can quietly appear as umbrel-2.local while your bookmarks still open the old one.

Using self-signed certificates without a proper local CA. Many node operators generate self-signed certificates for HTTPS but never install a root CA in their devices’ trust stores. This results in persistent browser security warnings that users learn to click through—a habit that makes them vulnerable to actual man-in-the-middle attacks. Take the time to set up a proper local CA and install its root certificate on all devices that access your node. Tools like mkcert simplify this process dramatically.

Neglecting to update service configurations after network changes. When your router assigns a new IP address to your node (if using DHCP) or when you change your network subnet, service discovery can break silently. Either assign a static IP to your node or configure a DHCP reservation on your router to ensure the IP remains consistent. Update any hardcoded IP references in service configurations, reverse proxy settings, and client applications whenever network topology changes.

Frequently Asked Questions

Why can’t my Windows computer find my Bitcoin node using the .local address?

Windows does not natively support mDNS resolution in the same way macOS and Linux do. While Windows 10 and later versions have added limited mDNS support, it is inconsistent and often fails for .local addresses. The most reliable solution is to add a name for each app, such as explorer.home.arpa, in your router’s DNS settings, pointing to the node’s local IP address, and add each name to that app’s route in your proxy and to your certificate; these names work across all platforms without additional software.

Is it safe to access my Bitcoin node services over HTTP instead of HTTPS on my local network?

While the risk is lower on a local network than over the internet, using unencrypted HTTP still exposes your traffic to anyone with access to your network—including compromised IoT devices, guests on your Wi-Fi, or anyone who has cracked your wireless password. Authentication credentials sent over HTTP can be captured in plaintext. For services that handle sensitive Bitcoin operations, always use HTTPS even locally. The one-time effort of setting up a local CA and TLS certificates is worth the persistent security benefit.

Can I access my node’s services from outside my home network?

Yes, but you should never do so by exposing your apps’ ports directly to the internet. The recommended approach is to set up a WireGuard or Tailscale VPN on your node, which creates an encrypted tunnel from your remote device to your home network. Once connected to the VPN, you reach your node by its VPN address or the name your VPN gives it (with Tailscale, the node’s own Tailscale IP or its MagicDNS name); .local names work only on the home network itself. Your proxy picks apps by name and has no route for that address, so give each app its own port on the proxy (say 4431 for the explorer) and add the address to your certificate. This approach maintains your node’s security posture while providing full remote access. WireGuard has minimal performance overhead and works well even on mobile connections.

Do I need a separate device for each Bitcoin service, or can they all run on one machine?

Most self-hosted Bitcoin setups run all services on a single machine—typically a Raspberry Pi 5 or a small mini-PC. Bitcoin Core, an Electrum server, a block explorer, a mempool viewer, and a Lightning node can all coexist on one device with 8 GB or more of RAM and a 2 TB SSD. Node operating systems like Umbrel, RaspiBlitz, and Start9 are specifically designed to manage multiple services on a single device, and they set up the route to each app for you, usually one port per app (on Umbrel, the mempool app opens at umbrel.local:3006).

Related Resources

Part of our free Bitcoin course: This topic is covered in Setting Up Your Bitcoin Node Step by Step, from the Lightning Network & Bitcoin Nodes course.

Filed under: Bitcoin Nodes & Infrastructure