There’s a whole bunch of “it loses all your data” bugs in OpenZFS too, ironically, although it’s way way less fragile than btrfs in general.

That said, the latter is pretty much solid too, unless you do raid5-like things.

FWIW that java app isn’t much memory hungry and it’s not cpu-intensive at all. There are no issues with running java apps at all if you spend 5 minutes figuring the basix flags on how to set the memory limits or run it in a memory-limited cgroup via some containers runtime.

I run k3s in my homelab as a single node cluster. I’m very familiar with kubernetes in general, so it’s just easier for me to reason with a control plane.

Some of the benefits I find useful:

• ArgoCD set to fire and forget will automatically update software versions as they happen. I use nix to lower the burden of maintaining my chart forks. Sometimes they break, but
• VictoriaMetrics easily collects all the metrics from everything in the cluster with very little manual tinkering, so I am notified when things break, and
• zfs-localpv provides in-cluster management for data snapshots, so when things do break I can easily roll back to a known good state.

k3s is, of course, a memory hog, I’d estimate it and cilium (my CNS of choice) eat up about 2Gb ram and a bit under one core. It’s something you can tune to some extent, though. But then, I can easily do pod routing via VPN and create services that will automatically get a public IP from my endless IPv6 pool and get that address assigned a DNS name in like 10 lines of Yaml.