Node data persistence in persistent volume claims by Jhoyola · Pull Request #787 · bitcoin-dev-project/warnet

Jhoyola · 2026-02-17T10:44:44Z

At Torq / Mion we intend to move to using warnet for persistent regtest lightning network for development locally. This requires to have the nodes keep their state indefinetly, to not need to constantly recreate the network, connect nodes to our software etc. I tried to do it by defining volumes and volumeMounts, but for bitcoin core the .bitcoin directory is already mounted so it conflicted on making a new mount to the same dir. This PR aims to add built-in, easy and configurable persistence option.

Overview

Uses persistent volume claims. Either auto generated or pre-defined
A new helm configuration value set "persistence"
- Simply add enabled: true to create automatic PVC for the node
- Use existingClaim: <existing-pvc-name> to use pre-created PVC instead of creating new one
- If not set, everything should work as it did before
Down command prompts to delete the PVCs if they exist
Added documentation on how to use this

Tested in Windows WSL environment.

pinheadmz

Concept ACK so far, a few questions below.

It would be great if possible if you could add a test that demonstrates the data recovery. I feel like there's one step missing in the docs (see below) that I could use to test the feature.

Have you also tried the persistent volumes with a cloud provider like Digital Ocean? I'm just wondering if there's any obstacles with that. I imagine the volumes persist as long as the cluster is running.

Also - tested using Windows WSL! I know we connected on #655 already, I'm just impressed you are using windows ;-)

And finally thanks for the contribution! Your PR is clean, well organized, and the commits show understanding of the repo which is really great. Please keep in touch about how you're using Warnet at Mion and if there's anything else you need.

pinheadmz · 2026-02-17T14:36:58Z

resources/charts/bitcoincore/charts/cln/templates/pod.yaml

    - configMap:
        name: {{ include "cln.fullname" . }}
      name: config
+    - name: shared-volume


e966d99

This can be named something more specific like cln-datadir and below, lnd-datadir. I think the reason it is called "shared volume" on main is because for lnd it is shared with circuit breaker and other containers that read the macaroons, etc. But that was a poor choice of name and we can fix it now.

pinheadmz · 2026-02-17T14:37:57Z

resources/charts/bitcoincore/charts/cln/values.yaml

+persistence:
+  enabled: false
+  storageClass: ""
+  accessMode: ReadWriteOnce


e966d99

I'm not super familiar with these options, but is there a reason you chose ReadWriteOnce which is accessible by the entire kubernetes node and not ReadWriteOncePod which seems to be a bit more specific for the use case?

I'm not very good with Kubernetes, but good suggestion, ReadWriteOncePod is better. I changed it to that.

pinheadmz · 2026-02-17T14:49:33Z

docs/persistence.md

+```yaml
+persistence:
+  enabled: true
+  existingClaim: "bitcoin-node-001-data"


763d940

How do you get the name of the claim from the last lifecycle?

The name is decided based on tank name, namespace and node type. I added it to the documentation.

Jhoyola · 2026-02-18T10:32:05Z

I didn't test with any cloud setup. I'm actually quite new to kubernetes and never ran it in cloud. I would imagine this works nicely there too.

One thing I'm still unsure about: Now it's possible to leave the volumes intact even after warnet down command. But currently I don't think there is a way of restarting the network gracefully with existing data. The deploy command kind of works, but returns some errors because it expects it to be the first startup. And anyways if wallets, channels etc. already exist, it's not correct to recreate them I think. Would it make sense to create some "restart" command?

I at least added a small fix for the ensure_miner to allow to load existing miner wallet without throwing an error.

pinheadmz · 2026-02-18T12:12:21Z

src/warnet/control.py

+                inquirer.Confirm(
+                    pvc_confirmed,
+                    message=click.style(
+                        "Do you also want to delete all PVCs containing persistent data? This will result in permanent loss of data.",


Also just noticed this message is too long for click I guess? Just barely

Shortened it in rebase

…pvcs

Jhoyola · 2026-02-18T18:14:22Z

Now by adding restartPolicy: Always and loading unloaded miner wallet in ensure_miner the nodes seem operational after each computer restart. The ensure_miner fix is important to be able to start miner after pod restart.

Jhoyola · 2026-02-19T09:01:16Z

For me the ln_test passes locally on this branch so maybe there is some race condition or similar?

pinheadmz · 2026-02-19T18:42:42Z

For me the ln_test passes locally on this branch so maybe there is some race condition or similar?

Our ci is notoriously flaky, working with kubernetes has this "eventual consistency" to it which isn't easy to reproduce all the time. Anyway I restarted CI on your PR and everything looks good.

I'm going to add a test myself and push to your branch (if you don't mind) then we'll be RFM.

Jhoyola · 2026-02-19T18:52:28Z

I'm going to add a test myself and push to your branch (if you don't mind) then we'll be RFM.

Thanks, yes, sounds good.

charts: add option for persisting bitcoin-core, lnd and cln data

e966d99

pinheadmz reviewed Feb 17, 2026

View reviewed changes

Jhoyola force-pushed the node-persistence branch from bd1886c to e62cf6d Compare February 18, 2026 10:25

pinheadmz reviewed Feb 18, 2026

View reviewed changes

Jhoyola added 5 commits February 18, 2026 17:51

control: allow deletion of pvcs in down command

173667f

docs: Documentation about persistent data volumes

0c96009

Rename data volumes, rename persistent pvcs, add documentation about …

ac69287

…pvcs

Keep pvcs after helm release uninstall

81b6da5

ensure_miner check for existing wallet

bf495eb

Jhoyola force-pushed the node-persistence branch from e62cf6d to bf495eb Compare February 18, 2026 15:52

Jhoyola added 2 commits February 18, 2026 20:07

Fix unloaded wallets check in ensure_miner

88e27dd

docs: note about restartPolicy to persistence docs

057f40d

Conversation

Jhoyola commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Uh oh!

pinheadmz left a comment

Choose a reason for hiding this comment

Uh oh!

pinheadmz Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

pinheadmz Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

Jhoyola Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

pinheadmz Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

Jhoyola Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

Jhoyola commented Feb 18, 2026

Uh oh!

pinheadmz Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

Jhoyola Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

Jhoyola commented Feb 18, 2026

Uh oh!

Jhoyola commented Feb 19, 2026

Uh oh!

pinheadmz commented Feb 19, 2026

Uh oh!

Jhoyola commented Feb 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Comments

Jhoyola commented Feb 17, 2026 •

edited

Loading