Verda Object Storage is now available in beta to all Verda customers. It is S3-compatible storage for the data behind your AI work, whether you're training, fine-tuning or serving models. Built and operated by Verda, it's managed in the console alongside your instances and clusters and works with the tools you already use. You pay only for the data you store. Uploads, downloads and API requests are free.
Keep your data where your AI work happens
Training and serving models both run on unstructured data. Training turns datasets of text, images, video and audio into checkpoints and model weights. Serving those models creates even more, from generated files and logs to the feedback that shapes the next round of training. All of it belongs in object storage, in one place every job can read and write.
That data moves constantly. Training reads the same datasets many times, checkpoints are reloaded whenever a job restarts, and model weights are loaded each time a new instance starts serving.
The usual setup keeps storage with one provider and compute with another, so every one of those moves crosses between the two. You need accounts and credentials in both, tools to copy data back and forth, and time for transfers before a job can start.
Verda Object Storage keeps your data in the same cloud as the GPUs and CPUs that use it, managed in the same console as the rest of your work. Within a region, traffic between your instances and your buckets stays on Verda's network. And because egress is free, your data is free to move. We think storage for AI should sit where the work runs, and moving your own data shouldn't cost you anything.
Your data, from training to serving
- Feeding training runs: share datasets across your project, and stage the parts each job needs onto a shared filesystem or NVMe volume.
- Checkpointing long runs: save checkpoints as training progresses, so an interrupted job picks up from the last one instead of starting over.
- Serving models: keep every model version in one library, and load the one you need onto your inference instances when they start.
- Collecting outputs and feedback: store the generated files, evaluation results and logs from training and serving, ready to share with a temporary link or feed into the next round of training.
- Backing up instance data: keep copies of important data off your instances, so it's safe even if an instance isn't.
What you get
- Compatibility with your S3 tools: the AWS CLI, boto3, rclone, s5cmd and other S3 SDKs connect with a few settings, so your scripts for uploading, downloading and syncing data keep working as they are.
- All-NVMe storage: your data is stored on NVMe drives, built for the constant reads and writes that training and serving make.
- Reliable transfers for large files: the Verda CLI splits big uploads and downloads into parallel parts. If the connection drops, run the same command again and it picks up where it left off. It also syncs folders and lets you browse buckets from your terminal.
- One console for storage and compute: create buckets, manage access keys, and see each bucket's size and approximate object count in the same console as your instances and clusters.
- Private, protected storage: buckets are never exposed anonymously, and access keys are scoped to your project. Erasure coding keeps your data intact when hardware fails.
Get started in three steps
- Create a bucket. In the Verda console, open your project, go to Storage → Object storage, and choose Create bucket.
- Create an access key. Go to Project management → Credentials, and create a key in the Object Storage Access Keys section. The secret key is shown only once, so store it somewhere safe.
- Connect your tools and upload your first object.
With the Verda CLI, connecting and uploading takes two commands:
verda object-storage configure \ --access-key <ACCESS_KEY> \ --secret-key <SECRET_KEY> verda object-storage cp ./model.safetensors s3://my-bucket/models/model.safetensors
The quickstart has the same steps for the AWS CLI and boto3.
Moving data from another provider? With rclone, you can copy it from any S3-compatible storage straight into your Verda buckets.
Working with your Verda compute
A common pattern is to keep datasets and checkpoints in Object Storage, and copy what a job needs onto a shared filesystem or NVMe volume before it starts. When the job finishes, sync the results and checkpoints back.
# before the job: copy the dataset onto the shared filesystem verda object-storage sync s3://my-bucket/datasets/train/ /mnt/shared/datasets/train/ # after the job: send checkpoints back to the bucket verda object-storage sync /mnt/shared/checkpoints/ s3://my-bucket/checkpoints/
Pricing and availability
During beta, Object Storage is available in FIN-03, with default quotas of 1 TiB of storage, 100,000 objects and 100 buckets. You can request more anytime from Account settings > Quotas.
You pay $0.07 per GiB stored per month, billed from your prepaid balance like your other Verda resources. There are no fees for egress, ingress or API requests, and no subscription or minimum commitment.
Get started today
Object Storage is available now in the Verda console. Read the documentation to dive in. Planning a larger workload? Get in touch and we'll help you set it up. We'd love your feedback through the chat in the console.
