CoreWeave
Search…
Getting Started with Storage
Learn about CoreWeave Storage options
High-performance, network-attached storage volumes for both containerized workloads and Virtual Servers are easy to provision and manage on CoreWeave Cloud.
Available in both all-NVMe and HDD tiers, Storage Volumes can be created as Block Volumes or Shared File System Volumes, and can be resized at any time. Storage is managed separately from compute, and can be moved between instances and hardware types.
CoreWeave Cloud Storage Volumes are built on top of Ceph, a software defined scale-out enterprise grade storage platform. Built with triple replication, the CoreWeave Cloud Storage platform is built to provide high-availability, performant storage for your most demanding Cloud-native workloads.

In addition to traditional storage volumes, CoreWeave also offers S3-compliant Object Storage.

​
🀝
Storage Volumes are accessible by both containerized and hypervisor workloads
​
πŸ“ˆ
Easily resized to add more capacity at any time
​
🀯
Single Storage Volumes can be scaled to the multiple Petabyte level
​
βœ…
Create and manage your Cloud Storage Volumes from the Storage Volumes UI, or via kubectl
​
🏁
Clone your Block Storage Volumes to instantiate Virtual Servers from a template
​
πŸ”₯
Run automated backups of your Shared File System Volumes to BackBlaze via CoreWeave Apps​

Block Storage Volumes are attached to containerized workloads and Virtual Server instances as high-performance virtual disks.
When served from our all-NVMe storage tier, these virtual disks readily outperform local workstation SSDs, and are scalable to the Petabyte scale. These volumes are presented as generic block devices, so they are treated by the operating system like a typical physically connected storage device.

POSIX compliant Shared File System Volumes can be attached to both containerized and Virtual Server workloads to provide native shared file systems.
It is possible to attach these Volumes to many instances at the same time. They are great for centralized asset storage, whether for sharing with co-workers in the cloud or as a data source for massively parallel computation.

The All-NVMe CoreWeave Cloud storage tier offers the highest performance in both throughput and IOPS. Great for hosting the root disk of a Virtual Server, or as the backing store for a transactional database, the All-NVMe tier can provide up to 10 million IOPS per Volume and peak storage throughput into the Tbps range.
All-NVMe Cloud Storage Volumes can be provisioned using the following storage class convention:
Block Volumes: block-nvme-<region> Shared File System: shared-nvme-<region>

The HDD CoreWeave Cloud storage tier offers excellent throughput optimized performance at a lower cost. Great for large file storage with sequential IOPS access patterns, the HDD tier is backed by an NVMe caching layer to improve performance and scale throughput capacity.
All HDD Cloud Storage Volumes can be provisioned using the following storage class convention: Block Volumes: block-hdd-<region> Shared File System: shared-hdd-<region>

Storage is billed per gigabyte of allocated (requested) space as an average over a billing month.

Storage Volumes can be configured and deployed using either the CoreWeave Cloud UI or using the Kubernetes command line (kubectl).
Cloud UI
CLI
Deployment method: CoreWeave Cloud UI
​The CoreWeave Cloud UI provides an easy-to-use storage configuration page.
To access it, first log in to your CoreWeave Cloud account. Then, from the left-hand menu, navigate to Storage Volumes.
​
The storage volumes link on the left-hand menu of the Cloud UI
​
From the upper right-hand corner, click the New Volume button. This will launch the volume configuration modal.
​
The New Volume button
​
The volume configuration modal
On this modal, configure your desired Volume settings. Finally, click Create to deploy the storage volume.
Deployment method: Kubernetes CLI
Storage can also be managed via the Kubernetes API natively using kubectl. Below are some example manifests to do this, as well as descriptions of the fields used.
​
Field name
Field type
Description
storageClassName
string
Sets the storage class name for the volume's PVC; determines which kind of storage class the volume will be
accessModes
list
Sets the access mode for the volume
resources
array
Defines which resources with which to provision the Volume
requests
array
Defines the resource requests to create the volume
storage
string
Determines the size of the volume, in Gi
​

All-NVMe Cloud Storage Volumes can be provisioned using the following storage class convention:
Block Volumes: block-nvme-<region> Shared File System: shared-nvme-<region>
For example:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data
spec:
storageClassName: block-nvme-ord1
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
​

All HDD Cloud Storage Volumes can be provisioned using the following storage class convention:
Block Volumes: block-hdd-<region> Shared File System: shared-hdd-<region>
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: shared-data
spec:
storageClassName: shared-hdd-ord1
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi

The steps below describe how to attach storage for usage on both Virtual Servers and Pods according to deployment method.
Note
The volumes must first be created and provisioned before they can be attached to a Pod or Virtual Server.
Cloud UI
CLI
Deployment method: CoreWeave Cloud UI

