Quake AI Object Storage provides S3-compatible storage for unstructured data: files, backups, media, archives, data lakes, and static assets. It is backed by OpenStack Swift with a Ceph storage backend. The platform exposes both the native Swift API and an S3-compatible API. Data is replicated across multiple storage nodes automatically; you do not manage RAID arrays or backup jobs for durability.

Each dedicated vCPU subscription does not include a bundled object-storage allotment on the current named packs. Object storage is a per-TB add-on. See Resource tiers and the pricing reference.

They are the same thing. In OpenStack Swift terminology, the top-level namespace for objects is called a container. Quake AI uses bucket as the primary user-facing term, matching the S3 vocabulary your tools already expect. If you see "container" in API responses, CLI output, or Swift documentation, it refers to the same concept. Neither term means a Docker container.

Any S3-compatible client works once you point it at the Quake AI endpoint and supply an S3 credential pair. Confirmed working tools:

• AWS CLI: pass --endpoint-url https://object.<region>.rumble.cloud on every command; set the region to us-east-1 for SigV4 signing regardless of your Quake AI region.
• s3cmd: configure host_base and host_bucket in ~/.s3cfg; a pre-filled .cfg file is available when you create credentials in the console.
• rclone: configure a remote with type = s3, provider = Ceph, and your region endpoint.
• MinIO Client (mc): mc alias set rumble https://object.<region>.rumble.cloud ...
• boto3 (Python): pass endpoint_url to boto3.client("s3", ...).
• restic: use the S3 backend pointed at the Quake AI endpoint.

S3 credentials (access key + secret key) are separate from OpenStack application credentials. Generate them via API > S3 Credentials in the console or with openstack ec2 credentials create.

The S3-compatible endpoint hostname uses the object. prefix in each region:

Use the same hostname for the AWS CLI (--endpoint-url), boto3 (endpoint_url), rclone (endpoint), and any other S3 client. When signing requests with SigV4, set the region to us-east-1 regardless of which Quake AI region you target.

Common mistake from AWS migrators: trying s3.<region>.rumble.cloud. That hostname returns DNS NXDOMAIN. The platform's S3 gateway answers only on object.<region>.rumble.cloud.

Core S3 operations:

Design alternatives:

Use object storage when your application treats files as whole units (upload once, read many times). Use block storage when your application needs a filesystem with random read/write access, such as a database or OS disk.

Versioning keeps every version of every object in a bucket. When you overwrite or delete an object, the previous version is retained. You can list, retrieve, or restore any historical version via the S3 API.

Key behaviors to know before enabling:

• Each object version counts against your storage quota.
• Deleting an object in a versioned bucket adds a delete marker; the object still exists in previous versions.
• Once enabled, versioning can only be suspended, not removed.
• The Quake AI console shows only the current version; all versions are visible via S3 API calls.
• Versioning is configured via the S3-compatible API, there is no versioning toggle in the console.

Enable versioning with s3cmd setversioning s3://my-bucket enable or aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled --endpoint-url "https://object.us-east-1.rumble.cloud".

Quake AI offers two server-side encryption modes. Both use AES-256 and encrypt only object data, not object metadata.

• SSE-C (customer-provided keys): You supply a 256-bit Base64-encoded key with each upload and download request. Quake AI never stores your key; it applies encryption on write and removes the key from memory. HTTPS is mandatory. If you lose the key, the object is permanently unrecoverable. Use SSE-C when compliance requires you to maintain exclusive control of encryption keys.

• SSE-OMK (object management keys): Quake AI manages the encryption keys. Each object is encrypted with a unique key; the key itself is encrypted with a root key that Quake AI rotates on a schedule. No special headers are required on download. Use SSE-OMK for simplicity when key management is not a compliance requirement.

You can configure a bucket to apply SSE-OMK automatically to all new objects using aws s3api put-bucket-encryption.

CORS (Cross-Origin Resource Sharing) lets browser scripts on one origin access objects on your Quake AI bucket from another origin. Configure per-bucket CORS rules as a JSON policy (AWS CLI) or XML (s3cmd).

Apply a CORS policy:

# AWS CLI (JSON)
aws s3api put-bucket-cors --bucket your-bucket \
  --cors-configuration file://cors.json

