> ## 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.
# Local Path Provisioner
> Direct local disk storage for development, single-node setups, and latency-sensitive workloads
Local Path Provisioner uses the worker node's local disk to create persistent volumes. It requires no external dependencies or configuration, and delivers fast I/O since data lives on the same machine as your application.
## When to use
* **Development and testing**: get persistent storage running in seconds
* **Single-node clusters**: local testing with [Multipass](/clusters/local-testing) or a single production server
* **Latency-sensitive production workloads**: databases on NVMe SSDs where direct disk access matters and the application handles its own replication (for example, PostgreSQL with streaming replication or MongoDB replica sets)
* **Simple production setups**: single-node servers where replication isn't needed
Local Path Provisioner stores data on a single node with **no replication**. If the node fails or is replaced, the data is lost. For production workloads that need storage-level durability, use [Piraeus (LINSTOR)](/clusters/storage/piraeus) instead, unless your application handles replication itself.
## How it works
When an application requests storage, Local Path Provisioner creates a directory on the node's local filesystem and mounts it into the pod. The volume is tied to that specific node. If Kubernetes needs to reschedule the pod, it schedules it back to the same node so it can access its data.
**Key characteristics:**
* One volume per PersistentVolumeClaim
* Pods using local storage are pinned to the node where the volume was created
* No network overhead: reads and writes go directly to local disk, providing the lowest possible latency
## Deploy
Navigate to your cluster's **Storage** tab, click **Deploy Storage**, and select **Local Path Provisioner**. The provider deploys in under a minute and creates a default StorageClass automatically.
After deployment, any application that requests a PersistentVolumeClaim will get a local volume provisioned on the node where the pod is scheduled.
## Limitations
* **Single-node only**: data lives on one node and is not replicated
* **No failover**: if the node goes down, pods using local storage can't be rescheduled elsewhere until the node recovers
* **No snapshots**: volume snapshots are not supported
* **No volume size enforcement**: requested storage sizes in PersistentVolumeClaims are not enforced. Since each volume is just a directory on the node's filesystem, it can grow to use all available disk space regardless of the size you request ([GitHub #107](https://github.com/rancher/local-path-provisioner/issues/107)).
* **No volume expansion**: resizing a PVC after creation is not supported. Attempting to expand a volume causes the controller to log repeated errors because the provisioner has no resize capability ([GitHub #190](https://github.com/rancher/local-path-provisioner/issues/190)).
* **Node affinity**: pods are pinned to the node where their volume was created
## Local storage in production
Local Path Provisioner can be a valid production choice when your priority is raw disk performance and your application handles data replication at the application level. Databases like PostgreSQL, MySQL, and MongoDB have built-in replication that keeps copies of data across multiple instances; they don't need the storage layer to replicate for them. In these cases, local storage on NVMe SSDs gives you the lowest latency without the overhead of network-based replication.
The trade-off is operational: you're responsible for ensuring your application's replication is configured correctly. If it isn't, a node failure means data loss.
## Moving to replicated storage
When you want storage-level replication instead of managing it at the application layer:
1. Deploy [Piraeus (LINSTOR)](/clusters/storage/piraeus) for replicated storage across nodes
2. Migrate your data by backing up and restoring from the application level (database dumps, file exports)
3. Remove Local Path Provisioner once all workloads have moved
You can run both storage providers simultaneously during migration. Set Piraeus as the default StorageClass, and new volumes will automatically use replicated storage while existing local volumes continue to work.
## Related topics
Production-grade replicated storage across multiple nodes.
Compare providers and deploy storage to your cluster.
Connect worker nodes that provide local disk for this provider.
Project source and upstream documentation.