NixOS lets you describe an entire sovereign stack — bitcoind, electrs, Tor, a local-AI server, and a Nostr relay — in one declarative configuration.nix file. Every rebuild is reproducible, every upgrade is atomic, and a bad change rolls back in one boot. It is the reproducible tier above appliance node OSes: more control, a steeper curve.
Appliance node operating systems like Umbrel and StartOS (Start9) did something genuinely important: they took running your own Bitcoin node from a weekend of Linux yak-shaving down to a few clicks. If you are running one today, you are already further down the sovereignty road than most. This guide is for the next step — when you want the machine itself to be described in code, version-controlled, and rebuildable from scratch on any hardware. That is what NixOS and the nix-bitcoin project give you, and both are the work of large open-source communities we are simply standing on the shoulders of here.
Why declarative beats hand-tuned for a sovereign stack
The usual way to build a self-hosted node is imperative: you SSH in, apt install some things, edit a dozen config files in /etc, open some firewall ports, set up systemd units, and pray you remember what you did. Six months later the SD card dies, or you upgrade Debian, and your carefully tuned box is a pile of undocumented tweaks you have to reverse-engineer from your own past self.
NixOS inverts this. The whole system — kernel options, every package, every service, every user, every firewall rule — is declared in /etc/nixos/configuration.nix. You do not install software; you declare that it should exist and run a rebuild. The NixOS project describes its three pillars as reproducible (“if a package works on one machine, it will also work on another,” via isolated builds with no undeclared dependencies), declarative, and reliable (installing or upgrading “cannot break other packages,” and you can “roll back to previous versions”). For a node that is supposed to outlive hardware, that property set is exactly what you want.
Under the hood, the Nix package manager pins every dependency by cryptographic hash and builds each package in isolation. The practical payoff: the same config plus the same pinned inputs produces the same system — on your spare ThinkPad, on a fresh NVMe, or on a friend’s machine a year from now. Your node becomes a text file you can back up, diff, and audit, not a fragile snowflake.
The appliance tier versus the declarative tier
This is not a contest, and the honest answer for most people is “start with an appliance.” Umbrel and StartOS are excellent on-ramps, and D-Central documents that landscape over on the Bitcoin node appliances page. NixOS is a different tier with a different trade: you give up the app-store ease and pay in learning curve, and in return you get total, reproducible control. Here is the honest comparison.
| Dimension | Appliance OS (Umbrel, StartOS) | NixOS + nix-bitcoin |
|---|---|---|
| Mental model | App store + web dashboard | One declarative config file |
| Setup effort | Low — flash, click, done | High — learn the Nix language first |
| Installing a service | Click “install” in the UI | Add a few lines, run a rebuild |
| Upgrades | Managed updates per app | Atomic whole-system generation switch |
| Rollback | App-level, sometimes manual | Whole system, one command or one reboot |
| Reproducibility | Image-based; drift over time | Pinned inputs; rebuild identical anywhere |
| Customization ceiling | Bounded by the app catalog | The entire Linux userland |
| Best for | Getting sovereign this weekend | Operators who want infrastructure-as-code |
If the appliance route is where you are, keep going — the self-hosting hub and the broader sovereign self-hosting catalog map out plenty of services worth running before you ever touch Nix. NixOS earns its place once “I want to rebuild this exact box, on demand, from a file in git” becomes a requirement rather than a nice-to-have.
What “atomic rollback” and “reproducible rebuild” actually mean
These two phrases get thrown around a lot, so here is the concrete mechanics on NixOS.
Generations. Every time you apply a configuration, NixOS builds it as a new generation and adds an entry to the bootloader menu. The current system is just a symlink pointing at the active generation. Switching is effectively a pointer swap, which is why activation is described as atomic: either you are on the new generation or the old one, never a half-applied mess.
Applying changes. The command nixos-rebuild switch builds the new configuration, makes it the default for booting, and activates it on the running system (restarting affected services). If you only want to try it without changing the boot default, nixos-rebuild test activates it now but leaves the previous generation as the boot fallback — a reboot undoes everything. That alone makes risky changes far less scary.
Rolling back. If a change breaks something, nixos-rebuild switch --rollback reverts to the previous generation. And because every past generation is still in the boot menu, you can pick an older, known-good system right from the bootloader if the box won’t even come up. Your node has an undo button at the operating-system level.
Reproducible rebuild. Because the config and its pinned inputs fully determine the result, “reinstall” stops being a research project. Flash a base NixOS, drop in your configuration.nix (and your pinned channel or flake lock), run one rebuild, restore your wallet and chain data, and you are back. There is no undocumented state living only in your head.
nix-bitcoin: the security-hardened heart of the stack
You could wire up bitcoind by hand on NixOS, but you do not have to. The nix-bitcoin project — maintained by the fort-nix community — is “a collection of Nix packages and NixOS modules for easily installing full-featured Bitcoin nodes with an emphasis on security.” It is the part of this stack we credit most directly; it has done the hard, careful work so you do not have to.
Its design leans on four hardening principles worth understanding before you trust it with a node:
- Simplicity — only the services you enable get installed; less surface area, fewer surprises.
- Integrity — Nix specifies exact dependencies and upstream packages are cryptographically verified.
- Least privilege — each service runs isolated with minimal permissions via systemd restrictions, RPC whitelisting, and network-namespace isolation.
- Defense in depth — hardened-kernel support, Linux namespaces, a dbus firewall, and seccomp-bpf syscall filtering.
Out of the box, nix-bitcoin’s secure-node.nix preset enables bitcoind and routes outbound connections over Tor, and it can publish onion services for the components you want reachable. The catalog of modules it ships is broad: bitcoind, electrs and Fulcrum (Electrum servers), the mempool explorer, c-Lightning and LND (with plugins, Ride The Lightning, Lightning Loop/Pool), BTCPay Server, JoinMarket, Liquid, plus utilities like a non-root operator user, nodeinfo, and Duplicity backups. You enable what you need and ignore the rest.
A starter configuration.nix skeleton
Below is an illustrative skeleton, broken into the pieces you would assemble into one configuration.nix. Treat it as a teaching scaffold, not a copy-paste production deployment — pin your versions, read the upstream docs, and test on hardware you can afford to wipe. Always cross-check option names against the current nix-bitcoin and NixOS releases, because module options do change between versions.
1. Imports and base hardening (nix-bitcoin)
imports = [./hardware-configuration.nix<nix-bitcoin/modules/modules.nix><nix-bitcoin/modules/presets/secure-node.nix><nix-bitcoin/modules/presets/hardened.nix>];
2. The Bitcoin layer: bitcoind + electrs
services.bitcoind.enable = true;— enabled by the secure-node preset; full validation.services.bitcoind.prune = 0;— keep the full chain for electrs (set a value like100000MiB only if you must prune).services.electrs.enable = true;— your own Electrum server so wallets never leak addresses to a third party.nix-bitcoin.onionServices.bitcoind.public = true;— accept inbound peers over Tor.
3. Privacy: Tor
services.tor.enable = true;services.tor.client.enable = true;— opens the local SOCKS proxy (default 9050) so other services can dial out over Tor.- nix-bitcoin’s secure-node preset already wires bitcoind and Lightning through Tor and manages v3 onion services for you.
4. Local AI: an Ollama server
services.ollama.enable = true;— runs the Ollama daemon as a systemd service, bound tolocalhost:11434by default (private to the box).services.ollama.acceleration = "cuda";— use"rocm"for AMD, or omit / setfalsefor CPU-only.services.ollama.loadModels = [ "llama3.2:3b" "deepseek-r1:1.5b" ];— pulls models at startup via a generatedollama-model-loader.service.services.open-webui.enable = true;— optional browser UI onlocalhost:8080if you prefer chat to CLI. (llama.cpp is the lighter-weight alternative if you want to drive GGUF models yourself.)
5. Communications: a personal Nostr relay
services.nostr-rs-relay.enable = true;— the Rust relay by scsibug / gheartsfield, persisting events to SQLite.services.nostr-rs-relay.settings.info.name = "my-sovereign-relay";services.nostr-rs-relay.settings.info.description = "Personal relay";- Set the listen port explicitly (the module exposes a
portoption; nostr-rs-relay commonly uses 8080) and front it with an onion service or reverse proxy for remote access.
6. The operator account and apply
users.users.operator.extraGroups = [ "wheel" ];— gives the non-root operator user admin rights for day-to-day commands likebitcoin-cliandnodeinfo.system.stateVersion = "25.11";— pin the release you initially installed.- Apply it all with
nixos-rebuild switch.
Notice what just happened: a Bitcoin full node, your own Electrum server, Tor, a local LLM, and a Nostr relay — the spine of a sovereign computing setup — are now described in a single auditable file. That is the whole point. For the bigger map of what “sovereign computing” means around these services, the sovereign computing 101 primer is a good companion read.
Day-to-day operation
Living with a NixOS node is a small, repeatable loop. Edit configuration.nix, run nixos-rebuild test to try the change without committing it to boot, confirm everything is healthy (nix-bitcoin’s nodeinfo command is handy here), then nixos-rebuild switch to make it permanent. Commit the file to a private git repo so every change to your infrastructure is logged. When an upgrade misbehaves, --rollback or a boot-menu pick gets you back to the last good state in under a minute. There is no “what did I change?” anxiety because the diff is right there in version control.
Backups also get simpler. Your system is the config file (tiny, in git). Your state — the wallet, the chainstate, the relay’s SQLite, the LLM models — is the only thing that needs real disk backup, and nix-bitcoin even ships Duplicity for it. Separating reproducible-from-config from must-be-backed-up is one of the most clarifying habits this approach teaches.
The honest trade-offs, and who this is for
NixOS is not free of friction. The Nix language is genuinely unusual — it is a lazy, functional configuration language, and it will fight you at first. Error messages can be cryptic. The documentation, while improving fast, is spread across the manual, the wiki, the options search, and community Discourse threads. And the appliance OSes will get a beginner to a working node hours sooner. None of that is a knock on Umbrel or Start9; they are solving a different, equally valid problem.
Reach for NixOS when you have outgrown click-ops and want your node, your privacy plumbing, your local AI, and your relay to be one reproducible artifact you fully control. It rewards the operator who treats their setup as infrastructure-as-code: a hardware-fluent pleb who is comfortable in a terminal, values being able to rebuild from scratch, and wants the entire stack auditable. If that is you, the NixOS and nix-bitcoin communities have already built most of the path; you are just walking it. For where this fits in the wider toolkit, browse the sovereignty hub, the local-AI work in the AI section, and the Nostr resources.
Frequently asked questions
Is NixOS better than Umbrel or Start9 for a Bitcoin node?
Not better — different. Umbrel and StartOS are excellent, fast on-ramps with app stores and friendly dashboards, and they are the right call for most people getting started. NixOS sits at a more advanced tier: you describe the whole machine in one declarative file, get atomic rollbacks and reproducible rebuilds, and gain total customization, at the cost of a steeper learning curve. Pick based on whether you want infrastructure-as-code or appliance simplicity.
Do I need to learn the Nix language before I start?
You need a working familiarity with it, but not mastery. nix-bitcoin is explicitly designed so you can deploy a node without prior Nix experience by following its examples. Realistically, plan to spend a few evenings understanding the basics of configuration.nix, the nixos-rebuild workflow, and how options are set, before you are comfortable making changes confidently.
What does an atomic rollback actually protect me from?
From bricking yourself with a bad change. Each rebuild becomes a new “generation” that the bootloader remembers. If a config or upgrade breaks something, nixos-rebuild switch --rollback reverts the entire system to the previous generation, or you can boot an older generation straight from the boot menu if the machine won’t start. It is an operating-system-level undo button for your node.
Can I really run bitcoind, electrs, Tor, an LLM, and a Nostr relay on one box?
Yes, given adequate hardware. A full archival node plus electrs wants a fast NVMe and comfortably more than the chain’s current size in storage; a local LLM wants RAM and ideally a GPU for usable speeds. They coexist fine on NixOS because each is an isolated systemd service with its own privileges. Start with smaller models (3B-class) and scale up as your hardware allows.
Does the local-AI part leak anything to the cloud?
By default, no. The Ollama service binds to localhost:11434, so models run entirely on your own machine with no external API calls. That is the appeal of local AI for sovereign setups: your prompts and data never leave the box. If you deliberately expose it to your LAN or the internet, you take on the usual responsibility of securing that endpoint.
How do I keep the system updated without breaking it?
Update your pinned channel or flake inputs, then run nixos-rebuild test to trial the new build without changing the boot default. Verify your services are healthy, and only then nixos-rebuild switch to commit it. If anything regresses, roll back. Keeping configuration.nix in git means every update is a reviewable, revertible diff rather than a leap of faith.
Sources and further reading
- nixos.org — declarative, reproducible, reliable; the
nixos-rebuildand generation/rollback model. - nix-bitcoin (fort-nix) — security-hardened NixOS modules for bitcoind, electrs, Tor, Lightning, and more.
- NixOS wiki: Ollama —
services.ollamaoptions, acceleration, andloadModels.
