Skip to main content

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.

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. Pod container filesystems (the writable layer created by the container runtime) and Kubernetes emptyDir volumes are stored on this NVMe-backed storage by default, via kubelet and containerd directories under /mnt/local.
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).
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, which is 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, prefer emptyDir over writing to arbitrary paths in the container root filesystem.

​
Setting the amount of local ephemeral storage

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. If you require a large amount (above 20Gi) of ephemeral storage, include the size requirement in the workload’s resource request. 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

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 are not cleaned up automatically, and you are 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, ensuring data security.

​
Non-persistent storage

Because Node-local ephemeral storage is non-persistent, it does not persist through Node reboots, and does not require a Persistent Volume. To create a persistent filesystem volume that is independent of node status, see Create Distributed File Storage volumes.
Last modified on April 2, 2026