Choosing the best Kubernetes storage for an ARM homelab isn’t the same problem most Kubernetes storage guides are trying to solve. Many comparisons assume abundant RAM, dedicated storage hardware, and infrastructure that looks very different from a small k3s cluster running on ARM.
This comparison focuses on four of the most common Kubernetes storage options for ARM64 clusters:
- Longhorn
- Ceph via Rook
- OpenEBS
- NFS via CSI
The goal isn’t to compare feature lists. It’s to determine which storage system actually makes sense on a real ARM homelab running k3s.
The analysis is based on the cluster used throughout this series: three RK1 modules (8GB, 16GB, and 32GB) running on Turing Pi 2.5. Resource overhead, ARM64 maturity, operational complexity, backup and recovery capabilities, and day-to-day management matter far more here than enterprise-scale feature sets.
If you’re deciding between Longhorn, Ceph, OpenEBS, and NFS or simply trying to find the best Kubernetes storage for a small ARM cluster, this guide will help you choose the right option.
The Comparison Criteria
The goal of this comparison isn’t to reward the most capable platform. It’s to identify which storage system fits a small k3s cluster running on ARM hardware with real resource constraints. A storage platform can look great on paper and still be a poor fit for a small k3s cluster if it consumes too much RAM, adds operational complexity, or assumes hardware resources you don’t have.
The rest of this comparison evaluates Longhorn, Ceph, OpenEBS, and NFS against six criteria, ranked by how much they matter on this hardware:
- ARM64 support quality: officially published multi-arch images carry less risk than community-maintained builds that can lag behind upstream releases.
- RAM and CPU overhead per node: critical when the smallest node in the cluster has 8GB total to split between storage daemons and actual workloads.
- Setup complexity on k3s specifically: a homelab cluster doesn’t have a platform team to absorb a complicated install.
- Replication and redundancy model: determines what happens to your data when a node goes down, and how much storage capacity you’re trading for that safety.
- Snapshot and backup support: matters once you’re running anything you’d actually be upset to lose.
- Community activity and maintenance status: a project losing contributors, slowing development, or changing governance is a real signal for long-term homelab bets, not just a vanity metric.
Longhorn: The Benchmark
Longhorn is the benchmark against which every other option in this comparison is measured. It’s the storage platform already running on this cluster, integrates cleanly with k3s, and has one of the most mature ARM64 implementations of any Kubernetes storage system available today.
ARM64 support isn’t a checkbox here. It started experimental back in Longhorn v1.1.0 and graduated to general availability in v1.4.0, after roughly a year of community testing closed the gap with the amd64 build.
The current stable release line sits around v1.12.x, and Longhorn’s own documentation lists 3 nodes, 4 vCPUs per node, and 4GiB of RAM per node as the minimum recommended hardware for the base V1 data engine. Some deployment guides push that further and suggest 8GB as a more comfortable floor per storage node specifically. On the 8GB RK1, that’s not a small ask: Longhorn’s controller stack and instance-manager pods are competing with k3s itself, plus whatever workloads you’re actually trying to run.
Longhorn’s weaknesses don’t usually appear during normal operation. They appear during failure recovery, replica rebuilds, and backup activity: the exact moments when storage reliability matters most. Replica rebuilds are where the 8GB node feels real pressure. Longhorn’s own troubleshooting documentation calls out resource exhaustion as a direct cause of failed replicas entering a rebuild loop, where a new replica gets rescheduled onto the same constrained node and fails again. Real-world deployments show the same pattern: replica rebuilds and backup operations can drive noticeable spikes in CPU and memory consumption, particularly when nodes are already resource constrained. On a small ARM cluster, rebuilds and backups are when Longhorn asks the most of a node, and the 8GB tier has the least to give.
Snapshots and backups are where Longhorn remains ahead of most lightweight alternatives. Volume snapshots, recurring backup jobs, and backup targets such as NFS or S3-compatible object storage are built into the platform rather than bolted on through external tooling. For homelab users, that reduces operational complexity considerably compared to building backup workflows around LocalPV or NFS.
The UI and controller stack carries its own baseline cost that’s easy to underestimate when sizing a small cluster. Between longhorn-manager, the CSI sidecars (attacher, provisioner, resizer, snapshotter), the engine images, and the instance managers, you’re running a meaningful number of always-on pods before a single PVC gets mounted. None of this is unique to ARM, but it lands harder on 8GB than on 32GB.
The result is a storage platform that isn’t the lightest option in this comparison, but remains the most balanced combination of ARM64 maturity, operational simplicity, and built-in data protection for a small k3s cluster.
Ceph via Rook: The Heavyweight
Ceph is one of the most mature and capable distributed storage systems available for Kubernetes. If your primary requirements are maximum flexibility, fine-grained control over replication, and support for multiple storage interfaces from a single platform, Ceph offers capabilities that few alternatives can match.
Its biggest advantage is flexibility. Ceph can expose block storage through RBD, shared filesystems through CephFS, and object storage through RGW, all from the same underlying storage cluster. Replication policies, failure domains, placement rules, snapshots, and recovery behavior are all highly configurable. None of the other options in this comparison offer the same breadth of functionality.
ARM64 support has genuinely improved. Ceph’s own images now publish as multi-arch manifests that include ARM64, eliminating a gap that once forced ARM users onto community-maintained builds.
The first challenge is memory, and the math is unforgiving here. Ceph’s documentation sets the default osd_memory_target at 4GiB per OSD, warns against going below 2GiB because performance degrades sharply, and recommends total node RAM greater than double the sum of OSD memory targets to leave room for the OS and other Ceph daemons. That’s before counting the mon and mgr daemons each node would likely also run, since Ceph wants at least three monitors for quorum.
Run that against the 8GB RK1: even pinning a single OSD to the absolute minimum 2GiB target, Ceph’s own headroom formula puts you at roughly 4GiB consumed by that one OSD, performing worse than default the whole time. Add a mon daemon, k3s and kubelet overhead, and the OS, and there’s little left for actual application pods.
Operational complexity is the second challenge. Longhorn can be installed with a single Helm chart and managed through a dedicated UI. Ceph requires monitors, managers, OSDs, CRDs, operator components, storage device planning, and a much deeper understanding of the platform when something goes wrong. That’s a reasonable trade-off if you need Ceph’s advanced capabilities. For many homelab users, it’s simply more complexity than necessary.
For most ARM homelabs running nodes in the 8GB–32GB range, Ceph via Rook is difficult to justify. The platform itself is excellent, but its hardware requirements and operational complexity don’t align particularly well with what small ARM clusters typically provide.
Ceph’s strengths become more valuable as storage requirements become more complex. If you need advanced storage policies, multiple storage interfaces, or fine-grained control over data placement and recovery, Ceph can make sense even on a smaller cluster. For most Turing Pi and RK1 deployments, however, Longhorn delivers the features people actually need with far less operational overhead.
OpenEBS: The Engine Question
OpenEBS isn’t one storage system, and treating it as one is the most common mistake in evaluating it for a homelab. It’s an umbrella project covering several distinct data engines with very different resource profiles, operational models, and maturity levels. The right answer to “is OpenEBS good for ARM?” depends entirely on which engine you’re talking about.
For ARM homelab users, the discussion effectively splits into two categories: LocalPV and OpenEBS Replicated PV (formerly known as Mayastor). One is among the lightest storage options available for Kubernetes. The other aims to provide replicated, distributed storage comparable to platforms like Longhorn.
LocalPV (specifically the Hostpath and LVM engines) is the lightweight option. It provisions directly against local node storage with no replication daemon running underneath, which means close to zero overhead beyond the provisioner itself. ARM64 multi-arch images for these engines have been available since OpenEBS v2.3.0, making LocalPV one of the more mature ARM64 storage options in this comparison.
The trade-off is exactly what you’d expect: no built-in replication. If a node fails, the volume fails with it unless redundancy exists elsewhere in the application stack. For workloads that already handle replication, backups, or failover themselves, that’s often an acceptable compromise in exchange for dramatically lower resource consumption.
OpenEBS Replicated PV tells a different story. Its goal is to provide replicated, high-performance storage similar in spirit to Longhorn, but it’s also solving a much harder problem than LocalPV. Replication, failover, and distributed storage coordination inevitably add complexity, and that complexity shows up in deployment requirements, troubleshooting, and operational overhead.
ARM64 support has improved considerably over the years, but OpenEBS Replicated PV still lacks the same level of ARM-specific adoption, documentation depth, and long-term field testing that Longhorn enjoys. That’s an important distinction. The question isn’t whether it can run on ARM today. It’s whether you’d choose it over a storage platform that already has years of proven ARM64 deployments behind it.
Project governance is worth a direct mention. OpenEBS was accepted into the CNCF at Sandbox maturity in 2024 and has continued progressing through the CNCF ecosystem. Community health remains generally positive, though contributor growth and project momentum aren’t as strong as some of the larger storage projects in this comparison.
The practical takeaway is straightforward. OpenEBS isn’t really one recommendation; it’s two very different ones.
If your workloads don’t require storage-level replication, OpenEBS LocalPV is one of the strongest alternatives to Longhorn on ARM. It delivers minimal resource overhead, mature ARM64 support, and straightforward operation.
If you do need replicated storage, the decision becomes less compelling. OpenEBS Replicated PV is capable, but Longhorn remains the more mature and battle-tested option for most ARM homelabs today. The result is that LocalPV stands out as OpenEBS’s strongest offering on small ARM clusters, while replicated workloads are generally better served elsewhere.
NFS via Provisioner: The Simple Option
The model here is the simplest of the four: one shared mount point, a CSI driver that creates Persistent Volumes against it, and no replication logic happening at the Kubernetes layer at all. Whatever redundancy exists lives entirely on the NFS server side, not in Kubernetes.
csi-driver-nfs has become the standard recommendation, replacing the older nfs-subdir-external-provisioner. The older provisioner predates the CSI standard and lacks several features expected from modern Kubernetes storage integrations. If you’re deploying NFS storage on a new cluster today, csi-driver-nfs is the obvious choice.
NFS also fits naturally into how many homelabs are already built. Unlike Longhorn, Ceph, or OpenEBS Replicated PV, it doesn’t require Kubernetes to become the storage platform. Instead, Kubernetes simply consumes storage that already exists elsewhere. That might be a TrueNAS box, a Synology NAS, an Unraid server, a dedicated storage node, or even an NVMe drive exported from another machine on the network.
Resource overhead is genuinely minimal. The driver itself runs as a small controller deployment plus a lightweight per-node daemonset responsible for mounting volumes. For ARM homelabs where every CPU core and gigabyte of RAM matters, that’s a meaningful advantage over replicated storage platforms.
The trade-off is equally straightforward. Kubernetes isn’t protecting your data here: the NFS server is. If the NFS server becomes unavailable, every workload depending on those volumes is affected. Replication, snapshots, backups, and redundancy are all responsibilities of the storage system behind the NFS export rather than the Kubernetes storage layer itself.
That’s what makes NFS fundamentally different from the other options in this comparison. Longhorn, Ceph, and OpenEBS Replicated PV are storage platforms. NFS is simply a way to connect Kubernetes to a storage platform that already exists.
The practical takeaway is simple. NFS is rarely the best choice when you’re building a fully self-contained Kubernetes storage layer. It is, however, an excellent choice if you already have centralized storage elsewhere and want the lowest possible operational overhead.
If Longhorn is the best all-around storage platform for a small ARM cluster, NFS is the simplest way to connect Kubernetes to storage you already trust.
Comparison Matrix
| Criterion | Longhorn | Ceph (Rook) | OpenEBS | NFS |
| ARM64 support | GA since v1.4.0, mature ARM64 support with multi-arch images and broad k3s adoption | Mature ARM64 support via multi-arch images; no major architecture limitations | LocalPV: mature ARM64 support. Replicated PV: improving ARM64 support but less proven on ARM than Longhorn | Architecture-agnostic; simply mounts an existing NFS export |
| RAM/CPU overhead per node | Moderate; additional overhead from replicas, controllers, and backup operations | High; OSDs and supporting daemons consume significant memory and CPU resources | LocalPV: very low overhead. Replicated PV: higher due to distributed storage services | Very low; lightweight controller and mount daemonset |
| Setup complexity on k3s | Low; straightforward installation and management | High; multiple components, storage planning, and operational complexity | LocalPV: low. Replicated PV: moderate to high depending on deployment requirements | Very low; point a StorageClass at an existing NFS export |
| Replication model | Built-in, configurable replica count (default 3) | Built-in, highly configurable distributed replication | LocalPV: none. Replicated PV: built-in replication | None at the Kubernetes layer; redundancy depends on the NFS backend |
| Snapshot/backup support | Native snapshots and backups to NFS or S3-compatible targets | Native snapshots and mature backup ecosystem | LocalPV: relies on underlying storage tooling. Replicated PV: supported | Depends on the storage system behind the NFS export |
| Community activity | Backed by SUSE/Rancher with active development and strong community adoption | Large, mature upstream community with extensive production use | CNCF project with active development and growing ecosystem | Maintained under Kubernetes SIG Storage with steady release cadence |
| Pick this if… | Option |
| You want the best balance of ARM64 maturity, built-in replication, snapshots, backups, and operational simplicity | Longhorn |
| You need advanced storage features, multiple storage interfaces (RBD, CephFS, RGW), or fine-grained control over replication and recovery | Ceph (Rook) |
| Your workload doesn’t need storage-level replication and you want the lightest possible local storage on ARM | OpenEBS LocalPV |
| You already have a NAS, storage server, or centralized storage and want the simplest way to expose it to Kubernetes | NFS via csi-driver-nfs |
The Recommendation
Longhorn isn’t the lightest option here, and it isn’t the most flexible. Ceph offers more advanced storage capabilities, while OpenEBS LocalPV consumes fewer resources. The reason Longhorn comes out on top is that it strikes the best balance between the criteria that matter on a small ARM cluster.
ARM64 maturity is the first factor. Longhorn has years of real-world ARM64 deployments behind it and remains one of the most widely used storage platforms in the k3s ecosystem. Operational simplicity is the second. Compared to Ceph, installation, upgrades, troubleshooting, and day-to-day management are significantly easier while still providing built-in replication, snapshots, and backup capabilities.
The third factor is feature efficiency. Longhorn certainly consumes more resources than LocalPV or NFS, but those alternatives achieve their lower overhead by giving up storage-level replication. Longhorn remains one of the few options that provides replicated storage, snapshot support, backup integration, and a mature management experience without requiring a separate storage platform alongside Kubernetes.
The one alternative worth highlighting directly is OpenEBS LocalPV. If your workloads genuinely don’t require storage-level replication, such as single-instance databases, scratch space, caches, or workloads with application-level redundancy, LocalPV is a compelling option. It delivers mature ARM64 support with minimal resource overhead.
For most Turing Pi and RK1 deployments, however, Longhorn remains the easiest recommendation. It isn’t the lightest solution, but it offers the best balance of ARM64 maturity, data protection, and operational simplicity for a small k3s cluster.
Related Articles
If you’re building an ARM homelab around k3s and Longhorn, these guides continue the journey:
- k3s on Turing Pi 2.5: Persistent Storage and Load Balancing on ARM – Deploy Longhorn, configure persistent volumes, and add MetalLB to your ARM Kubernetes cluster.
- Turing Pi 2.5 + RK1 Complete Setup Guide: From Unboxing to a Running k3s Cluster – Build the foundation for a multi-node ARM cluster and install k3s on RK1 modules.
- k3s vs K0s vs MicroK8s vs RKE2: Which Lightweight Kubernetes Fits an ARM Homelab? – Compare lightweight Kubernetes distributions and decide which control plane belongs on your hardware.
FAQ
Does Ceph run well on ARM64?
Yes. Modern Ceph and Rook releases provide mature ARM64 support through multi-arch container images. The bigger challenge for ARM homelabs is resource consumption rather than architecture compatibility. Ceph’s memory requirements and operational complexity can be difficult to justify on small clusters with 8GB to 32GB nodes.
What is the lightest persistent storage option for k3s on ARM?
OpenEBS LocalPV is generally the lightest Kubernetes-native storage option in this comparison. It provisions directly against local storage and avoids the replication overhead of platforms like Longhorn or Ceph. NFS can be even lighter from the cluster’s perspective, but only because the storage workload is moved to an external server.
Can I use NFS for Kubernetes storage on a homelab?
Yes. NFS remains a practical option for homelabs that already have centralized storage available. Using csi-driver-nfs, Kubernetes can dynamically provision Persistent Volumes from an existing NFS export with very little CPU or memory overhead. The trade-off is that replication, snapshots, backups, and redundancy become the responsibility of the NFS server rather than Kubernetes.
Is Longhorn good for ARM-based Kubernetes clusters?
Yes. Longhorn is one of the most mature Kubernetes storage platforms available on ARM64 and integrates particularly well with k3s. It provides built-in replication, snapshots, backups, and a dedicated management UI while maintaining a relatively straightforward operational model for homelab users.
What is the difference between OpenEBS and Longhorn?
Longhorn provides a single storage platform with built-in replication, snapshots, backups, and a consistent management experience. OpenEBS is a collection of storage engines with different trade-offs. LocalPV prioritizes minimal overhead and simplicity, while OpenEBS Replicated PV focuses on distributed storage. In practice, the decision usually comes down to whether you need storage-level replication or would prefer the lowest possible resource consumption.
Which Kubernetes storage option is best for a small ARM homelab?
For most ARM homelabs, Longhorn remains the strongest overall choice because it balances ARM64 maturity, built-in data protection, and operational simplicity. OpenEBS LocalPV is the best alternative when minimizing resource usage is more important than storage-level replication.