Before you start, ensure that you have API Key with
Disks -> Read and write permissionOverview
Network-attached disks provide persistent storage that can be shared across multiple GPU instances. Disks persist independently from instances, making them ideal for storing datasets, model checkpoints, and other data that needs to survive instance termination.Finding Available Disk Options
Before creating a disk, use the disk availability endpoint to find available storage options across different providers and datacenters.Query Disk Availability
Understanding the Response
The response returns available disk configurations:Key Fields
cloudId: Identifies the storage configuration (if applicable)provider: The provider offering the storage (e.g.,hyperstack,runpod)dataCenter: Location where the disk will be createdspec.minCount: Minimum disk size in GBspec.maxCount: Maximum disk size in GBspec.pricePerUnit: Cost per GB per hourisMultinode: Whether the disk can be attached to multiple instances
Creating a Disk
Once you’ve identified a suitable disk configuration from the availability API, create a disk using the information from the availability response.Request Body Structure
Parameters
| Parameter | Required | Description |
|---|---|---|
disk.size | Yes | Disk size in GB (must be between minCount and maxCount from availability) |
disk.name | No | Human-friendly name for the disk (auto-generated if not provided) |
disk.cloudId | Yes* | Cloud ID from the availability response (*if provided in availability response) |
disk.dataCenterId | Yes* | Data center ID from availability (*if provided in availability response) |
provider.type | Yes | Provider type from availability response (e.g., hyperstack, runpod) |
Example: Creating a 500GB Disk
Response
On successful creation, you’ll receive a201 Created response with the disk details:
Cost Calculation
The hourly cost is calculated as:Listing Your Disks
Retrieve all disks associated with your account:Query Parameters
| Parameter | Default | Description |
|---|---|---|
limit | 50 | Number of results per page (max 200) |
offset | 0 | Number of results to skip for pagination |
Response
Getting a Single Disk
Retrieve detailed information about a specific disk:Response
pods: Array of pod IDs currently using this diskclusters: Array of cluster IDs currently using this diskinfo: Additional metadata about disk location and capabilities
Updating a Disk
Currently, you can update the disk name:Response
Deleting a Disk
Terminate a disk when you no longer need it. This will permanently delete the disk and all its data.Response
Detachment Timing: The disk detachment process can take longer than instance termination. After terminating an instance, you may need to wait a few moments before the disk becomes available for deletion or reuse.
Disk Status Values
Disks go through different statuses during their lifecycle:| Status | Description |
|---|---|
PROVISIONING | Disk is being created |
PENDING | Disk status is changing |
ACTIVE | Disk is ready and can be attached to instances or deleted |
STOPPED | Disk is stopped |
ERROR | An error occurred during disk operations |
DELETING | Disk is being deleted |
TERMINATED | Disk has been deleted |
UNKNOWN | Disk status is unknown (cannot access the current status) |
After terminating an instance, the disk detachment process may take a few moments to complete. You may need to wait briefly before the disk becomes available for deletion or reattachment.
Common Use Cases
Shared Training Data
Create large disks with your training datasets that can be reused across multiple training runs. This is ideal for storing preprocessed data, large image datasets, or any training data that needs to be accessed by multiple GPU instances. By keeping your data on a persistent disk, you avoid having to re-upload or regenerate datasets for each new training session.Model Checkpoints and Artifacts
Use disks to persist model checkpoints, trained weights, and training artifacts. This is especially valuable when running spot instances or interruptible workloads, as your progress remains safe even if the instance is terminated. You can resume training from the last checkpoint by simply attaching the disk to a new instance.Multi-Node Distributed Training
For distributed training across multiple GPUs or nodes, use multinode-compatible disks that can be accessed simultaneously by multiple instances. This enables shared access to training data and synchronized checkpointing across your distributed training cluster. Check theisMultinode field in the disk availability response to verify support.
Best Practices
Location Planning
- Create disks in the same datacenter where you plan to run GPU instances
- Use the availability endpoint with
disksfilter to find compatible GPUs
Size Planning
- Start with the size needed - you cannot resize disks after creation
- Consider future growth when selecting disk size
- Remember that larger disks cost more per hour
Data Management
- Regularly backup important data from disks
- Use descriptive names to identify disk contents
Related Documentation
- Check GPU Availability - Filter GPUs by disk location
- Provision GPU - Attach disks when creating instances
- Managing Instances - Manage instances with attached disks