Filesystem attachments are specified under the Attach Filesystems menu while creating a Virtual Server. To attach a filesystem, select the volume you wish to attach from the Available Volumes menu. The selected volumes will appear under the Attach Volume column. Finally, configure the mount point under the Mount As column.
Example
The Attach Filesystems menu during Virtual Server creation
​

Note
Attaching block device storage is not currently achievable via the Cloud UI. Please see CLI options to attach block storage devices to Virtual Servers.
Deployment method: Kubernetes CLI
​
Select instructions for Pods or Virtual Servers below.
Attach to:
​Pods​
​Virtual Servers​

To attach filesystem storage to a Pod, specify the mountPath and name under the volumeMounts stanza.
Then, specify the volumes.name and the persistentVolumeClaim.claimName.
​
Example
apiVersion: v1
kind: Pod
metadata:
name: filesystem-storage-example
spec:
containers:
- image: nginx:1.14.2
name: nginx
volumeMounts:
- mountPath: /storage
name: filesystem-storage
volumes:
- name: filesystem-storage
persistentVolumeClaim:
claimName: filesystem-storage-pvc
​

As a kind of device, block storage is attached to a Pod by providing the devicePath under volumeDevices, in addition to the volumes.name and persistentVolumeClaim.claimName values.
​
Example
apiVersion: v1
kind: Pod
metadata:
name: block-storage-example
spec:
containers:
- image: nginx:1.14.2
name: nginx
volumeDevices:
- devicePath: /dev/vda1
name: block-storage
volumes:
- name: block-storage
persistentVolumeClaim:
claimName: block-storage-pvc
​

The filesystem attachment information for Virtual Servers is provided in the storage.filesystems stanza of the spec. Here, specifying values for filesystems.name, filesystems.mountPoint, and persistentVolumeClaim.name.
​
Example
apiVersion: virtualservers.coreweave.com/v1alpha1
kind: VirtualServer
metadata:
name: filesystem-storage-example
spec:
[...]
storage:
filesystems:
- name: filesystem-storage
mountPoint: /mnt/storage
spec:
persistentVolumeClaim:
name: filesystem-storage-pvc

To attach a block storage device to a Virtual Server, specify the block device's values in the storage.additionalDisks stanza.
​
Example
apiVersion: virtualservers.coreweave.com/v1alpha1
kind: VirtualServer
metadata:
name: block-storage-example
spec:
...
storage:
additionalDisks:
- name: block-storage
spec:
persistentVolumeClaim:
name: block-storage-pvc

Volumes can be expanded by simply increasing the storage request, then reapplying the manifest. Storage Volumes can be resized in the CoreWeave Cloud UI, or via kubectl.
Important
Shared File System Volumes are resized online without disruption the workload.
Resizing Block Volumes requires stopping or restarting all workloads that are attaching the volume for the resize to take effect.
Volumes cannot be downsized again once they are expanded.
Cloud UI
CLI
Deployment method: CoreWeave Cloud UI
From the Storage Volumes page in the Cloud UI, click the pencil associated with the listed storage volume you'd like to resize. This will open the Persistent Volume Claim modal.
​
The storage volume list, featuring the pencil icon to the right
​
From this modal, make the desired changes, then click Save to apply the changes.
​
The volume edit modal
Deployment method: Kubernetes CLI
Expanding storage volumes via kubectl is as simple as a single-line command:
kubectl patch pvc <myvolume> -p \
'{"spec":{"resources":{"requests":{"storage": "500Gi"}}}}'

All physical nodes are equipped with SSD or NVMe ephemeral (local) storage. Ephemeral storage available ranges between 512GB to 2TB, depending upon node type.
No volume claims are needed to allocate ephemeral storage - simply write anywhere in the container file system.
If a larger amount (above 20GB) of ephemeral storage is used, it is recommended to include ephemeral storage in the workloads resource request:
spec:
containers:
- name: example
resources:
limits:
cpu: 3
memory: 16Gi
nvidia.com/gpu: 1
ephemeral-storage: 20Gi
Important
For the vast majority of use cases, workloads should run in the same region as the storage block they are accessing. Use the region label affinity to limit scheduling workloads to a single region.
There are certain exceptions to this rule of thumb, which are mainly relevant for shared volumes, such as:
  • Batch workloads where IOPS are not a concern but accessing compute capacity from multiple regions might give scaling benefits
  • When data is strictly read during startup of a process, such as when reading a ML model from storage into system and GPU memory for inference
In general, block volumes should always be used in the same region in which they are allocated.
Copy link
On this page
Storage Volume Features
Volume Types
Block Storage Volumes
Shared File System Volumes
All-NVMe
HDD
Billing
Deploying Storage Volumes
Using Storage
Resizing Volumes
Ephemeral Storage