MyNode: an appliance image for Bitcoin and Lightning on a single board

The repository holds packaging tooling, not the node itself

MyNode is presented as the easiest way to run a dedicated Bitcoin node and Lightning wallet, but the GitHub repository is not the node software. What it contains is the machinery that assembles an operating system image: a rootfs directory, setup scripts, an app_sdk folder for application integrations, a Makefile that drives root filesystem builds, and doc directories for developers. The README describes MyNode as a platform that combines open source Bitcoin projects with the vendor's own interface, management and support. The open source projects named include the Bitcoin node, a Lightning node, Electrum Server, BTCPay Server, RTL, Specter Desktop, Thunderhub, Mempool, LND Hub, Lndmanage, Lightning Terminal, LNBits, Caravan, Warden Terminal, JoinMarket, Tor and Bitcoin CLI. That list sits inside an HTML comment in the README, so the README itself is not a reliable current feature list, and the per-application guide under doc/applications.md is the documented place to look.

Flashing an image onto an SD card is the supported install path

The documented route to a running node is five steps. You download an image from the downloads page, flash it onto an SD card with Etcher, then insert the card, connect an ethernet cable to the router and boot the device. A fourth step asks you to attach an external drive, and the README states that 1TB or more is required. The fifth step is to open the local web interface at http://mynode.local/ or at the device IP address. Images exist for Raspberry Pi 4, RockPro64, Rock Pi 4, PCs and servers, and virtual machines under VirtualBox and VMWare. The reasoning behind the whole approach is stated in the README: with Bitcoin and Lightning running on the device itself, your transactions are verified by your own node rather than by an online third party. That is the actual value proposition, and it is what the extra hardware, the drive requirement and the flashing step are buying you.

A two-command installer for systems already running Debian

There is a beta path for people who do not want to flash an SD card at all. It applies to a supported platform that already runs Linux, such as a Raspberry Pi 4, a Rock Pi 4, a RockPro64 or a PC, and the README says to install Debian first, last tested with the Debian 10.11 Buster images. After logging in, two commands do the work:

wget https://raw.githubusercontent.com/mynodebtc/mynode/latest_release/setup/setup_device.sh -O mynode_setup.sh
sudo bash ./mynode_setup.sh online

The script is fetched from the latest_release branch rather than from a pinned tag, so the version you get depends on what that branch points at when you run it. The online argument appears to select a networked install path, though the README does not describe what other arguments exist. Once the script finishes, the instruction is to reboot, and the device then runs MyNode. Two things are worth noting before using this path. It is labelled beta in the README, and the Debian version it was last tested against is old enough that you may hit package or service differences on a current distribution.

Root filesystem builds are driven by a small set of Make targets

The build side of the repository is compact and readable, which makes it the most useful part for anyone extending MyNode. The Makefile exposes a rootfs target that calls make_rootfs.sh, optionally restricted to a single device by passing DEVICES, and a rootfs_auto target that depends on starting a file server. The file server target takes a port from FILE_SERVER_PORT, which defaults to 8000, and the start and stop targets shell out to scripts in the scripts directory. There is also a check_app_versions target that runs a Python script to compare app versions against upstream releases, and the Makefile comment notes arguments for updates only and for dependencies:

DEVICES ?=
FILE_SERVER_PORT ?= 8000
	@./make_rootfs.sh $(DEVICES)
	@python3 scripts/check_app_versions.py $(ARGS)
	@/bin/bash scripts/start_http_server.sh $(FILE_SERVER_PORT)

The base images for each supported board are downloaded as gzipped image files into an out directory, and a clean target removes those build outputs. In other words, a release image is a scripted composition of a vendor base image plus the app set, and the version check is what keeps those apps aligned with upstream.

The licence is custom, and support is a paid product

This is where MyNode differs from the projects it assembles. The repository is not published under a standard open source licence; the license field reports a custom licence that GitHub cannot classify, and the LICENSE.md file is the only authoritative text. Anyone planning to read the code, vendor it internally or redistribute it needs to read that file directly rather than assume a permissive grant, because the open source components inside the image carry their own terms while the platform layer does not. Commercial pressure is also part of the design. The README offers MyNode Premium with premium support and simplified upgrades for people running the Community Edition, and it points to a device order page for the Model One and Model Two hardware. The repository is therefore the build system behind a product with paid support and sold hardware, and the code you read here is the part that assembles that product rather than a standalone tool.

Development and application guides live beside the code

For anyone who wants to extend the platform, the repository points to two documents. The development guide under doc/development.md covers working on the MyNode platform itself, and the application guide under doc/applications.md covers creating and adding a new application. The app_sdk directory and the scripts directory are where the integration work happens, and SYSTEM_NOTES.md sits at the top level next to a CHANGELOG file. The README also mentions a dual mode interface, a simple web interface and dark mode, and describes container support inside the device for monitoring and terminal tools such as Netdata, Glances and WebSSH2, plus a virtual machine feature for VirtualBox or VMWare. The specifics of any of that live outside the README, in the doc tree and the vendor documentation at docs.mynodebtc.com, so the README is best read as an entry point rather than a specification.

No GitHub releases, so tags carry the version

The repository has no GitHub releases, which changes how you track what you are running. The README badge points at the tag list rather than a release feed, so the tag is the version reference for the platform code, and the CHANGELOG file at the root is the other place to look for what changed. The last push to the repository was on 2026-10-16, so the code is being worked on rather than abandoned. What that does not tell you is which Bitcoin or Lightning node versions are inside a given image, and the check_app_versions script exists precisely because that mapping has to be maintained against upstream releases. Anyone pinning a deployment should treat the image, the tag and the upstream project versions as three separate things to verify rather than assuming the platform version implies the rest.

Editorial conclusion

MyNode fits a person who wants a working Bitcoin node with a Lightning wallet and a few standard companion services without assembling a root filesystem by hand, and who is comfortable flashing an SD card and attaching an external drive. It does not fit someone who needs a permissively licensed codebase to audit and modify, because the repository carries a custom licence and the node software it ships is built from other projects. Before committing, read LICENSE.md in full, confirm your board has a MyNode image, and check that the external drive meets the 1TB requirement stated in the README.

Frequently asked questions

Official sources

1. Issues
2. mynodebtc/mynode on GitHub
3. README