## Introduction

Kubernetes supports multiple storage access modes. One of them is `ReadWriteMany` (RWX), which allows multiple pods to access the same volume simultaneously.

RWX storage is commonly used for:

- Shared application data
- Media and asset storage
- Machine learning datasets
- Legacy applications requiring shared filesystems
- Multi-replica workloads with shared state

However, RWX storage introduces additional operational and architectural complexity compared to local persistent storage. Shared filesystems require coordination between multiple clients accessing the same data simultaneously, which adds overhead around consistency, locking, replication, and recovery.

## Local storage vs RWX storage

In Syself Autopilot, volumes with `ReadWriteOnce` (RWO) are the preferred option. It is supported either with [network storage](/docs/hetzner/apalla/how-to-guides/storage/using-hcloud-storage) with Hetzner Cloud Volumes, or with [bare metal local storage](/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal). RWO volumes are simpler to operate and more predictable under load. Especially if you are using bare metal local storage, they are also much faster and have lower latency.

Most modern cloud-native applications are designed around stateless replicas, and rely on object storage and databases to save state. As a result, many workloads do not actually require a shared filesystem.

Before deploying RWX storage, evaluate whether the application truly requires simultaneous filesystem access across multiple pods.

## Syself Autopilot does not support Longhorn

Syself Autopilot, being built on top of Cluster API, treats nodes as replaceable resources that may be automatically reprovisioned during Kubernetes upgrades, scaling operations and self-healing events.

Distributed block storage systems such as Longhorn tightly couple storage replication and data availability to the lifecycle of Kubernetes nodes. In an environment where machines are frequently replaced or reprovisioned, this introduces additional complexity around replica recovery, resynchronization, scheduling, and failure handling.

For many workloads, local storage combined with application-level replication or external shared storage systems provides better operational characteristics with lower complexity.

## Recommended RWX approaches

If your workloads require shared filesystem access, we recommend using dedicated RWX-oriented storage solutions instead of distributed block storage systems.

For most cloud-native applications, object storage is often a better fit than a shared POSIX filesystem. However, some workloads still require a traditional filesystem, especially in AI, machine learning, media processing, and large shared dataset environments.

For these scenarios, Syself commonly recommends [JuiceFS](https://juicefs.com/).

JuiceFS combines object storage backends with distributed metadata management and Kubernetes CSI integration, allowing workloads to access shared storage using standard filesystem semantics while keeping the underlying storage decoupled from Kubernetes nodes.

This architecture aligns particularly well with the patterns used by Syself Autopilot. Since the persistent data lives independently from the cluster nodes, storage operations become less tightly coupled to node lifecycle events.

For implementation details, refer to the official [JuiceFS Kubernetes documentation](https://juicefs.com/docs/csi/introduction/).

Other distributed storage systems such as [SeaweedFS](https://seaweedfs.com) may also be suitable depending on workload requirements. SeaweedFS combines object storage, filesystem capabilities, and replication features in a lightweight distributed architecture that can work well in Syself Autopilot.

## Need help designing your storage architecture?

Storage architecture decisions have long-term operational impact. RWX storage alone does not automatically provide high availability, as the underlying storage system still requires proper replication, backup strategies, and failure recovery planning.

The Syself team can help evaluate and design the appropriate storage architecture for your environment and workload requirements. If you are planning a production deployment and want guidance on storage, [contact the Syself team](/demo).