Skip to main content
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 , which provide storage that survives pod restarts, upgrades, and rescheduling. Before your applications can use persistent storage, your cluster needs a — a definition of what storage is available and how volumes are created. CNAP provides two built-in storage providers you can deploy with one click, or you can use your own.

​
Built-in storage providers

CNAP includes two storage providers that cover development through production:

Local Path Provisioner

Direct local disk storage with the lowest latency. Ideal for development, single-node setups, and databases that handle their own replication.

Piraeus (LINSTOR)

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 ProvisionerPiraeus (LINSTOR)
ReplicationNone — your application must handle itStorage-level, across nodes
FailoverApplication-managedAutomatic — pods reschedule to a node with a replica
Volume size limitsNot enforced (volumes are directories)Enforced at the block device level
Volume expansionNot supportedSupported
SnapshotsNoYes
Write latencyLowest — direct to local diskDepends 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 a storage provider

1

Open the Storage tab

In your cluster dashboard, select your cluster and navigate to the Storage tab.
2

Click Deploy Storage

If no storage provider is installed, you’ll see an empty state with a Deploy Storage button. Click it to open the provider selection sheet.
3

Choose a provider

Select Local Path Provisioner for development or Piraeus (LINSTOR) for production. Each card shows the provider’s features and trade-offs.
4

Deploy

Click Deploy Storage. The provider is deployed to your cluster as a standard application. A default StorageClass is created automatically, so your applications can request storage right away.
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, 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.
  • Self-managed clusters — You can deploy CNAP’s built-in providers, or use a from your infrastructure provider. For example, if your VMs run on Hetzner, consider the Hetzner CSI driver to provision cloud volumes directly.
CNAP’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 ), Kubernetes automatically provisions a volume using your cluster’s default StorageClass. This happens transparently — your just need to 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)