How to migrate from Vultr object storage to Quake AI

Vultr Object Storage and Quake AI both expose an S3-compatible API. rclone copies data directly between the two endpoints with no local staging required.

Service mapping#

Prerequisites#

• A Quake AI account with S3 credentials
• A Vultr Object Storage access key and secret (created in the Customer Portal under Object Storage > Manage)
• rclone installed (v1.65+)

Before you start#

Read the migration planning guide for the S3/Swift compatibility matrix.

Vultr-specific considerations:

• Bandwidth allowance. Vultr Object Storage subscriptions include a fixed bandwidth allowance bundled with each tier; overage is per-GiB. For large migrations, estimate the transfer size against your allowance. Confirm current rates on the Vultr Object Storage page.
• Endpoint format. Vultr endpoints follow <region>.vultrobjects.com (for example, ewr1.vultrobjects.com, sjc1.vultrobjects.com). Pick the endpoint that matches the region your source bucket lives in.
• Bucket and credential scope. A Vultr Object Storage subscription has one access key per subscription that grants access to all buckets within it. Make sure the key you use for migration has read access to every prefix you plan to copy.
• CDN. If your Vultr bucket has a CDN attached (third-party), this is a source-side feature. Front your Quake AI bucket with a CDN (Cloudflare, CloudFront) if you need edge caching. See CloudFront CDN setup.
• Lifecycle and policy features. Confirm against the S3 feature compatibility matrix before you cut over. Swift's S3 gateway does not implement every S3 lifecycle and policy feature.
• Ceph backend. Vultr Object Storage is Ceph-backed (similar shape to DigitalOcean Spaces and Linode Object Storage). Standard S3 operations are compatible between the two.

Configure rclone remotes#

Add both remotes to ~/.config/rclone/rclone.conf:

[vultr]
type = s3
provider = Other
access_key_id = YOUR_VULTR_ACCESS_KEY
secret_access_key = YOUR_VULTR_SECRET_KEY
endpoint = ewr1.vultrobjects.com
acl = private

[quakeai]
type = s3
provider = Ceph
access_key_id = YOUR_RUMBLE_ACCESS_KEY
secret_access_key = YOUR_RUMBLE_SECRET_KEY
endpoint = object.us-east-2.rumble.cloud
acl = private

Replace the Vultr endpoint with the regional slug for your bucket. Replace the Quake AI endpoint with the region you provisioned credentials in.

Verify both remotes:

rclone lsd vultr:
rclone lsd quakeai:

Create the destination bucket#

rclone mkdir quakeai:my-bucket

Run the migration#

Initial copy#

rclone copy vultr:my-source-bucket quakeai:my-bucket \
  --transfers 16 \
  --checkers 32 \
  --s3-chunk-size 64M \
  --progress \
  --log-file migration.log \
  --log-level INFO

Delta syncs#

rclone sync vultr:my-source-bucket quakeai:my-bucket \
  --transfers 16 \
  --checkers 32 \
  --progress

Schedule daily until cutover.

Verify the migration#

rclone size vultr:my-source-bucket
rclone size quakeai:my-bucket

Check file integrity:

rclone check vultr:my-source-bucket quakeai:my-bucket \
  --one-way \
  --log-file check.log

See the validation checklist for the full procedure.

Cut over#

1. Run a final rclone sync.
2. Update your application's S3 endpoint configuration. See update application endpoint.
3. If you used a Vultr-side CDN, configure an external CDN (Cloudflare, CloudFront) pointing at your Quake AI bucket.
4. Keep the Vultr bucket for 30 days as a rollback target.
5. Delete all Vultr Object Storage subscriptions and access keys to stop Vultr billing.

See also#

• Plan your migration: compatibility matrix, validation checklist
• Migration tools comparison: rclone configuration and alternatives
• Update application endpoint: swap SDK config to Quake AI