> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Storage
> Add persistent storage to your clusters so applications can store data that survives restarts and upgrades
Most applications need to store data that persists beyond the lifetime of a single container: databases, file uploads, caches, and configuration. Kubernetes handles this through persistent volumes, which provide storage that survives pod restarts, upgrades, and rescheduling.
Before your applications can use persistent storage, your cluster needs a StorageClass (a definition of what storage is available and how volumes are created). Managed clusters get one when they are created, so a PersistentVolumeClaim binds without any setup. You can add a second provider, or bring your own.
## What a managed cluster starts with
Every managed cluster is created with [Local Path Provisioner](/clusters/storage/local-path) installed and its `local-path` StorageClass marked as the cluster default. An application that requests storage without naming a class gets a volume on the worker node its pod runs on.
That default covers development and any workload that replicates its own data. It replicates nothing itself, so a workload whose durability must survive losing a node needs a replicated provider instead.
## Built-in storage providers
Akua includes two storage providers that cover development through production:
Direct local disk storage with the lowest latency. Ideal for development, single-node setups, and databases that handle their own replication.
Replicated block storage across multiple nodes with synchronous or asynchronous replication. Automatic failover on node failure.
## Choosing a provider
The key question is: **who handles data replication, the storage layer or your application?**
| | Local Path Provisioner | Piraeus (LINSTOR) |
| - | - | - |
| **Replication** | None (your application must handle it) | Storage-level, across nodes |
| **Failover** | Application-managed | Automatic (pods reschedule to a node with a replica) |
| **Volume size limits** | Not enforced (volumes are directories) | Enforced at the block device level |
| **Volume expansion** | Not supported | Supported |
| **Snapshots** | No | Yes |
| **Write latency** | Lowest (direct to local disk) | Depends on replication mode (sync or async) |
If your databases already replicate data across instances (like PostgreSQL streaming replication or MongoDB replica sets), Local Path Provisioner on NVMe SSDs gives you the best raw performance. If you want the storage layer to handle durability for you, use Piraeus.
## Deploy an additional storage provider
In your [cluster dashboard](https://akua.dev/clusters), select your cluster and navigate to the **Storage** tab.
Click **Deploy Storage** to open the provider selection sheet.
Select **Piraeus (LINSTOR)**. The card shows the provider's features and trade-offs.
Click **Deploy Storage**. The provider is deployed to your cluster as a standard application, and its StorageClasses appear in the Storage tab once it is running.
After deployment, the Storage tab shows your available StorageClasses with their provisioner, reclaim policy, and binding mode.
## Imported clusters
If you're using an [imported cluster](/clusters/import), you may already have storage configured by your cloud provider or infrastructure team:
* **Managed Kubernetes** (EKS, GKE, AKS): these typically come with a default StorageClass backed by cloud block storage (EBS, Persistent Disk, Azure Disk). Check your cluster's Storage tab to confirm. Akua does not add a default class to an imported cluster, because a second default would silently change where existing claims land.
* **Self-managed clusters**: you can deploy Akua's built-in providers, or use a CSI driver from your infrastructure provider. For example, if your VMs run on Hetzner, consider the [Hetzner CSI driver](https://github.com/hetznercloud/csi-driver) to provision cloud volumes directly.
Akua's built-in providers work on any cluster, managed or imported. If your cloud provider already supplies storage, you don't need to deploy an additional provider unless you want different storage characteristics (like replication across nodes).
## How applications use storage
When an application requests persistent storage through a PersistentVolumeClaim, Kubernetes automatically provisions a volume using your cluster's default StorageClass. Your Package resources declare the storage they need, and the cluster handles the rest.
Common applications that require persistent storage:
* Databases (PostgreSQL, MySQL, Redis, MongoDB)
* File storage and media uploads
* Message queues (RabbitMQ, Kafka)
* Search engines (Elasticsearch, Meilisearch)
## Related topics
Set up a managed cluster to deploy storage on.
Connect compute capacity to your cluster.
Connect your existing Kubernetes cluster.
Understand how clusters work in Akua.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.