# s3cmd (XML only)
s3cmd setcors /path/to/cors.xml s3://your-bucket

Quake AI-specific pitfall: CORS preflight requests are not authenticated. You must include the tenant ID in the URL provided to browsers for each resource:

https://object.<region>.rumble.cloud/<tenant_id>:bucket/<object>

For example: https://object.us-east-2.rumble.cloud/gT2jQ9uX8pA4vY7fH3kL6dN5mB1rC:bucket/image.jpg

Common mistakes: using a wildcard * for AllowedOrigins, forgetting to account for preflight OPTIONS requests, omitting custom headers from AllowedHeaders, and specifying the wrong protocol or port in origins.

Yes. The recommended tool is rclone, which is cross-platform (Windows, macOS, Linux), open source, and actively maintained.

Configure rclone with type = s3, provider = Ceph, and your region endpoint, then run rclone mount quakeai:my-bucket/ /mnt/s3bucket.

Important: Only allow one system to mount a bucket as writable at a time. Concurrent writes from multiple systems can cause data loss (last writer wins). Enable versioning as a safety net if multiple systems need write access.

Object storage does not expose FTP/SFTP natively. The supported path is to set up a gateway VM that mounts your bucket using s3fs and then runs an FTP/SFTP server on top of that mount.

The recommended approach uses an Ubuntu 24.04 VM with s3fs to mount the bucket at /opt/s3storage, then exposes the mount over SFTP (which works without extra configuration on Ubuntu), FTPS (via vsftpd with SSL), or FTP (via vsftpd, but only within a private VPC: FTP sends passwords in plaintext).

Quake AI strongly recommends SFTP or direct S3 for internet-facing transfers. FTP should only be used on private VPC networks. For Windows or other OS-based gateways, rclone mount works identically.

