# nix-bitcoin: Bitcoin nodes as NixOS modules, now unmaintained > nix-bitcoin packaged bitcoind, Lightning implementations, explorers and merchant tooling as Nix packages and NixOS modules with a Tor-first secure node preset. Its README declares the project archived and unmaintained as of 2026-08-13, with v0.0.139 as the final release and no further security fixes. **fort-nix/nix-bitcoin** — A collection of Nix packages and NixOS modules for easily installing full-featured Bitcoin nodes with an emphasis on security. - Repository: https://github.com/fort-nix/nix-bitcoin - Website: https://nixbitcoin.org - Stars: 614 · Forks: 156 - Language: Nix - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/fort-nix-nix-bitcoin ## What the project actually packages nix-bitcoin is a collection of Nix packages and NixOS modules for installing full-featured Bitcoin nodes with an emphasis on security. The stated use cases are personal or merchant wallets, public infrastructure, and Bitcoin application backends. In all cases the aim is to provide security and privacy by default. The repository is built on Nix and NixOS, and the README says the abstractions they provide keep the project highly customizable and maintainable. It also says that running nix-bitcoin does not require any previous experience with the Nix ecosystem, which is a claim worth checking against your own comfort level, since the modules are NixOS options and the examples are Nix configurations. Deployment is flexible in a way that matters operationally. Nodes can be deployed on dedicated hardware, virtual machines or containers, and the Nix packages and NixOS modules can be used independently and combined freely. So you can take only the packages, only the modules, or both. The README is also careful about the maturity claim. It says that while nix-bitcoin is used in production today, it is still considered experimental. That combination is the honest summary: real deployments exist, and the project never claimed to be finished. ## Archived on 2026-08-13, with a final tag The first thing on the page is a warning banner, and it changes how everything below it should be read. The README states that the project is archived and unmaintained as of August 13, 2026, that v0.0.139 is the final release, and that there will be no further updates or security fixes. The release list confirms the shape of the ending. v0.0.137 was tagged on 2026-05-20, v0.0.138 on 2026-07-27 and v0.0.139 on 2026-08-13, matching the date in the banner. The last push to the repository was on 2026-09-21, so the tree saw some activity after the final tag, but a commit after the final release is not a maintenance commitment. For a piece of software whose job is to hold keys and enforce a network policy, the end of security fixes is not a footnote. A node is a long lived process, and the software it runs, the libraries it links and the TLS and networking code under it all move on. Pinning a frozen release means your node keeps running the versions that were current on 2026-08-13, with none of the upstream fixes that have landed since. The practical question is therefore not whether the modules are well designed, which is a separate question, but whether you want to own the patching story for a node you intend to run for years. ## The secure node preset is the centre of the design There is a configuration preset at modules/presets/secure-node.nix for setting up a secure node, and the README attaches one guarantee to it. All applications use Tor for outbound connections and support accepting inbound connections via onion services. That single property is what separates this project from installing a Bitcoin node with a package manager. A node that dials out over Tor and is reachable only as an onion service has no listening port on the clearnet, which removes the class of problems that come from port forwarding, from dynamic addresses and from anyone on the internet probing your machine. The cost is latency and the requirement that the remote party also supports Tor. The preset approach is also a statement about what you want to run. Services that are not enabled in configuration.nix and their dependencies are not installed at all, so the node's attack surface is the set of things you actually asked for. Combined with the network namespace isolation helper described later, the intent is a machine where an unused service is not merely stopped but absent. For a merchant or an application backend, the same defaults matter for a different reason. A payment processor that talks to its own node over the clearnet has a different risk profile from one that reaches the node only through an onion service, and the preset is what makes the second arrangement the path of least resistance. ## The module list is the actual feature list The breadth is the point of the project, so it is worth reading the module list as a catalogue of what you can run under one declarative configuration. The application services start with bitcoind and two Lightning implementations. clightning comes with support for announcing an onion service and for database replication, and a list of plugins: clboss as an automated node manager, currencyrate as a currency converter, monitor for analysing the health of peers and channels, rebalance for keeping channels balanced, zmq for publishing notifications over ZeroMQ, and trustedcoin, which is marked experimental and replaces bitcoind with trusted public explorers. lnd comes with onion service announcement and static channel backups, plus Lightning Loop, Lightning Pool and charge-lnd as a policy based channel fee manager. Around them sit the tools. lndconnect connects your wallet to lnd or clightning via WireGuard or Tor, Ride The Lightning provides a web interface for both, mempool is a visualiser, explorer and API service, electrs and fulcrum are Electrum servers with a module that compares the two, btcpayserver is the payment processor, liquid is the federated sidechain, JoinMarket comes with an orderbook watcher, and bitcoin-core-hwi handles hardware wallet interaction. The spread is wide enough that the difference from pulling packages from nixpkgs is not the software but the wiring. Here the node is a set of services with onion endpoints, users, storage and firewall rules, assembled from modules rather than configured by hand. ## The helper modules do the unglamorous work Four helper modules handle the parts that every operator eventually writes and nobody wants to write twice. netns-isolation, at modules/netns-isolation.nix, isolates applications on the network level using network namespaces. This is the mechanism behind the preset's promise in a stronger form. A service in its own namespace cannot reach the parts of the network it was not meant to, so separation stops being a matter of firewall rules you remembered to add. nodeinfo, at modules/nodeinfo.nix, is a script that prints information about the node's services, which is the first thing you want when something is not working and the last thing you want to assemble by hand during an incident. backups, at modules/backups.nix, does duplicity backups of all the node's important files. A Bitcoin node's important files are the wallet and the channel state, so a backup story that is expressed as a module rather than a cron entry is a meaningful difference in practice. operator, at modules/operator.nix, configures a non-root user who has access to client tools such as bitcoin-cli and lightning-cli. That is a small module with a clear purpose. Running your client tools as root because the daemon runs as root is a habit that costs nothing to avoid and everything to fix later. The security section backs this up with a principles list starting with simplicity, which covers installing only what is enabled, supporting doas as an alternative to sudo, and continuous code review, plus a SECURITY.md that holds the historical security fund policy and past vulnerability reports. ## Where to get it and how it is deployed The README does not carry an installation command, so the project points you at its own documents. To set up a new node from scratch there are installation instructions in docs/install.md, the examples directory README gives an overview of all features, and for adding nix-bitcoin to an existing NixOS configuration there is importable-configuration.nix and a Flake example under examples/flakes/flake.nix. The docs index also lists hardware requirements, configuration and maintenance, using services, and a FAQ. The examples directory is more than documentation. It holds configuration.nix, a container directory, krops and nixops examples, a qemu-vm example, a krops-vm-configuration.nix, and a set of deployment scripts: deploy-container.sh, deploy-container-minimal.sh, deploy-krops.sh and deploy-qemu-vm.sh, plus start-bash-session.sh and nix-bitcoin-release.nix. At the repository root the packaging surfaces are default.nix, overlay.nix, shell.nix, flake.nix and flake.lock, alongside directories for modules, helper, pkgs, dev, test, docs and examples. The deployment choices mirror the three deployment targets the README names. the krops and nixops examples target remote NixOS hosts, the container scripts deploy into containers, and the QEMU script deploys a virtual machine. Each one is a different answer to the same question about where the node runs and how much of the host it owns. ## Compared with installing the daemon yourself The alternative is to install bitcoind, or a Lightning implementation, from nixpkgs and write the systemd units, the users, the storage layout and the firewall rules by hand. That approach has one advantage and one disadvantage, and they are the same fact seen from different sides. The advantage is ownership. Nothing sits between you and the upstream release, so when bitcoind publishes a fix you take that fix, and the module layer is not a dependency you have to trust or work around. For a security sensitive node, being able to read the whole configuration is worth something. The disadvantage is that the operational work is now yours, and it is not small. Tor routing, onion service announcements, network namespace isolation, a non-root operator account and a backup strategy for wallet and channel state are all decisions that nix-bitcoin already made, tested and documented. Rebuilding them means both writing them and testing them. The honest summary of nix-bitcoin today is that it is a well documented answer to that operational work that stopped being maintained in August 2026. It remains a useful reference and a working configuration for someone who wants to fork it and continue. As a dependency for a node you intend to operate and protect, the archive banner is the deciding fact, not the feature list. ## Conclusion nix-bitcoin suits someone who already lives in Nix and wants to reproduce a hardened Bitcoin node declaratively, and who is prepared to own the upgrade work themselves now that the project is closed. It does not suit a new deployment, because the README states there will be no further updates or security fixes, and that is decisive for software that holds keys and connects to the network. Verify first which release you are pinning and what has changed in bitcoind and your Lightning implementation since 2026-08-13, and treat the packaged versions as frozen rather than current. ## FAQ ### Is nix-bitcoin still maintained? No. The README states the project is archived and unmaintained as of August 13, 2026, that v0.0.139 is the final release, and that there will be no further updates or security fixes. ### What does nix-bitcoin provide for a Bitcoin node? It provides Nix packages and NixOS modules for full-featured Bitcoin nodes, a configuration preset at modules/presets/secure-node.nix where all applications use Tor for outbound connections and accept inbound connections via onion services, and helper modules for network namespace isolation, node information, duplicity backups and a non-root operator user. ### Which Lightning implementations does nix-bitcoin support? clightning, with onion service announcement, database replication and plugins including clboss, currencyrate, monitor, rebalance, zmq and the experimental trustedcoin, and lnd, with onion service announcement, static channel backups, Lightning Loop, Lightning Pool and charge-lnd. ### How do I add nix-bitcoin to an existing NixOS configuration? The README points to importable-configuration.nix and the Flake example in examples/flakes/flake.nix, with the full feature overview in the examples README and the from-scratch instructions in docs/install.md. ### What licence does nix-bitcoin use? The repository is MIT licensed, with the terms in the LICENSE file at the root of the repository. ## Sources - [fort-nix/nix-bitcoin on GitHub](https://github.com/fort-nix/nix-bitcoin) - [License: MIT](https://github.com/fort-nix/nix-bitcoin/blob/master/LICENSE) - [Project website](https://nixbitcoin.org) - [README](https://github.com/fort-nix/nix-bitcoin/blob/master/README.md) - [Releases](https://github.com/fort-nix/nix-bitcoin/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fort-nix-nix-bitcoin