Serverless storage
Explore storage options for your Serverless endpoints, including container volumes, network volumes, and S3-compatible storage.
This guide explains the different types of storage available in Runpod Serverless, their characteristics, and when to use each option.
Storage types
Container volume
A worker’s container volume holds temporary storage that exists only while a worker is running, and is completely lost when the worker is stopped or scaled down. It’s created automatically when a Serverless worker launches and remains tightly coupled with the worker’s lifecycle.
Container volumes provide fast read and write speeds since they are locally attached to workers. The cost of storage is included in the worker’s running cost, making it an economical choice for temporary data.
Any data saved by a worker’s handler function will be stored in the container volume by default. To persist data beyond the current worker session, use a network volume or S3-compatible storage.
Network volume
Network volumes provide persistent storage that can be attached to different workers and even shared between multiple workers. Network volumes are ideal for sharing datasets between workers, storing large models that need to be accessed by multiple workers, and preserving data that needs to outlive any individual worker.
To learn how to create and use network volumes, see Network volumes.
S3-compatible storage integration
Runpod’s S3 integration works with any S3-compatible storage provider, not just AWS S3. You can use MinIO, Backblaze B2, DigitalOcean Spaces, and other compatible providers.
Runpod’s S3-compatible storage integration allows you to connect your Serverless endpoints to external object storage services, giving you the flexibility to use your own storage provider with standardized access protocols.
You can supply your own credentials for any S3-compatible storage service, which is particularly useful for handling large files that exceed API payload limits. This storage option exists entirely outside the Runpod infrastructure, giving you complete control over data lifecycle and retention policies. Billing depends on your chosen provider’s pricing model rather than Runpod’s storage rates.
To configure requests to send data to S3-compatible storage, see S3-compatible storage integration.
Storage comparison table
| Feature | Container Volume | Network Volume | S3-Compatible Storage |
|---|---|---|---|
| Persistence | Temporary (erased when worker stops) | Permanent (independent of workers) | Permanent (external to Runpod) |
| Sharing | Not shareable | Can be attached to multiple workers | Accessible via S3 credentials |
| Speed | Fastest (local) | Fast (networked NVME) | Varies by provider |
| Cost | Included in worker cost | $0.05-0.07/GB/month | Varies by provider |
| Size limits | Varies by worker config | Up to 4TB self-service | Varies by provider |
| Best for | Temporary processing | Multi-worker sharing | Very large files, external access |
Serverless storage behavior
Data isolation and sharing
Each worker has its own local directory and maintains its own data. This means that different workers running on your endpoint cannot share data directly between each other (unless a network volume is attached).
Caching and cold starts
Serverless workers cache and load their Docker images locally on the container volume, even if a network volume is attached. While this local caching speeds up initial worker startup, loading large models into GPU memory can still significantly impact cold start times.
For guidance on optimizing storage to reduce cold start times, see Endpoint configuration.
Location constraints
If you use network volumes with your Serverless endpoint, your deployments will be constrained to the data center where the volume is located. This constraint may impact GPU availability and failover options, as your workloads must run in proximity to your storage. For global deployments, consider how storage location might affect your overall system architecture.