Apply a public-read policy using the S3-compatible API. The simplest policy grants s3:GetObject to Principal: "*" (all users):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicReadGetObject",
    "Principal": "*",
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": ["arn:aws:s3::$tenant:$bucket/*"]
  }]
}

Replace $tenant with your project name and $bucket with the bucket name. Apply with s3cmd setpolicy policy.json s3://my-bucket or aws s3api put-bucket-policy --bucket my-bucket --policy file://policy.json --endpoint-url "https://object.us-east-1.rumble.cloud". You can also toggle public access in the console under Storage > Object Storage > Edit Container.

Anonymous URLs on the Quake AI S3 gateway require a tenant prefix in the path. Without it the gateway returns 404 Not Found even when the bucket policy grants public read.

The URL pattern is:

https://object.<region>.rumble.cloud/<tenant_id>:<bucket>/<key>

For example, with a project ID of gT2jQ9uX8pA4vY7fH3kL6dN5mB1rC and a bucket named assets:

https://object.us-east-1.rumble.cloud/gT2jQ9uX8pA4vY7fH3kL6dN5mB1rC:assets/logo.png

Find your tenant ID with openstack token issue -f value -c project_id or in the Quake AI portal under the project's settings. The bucket-policy ARN format (arn:aws:s3::<tenant>:<bucket>) already encodes the tenant; the URL the browser fetches must match that scope at the path level. The same prefix applies to CORS preflight requests; see CORS setup for the cross-origin specifics.

Use a read-only policy that explicitly allows s3:GetObject and s3:ListBucket, and denies all write and delete actions for the specified user. The policy references the user as an ARN in the form arn:aws:iam::$tenant:user/$user.

Warning: The strict read-only policy (read-only-policy.mdx) locks out write access so strongly that the policy itself cannot be removed without admin assistance. If you need the ability to self-revert the policy later, use the user-reversible read-only policy instead, which additionally grants s3:DeleteBucketPolicy and s3:PutBucketPolicy to the named user.

Remove any lifecycle policies before applying either read-only variant.

Use an IP whitelist (source IP) policy with the aws:SourceIp condition. Two variants are available:

• Block all access except from a known IP: uses Effect: Deny with NotIpAddress condition on Principal: "*".
• Allow public read only from a known IP: uses Effect: Allow with IpAddress condition on s3:GetObject for Principal: "*".

Both use a CIDR block (e.g., 1.2.3.4/32 for a single IP). The Resource array covers both the bucket and its objects (arn:aws:s3:::YourBucket and arn:aws:s3:::YourBucket/*).

Use the restricted public read policy, which grants s3:GetObject to Principal: "*" on all objects in the bucket, but does not grant s3:ListBucket. This lets anyone who knows an object's URL download it, while preventing enumeration of bucket contents.

The policy structure is identical to the public-read policy but intentionally omits ListBucket:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicReadGetObject",
    "Principal": "*",
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": ["arn:aws:s3::$tenant:$bucket/*"]
  }]
}

For even finer-grained control (granting different permissions to different users), use the grant-access-control how-to, which shows a multi-statement policy granting read/write to one user and read-only to another.

The Console exposes only basic bucket operations (create, delete, public-access toggle, file browse, upload, download). CORS configuration, JSON bucket policies, versioning, and per-user access grants live on the S3-compatible API; configure them with aws s3api, s3cmd, or another S3 client.

Available in the Console:

• Create and delete buckets
• Toggle the bucket's Public Access flag at create time or via the row's Update Access action
• Browse, upload, and download objects inside a bucket
• Delete individual objects from a bucket

Requires the S3 API or CLI:

Quake AI Object Storage does not implement lifecycle rules (object transition and expiration) on any surface. Implement retention with rclone delete --min-age on a schedule. The full design-alternatives table sits in the "Which S3 features does Quake AI Object Storage support?" entry above.

Application-credential openrc files do not export the token or protocol-specific URLs that Swift and S3 API examples use. Export them in the same shell before you run curl:

export OS_TOKEN="$(openstack token issue -f value -c id)"
export OS_PROJECT_ID="$(openstack token issue -f value -c project_id)"
export OS_SWIFT_S3_URL="https://object.${OS_REGION_NAME}.rumble.cloud"
export OS_SWIFT_URL="${OS_SWIFT_S3_URL}/swift/v1/AUTH_${OS_PROJECT_ID}"

On macOS, avoid bare swift post in tutorials: the system Swift compiler shares that command name. Prefer the curl API paths in the how-to guides or run OpenStack CLI commands from a Linux shell.

The quick triage table from the access runbook:

The most important distinction: EC2 (S3) credentials and OpenStack application credentials are different. Application credentials authenticate the OpenStack API; they do not work as S3 access keys. You must create EC2 credentials for S3 access via openstack ec2 credentials create.

EC2 credentials are project-scoped: a key from one project cannot access buckets in another project.

SigV4 signing: always set the S3 region to us-east-1 regardless of which Quake AI region you use. Wrong region produces SignatureDoesNotMatch even when the key pair is valid.

Resolution steps:

1. openstack ec2 credentials list, confirm credentials exist with the correct project_id.
2. If none exist: openstack ec2 credentials create.
3. Set the region to us-east-1 in your S3 client config.
4. Set the endpoint from an environment variable; do not hardcode it.
5. Test: aws s3 ls --endpoint-url "${YOUR_ENDPOINT}".
6. If SignatureDoesNotMatch persists after verifying region and endpoint, regenerate credentials.

Escalate if regenerated credentials with correct project and verified SigV4 settings still return 401/403, or if multiple projects fail simultaneously (possible platform identity or gateway issue).

Objects larger than 5 GB require multipart upload. Common failure modes:

Resolution:

For AWS CLI, multipart kicks in automatically for objects larger than 8 MB. Confirm it is working with --debug. For boto3, set TransferConfig(multipart_threshold=8 * 1024 * 1024, multipart_chunksize=16 * 1024 * 1024) explicitly.

List and abort stale multipart uploads:

aws s3api list-multipart-uploads --bucket YOUR_BUCKET --endpoint-url "${YOUR_ENDPOINT}"
aws s3api abort-multipart-upload --bucket YOUR_BUCKET --key YOUR_KEY \
  --upload-id YOUR_UPLOAD_ID --endpoint-url "${YOUR_ENDPOINT}"

For large or resumable transfers, rclone is the recommended tool. It handles multipart and retries automatically. For objects well above 50 GB, split into smaller objects or use a dedicated bulk transfer tool.

Five tools cover the common migration and backup scenarios. Choose based on your primary requirement:

Neither rclone, the AWS CLI, nor s3cmd preserves custom x-amz-meta-* metadata during cross-provider copies. Use MinIO Client if metadata must survive the transfer.

AWS offers free data transfer out when migrating away, so there are no egress fees for this path.

The recommended tool is rclone, which copies directly between endpoints without local staging. Configure both AWS and Quake AI as rclone remotes, then:

1. Run an initial rclone copy aws:my-source-bucket quakeai:my-bucket (use copy, not sync, for the initial pass, safer, no deletions).
2. Schedule daily rclone sync delta passes until you are ready to cut over.
3. On cutover: run a final rclone sync, update your application's S3 endpoint, keep the AWS source for 30 days as a rollback target.

Features that do not transfer and need remediation before migrating: lifecycle policies, event notifications, S3-format JSON bucket policies, and S3 Replication rules. All objects land on a single storage tier on Quake AI (no storage class transitions needed).

If objects have custom x-amz-meta-* headers, use MinIO Client's mc mirror instead of rclone.

Use rclone with a GCS service account JSON key file. Configure the GCS remote with type = google cloud storage and the Quake AI remote with type = s3, provider = Ceph.

GCS-specific considerations:

• Egress cost: GCS charges per-GB egress and does not run a free migration program. Confirm current rates on the Google Cloud Storage pricing page.
• Storage classes: Objects in Nearline, Coldline, or Archive have minimum storage duration charges (30, 90, and 365 days). Deleting them before the minimum incurs an early deletion fee.
• IAM permissions: GCS IAM roles do not translate to Swift ACLs. Re-apply access controls on Quake AI after migration.
• Lifecycle rules: Not supported on Quake AI; implement retention with rclone delete --min-age.

Use rclone with an Azure SAS token or service principal. Configure the Azure remote with type = azureblob.

Azure-specific considerations:

• Egress cost: Azure charges per-GB egress and does not run a free migration program. Confirm current rates on the Azure bandwidth pricing page.
• Archive tier: objects in Azure Archive must be rehydrated before copying (up to 15 hours, per-GB fee).
• Access tiers: Hot, Cool, Cold, and Archive all land on a single tier on Quake AI.
• RBAC/ABAC: Azure Entra ID policies do not translate to Swift ACLs. Re-apply access controls using the Quake AI grant-access-control how-to.
• Lifecycle policies: not supported on Quake AI; implement with external tooling.

Note: In Azure terminology, "containers" hold "blobs." On Quake AI, "buckets" (also called containers) hold "objects." The rclone config calls the Azure side azure:my-source-container.

B2 supports both its native API and an S3-compatible API; rclone handles both with direct cloud-to-cloud transfer.

Use the B2-native rclone remote (type = b2) for the source. It has faster listing operations than B2's S3-compatible endpoint.

B2-specific considerations:

• Egress: B2 charges per-GB for direct egress. Via the Cloudflare Bandwidth Alliance, egress is free up to 3× your stored data per day, so a Cloudflare-fronted bucket migrates without egress charges. Confirm current rates on the Backblaze B2 pricing page.
• File caps: B2 allows up to 10 million files per bucket; plan parallel transfers and checkpoint progress near this limit.
• Lifecycle rules: do not transfer; implement retention with rclone delete --min-age.

Both Wasabi and Quake AI use S3-compatible APIs, so rclone copies directly without local staging. Configure a Wasabi remote with type = s3, provider = Wasabi and the region-specific endpoint.

Wasabi-specific considerations:

• Egress: Wasabi does not charge for egress, provided your egress stays below your total stored data volume. Migrate while data is still stored on Wasabi.
• 90-day minimum storage: Wasabi bills each object for at least 90 days. Deleting after migration may not immediately save money. Keep the Wasabi source for at least 90 days; if objects are already past the minimum, a 30-day holdover is sufficient.

Both Hetzner Object Storage and Quake AI use S3-compatible APIs backed by Ceph, making this one of the simplest migration paths. Configure an rclone remote with type = s3, provider = Other and the Hetzner region endpoint (fsn1, nbg1, or hel1).

Hetzner-specific considerations:

• No egress fees: outbound transfer is included in the Hetzner plan.
• Custom metadata: rclone and s3cmd do not preserve x-amz-meta-* headers during cross-provider copies. Use MinIO Client if metadata must be preserved.
• 100-bucket limit: Hetzner limits accounts to 100 buckets; Quake AI does not impose a hard bucket limit.

DigitalOcean Spaces and Quake AI both use S3-compatible APIs. Configure an rclone remote with type = s3, provider = DigitalOcean and the Spaces endpoint for your region (nyc3, sfo3, ams3, etc.).

DigitalOcean-specific considerations:

• Egress: DigitalOcean includes a per-subscription outbound transfer allowance for Spaces and charges per-GiB for overage. Confirm current allowances and rates on the DigitalOcean Spaces pricing page.
• CDN: the built-in Spaces CDN is not available on Quake AI. Front your Quake AI bucket with Cloudflare or CloudFront after migration.
• Billing: Spaces billing ends only when all Spaces are deleted. Delete Spaces after the 30-day holdover period to stop charges.
• Terminology: DO calls each bucket a "Space." The rclone workflow is identical to any S3-compatible source.

You do not need to migrate your primary storage to use Quake AI as an off-site backup destination. Quake AI works well as the "one off-site copy" in a 3-2-1 strategy (three copies, two media types, one off-site).

Two tools cover the main patterns:

• rclone: file-level backups with rclone copy on a cron schedule. Use copy (not sync) for backups so local deletions do not propagate to the backup bucket. Supports PostgreSQL, MySQL, and SQLite dump scripts.
• restic: encrypted, deduplicated backups with built-in AES-256 encryption and retention policies (restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune). Encrypt before upload; server-side encryption is an additional optional layer.

Object storage on Quake AI is a per-TB add-on, and each dedicated vCPU subscription includes 1 TB at no additional cost. Backups within the included allowance do not add to the bill. For current rates, see the canonical Quake AI pricing page.

Use rclone in active-passive replication mode: your application writes to the primary provider, and a cron job on a small Quake AI VM syncs changes to Quake AI on a schedule. Quake AI acts as a read-only replica and failover target.

rclone sync primary:my-bucket quakeai:my-bucket-replica \
  --transfers 16 --checkers 32 \
  --log-file /var/log/rclone-sync.log --log-level INFO

For hourly replication, add that command to cron. Use --bwlimit to cap bandwidth during business hours.

For failover: point your application at the Quake AI endpoint, then reverse the sync direction once the primary recovers. After both sides are in sync, revert the application endpoint.

For selective sync (only specific prefixes), use --include "/backups/**" --include "/media/**".

Note: rclone bisync (bidirectional) is marked experimental and can cause data loss on edge cases. Use append-only naming patterns or prefix partitioning for workloads that write to both sides independently.

Object storage runs in all three Quake AI regions and exposes one S3-compatible endpoint per region:

• object.us-east-1.rumble.cloud
• object.us-east-2.rumble.cloud
• object.us-west-1.rumble.cloud

Each endpoint serves an independent bucket namespace; a bucket created in one region is not visible from another. No automatic cross-region replication exists. To replicate objects across regions, use a tool from Migration tools comparison (rclone, AWS CLI, or MinIO Client) and run it on a schedule. See Regions for the platform-wide region table.

The contractual durability target, availability target, and credit schedule are published as part of Quake AI's commercial terms at rumble.cloud/legal. The Service Level Agreement page explains how to read those terms and how to file a credit claim. Storage-layer replication (the multi-node Ceph cluster behind the S3 API) protects against hardware-level loss within a region. For cross-region durability, replicate objects to a bucket in a second region with the tool of your choice.

For most access problems, start with the runbook:

• Object storage access troubleshooting: S3 403/401 errors, credential confusion (InvalidAccessKeyId, SignatureDoesNotMatch), and large file upload failures (EntityTooLarge).

Before opening a support ticket, gather this evidence (redact all secrets and access keys):

If the runbook does not resolve the issue, open a support ticket with the evidence above. Get help is the canonical decision tree for picking the right starting point based on the symptom, and Support ticket evidence collection is the full evidence checklist.