Skip to main content
This guide explains the different types of storage you can configure for your Serverless workers so they can access and store data when processing requests.

​
Storage types

​
Container volume

A worker’s container disk 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 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 disk 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 attach a network volume to your endpoint, see Network volumes for Serverless.

​
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

​
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 disk, 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.