Skip to main content
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.
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).
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 and CPU-only instances. For ephemeral storage above 20Gi, include the size in the workload’s resource request. 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: 
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: 
volumes:
  - name: specialized-scratch
    hostPath:
      path: /mnt/local/my-unique-workload-id  # Always use a unique subdirectory
      type: DirectoryOrCreate
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.
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 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. 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.
Last modified on May 29, 2026