> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# About local storage

> High-performance, encrypted NVMe-backed ephemeral storage on CoreWeave Nodes for scratch space and caching

CoreWeave GPU and CPU Nodes provide high-performance, Node-local ephemeral storage on NVMe RAID, mounted at `/mnt/local`. Use this storage for temporary data such as intermediate training artifacts, caches, render outputs, or logs. This page is for workload authors who need fast scratch space close to compute and want to understand how to request it safely on CoreWeave Kubernetes Service (CKS).

Pod container filesystems (the writable layer created by the container runtime) and Kubernetes `emptyDir` volumes are stored on this NVMe-backed storage by default, through kubelet and containerd directories under `/mnt/local`. As a result, most workloads benefit from local storage without any additional configuration.

<Note>
  Local storage applies to workloads running on CoreWeave Kubernetes Service (CKS). Data is non-persistent and may be lost when a Pod is deleted or when the Node reboots (for example, during maintenance or failure).
</Note>

## Recommended emptyDir volumes

For most scratch-storage use cases, use `emptyDir` volumes. `emptyDir` is the standard Kubernetes mechanism for Node-local scratch space. An `emptyDir` volume is created when a Pod is scheduled onto a Node and is deleted automatically when the Pod is removed.

On CoreWeave, `emptyDir` volumes are:

* **Backed by NVMe**: Data is stored under the kubelet Pod directories on `/mnt/local`, an encrypted NVMe RAID array dedicated to ephemeral workload storage. This provides high throughput and low latency for scratch workloads.

* **Better for heavy writes**: Writes to an `emptyDir` volume go directly to the underlying filesystem, avoiding the copy-on-write overhead of the container image overlay filesystem. For large or write-heavy scratch data, use `emptyDir` instead of writing to arbitrary paths in the container root filesystem.

### Set the amount of local ephemeral storage

Size your `emptyDir` volume to match the scratch space your workload needs. This protects the Node from runaway usage and helps the scheduler place your Pod correctly.

The amount of available local ephemeral storage depends on the Node type. For information on ephemeral storage size per instance type, see [GPU instances](/platform/instances/gpu-instances) and [CPU-only instances](/platform/instances/cpu-instances).

For ephemeral storage above `20Gi`, include the size in the [workload's resource request](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#setting-requests-and-limits-for-local-ephemeral-storage). This lets the scheduler place the Pod on a Node with enough capacity.

The following example shows where to set the size limit for an `emptyDir` volume:

```yaml theme={"system"}
volumes:
  - name: scratch
    emptyDir:
      sizeLimit: 50Gi  # Recommended: set a limit matching your expected usage
```

## Advanced hostPath volumes

`hostPath` volumes mount a specific directory on the Node's filesystem directly into a Pod. In most cases, `emptyDir` is the right choice for scratch storage. Use `hostPath` only when you explicitly need to access a specific path on the Node's filesystem (for example, a legacy application that expects a hard-coded directory under `/mnt/local`).

The following example shows where to set a `hostPath` volume:

```yaml theme={"system"}
volumes:
  - name: specialized-scratch
    hostPath:
      path: /mnt/local/my-unique-workload-id  # Always use a unique subdirectory
      type: DirectoryOrCreate
```

<Warning>
  **Restrict paths to `/mnt/local/`.** Do not mount volumes outside of `/mnt/local/` (such as `/tmp/` or `/var/`). Other host paths are on, or include, the Node's RAM-backed root filesystem. Filling this filesystem can quickly exhaust memory and destabilize the Node.
</Warning>

When using `hostPath`:

* **Understand the trade-offs**: `hostPath` bypasses Kubernetes storage isolation and couples your Pod to a particular Node layout. Volumes aren't cleaned up automatically, and you're responsible for managing path uniqueness, cleanup, and avoiding conflicts with other workloads.
* **Remember data is ephemeral**: Data on `/mnt/local` is encrypted at rest and tied to in-memory keys. When the Node reboots, those keys are discarded and data becomes inaccessible.

## Security

Drives are encrypted in 8-drive [RAID10 (RAID 1+0) arrays](https://en.wikipedia.org/wiki/Nested_RAID_levels#RAID_10_\(RAID_1+0\)) using an in-memory key. This key is lost on reboot, providing a crypto-shredding feature that renders encrypted data unusable and ensures data security.

## Non-persistent storage

Because Node-local ephemeral storage is non-persistent, it doesn't persist through Node reboots and doesn't require a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). If you need data to survive Node reboots or be shared across Nodes, use a persistent storage option instead. To create a persistent filesystem volume that is independent of Node status, see [Create Distributed File Storage volumes](/products/storage/distributed-file-storage/create-volumes).