# Quake AI platform

Source: https://docs.quake.ai/docs/platform
Markdown: https://docs.quake.ai/docs/platform.md
> Quake AI is a US-based public cloud built on OpenStack, offering compute, networking, storage, and Kubernetes through standard OpenStack APIs.

---

# Quake AI platform

Quake AI is an independent, US-based public cloud built on OpenStack. It offers IaaS primitives (compute, networking, block storage, object storage, Kubernetes, and orchestration) through standard OpenStack APIs, with no egress fees and fixed monthly plans plus per-resource add-ons.

Use the [Quickstart](/docs/quickstart) to get resources running, or [Migration](/resources/migration) if you are deciding whether Quake AI fits your workload and how to move from another provider.



If you signed up under the Rumble Cloud name, you are on the same platform. Your account, logins, and services are unchanged. For background on the realignment, see the [Rum Group announcement of the Quake AI realignment](https://www.rum.group/blog/rumble-announces-realignment-into-two-core-business-units-and-renames-newly-acquired-cloud-and-ai-infrastructure-business-quake-ai/).



## What runs underneath

Quake AI runs OpenStack. Each Quake AI service maps directly to an OpenStack project, and the public APIs are the upstream OpenStack APIs:

| Quake AI service        | OpenStack project | Purpose                                              |
| --------------------- | ----------------- | ---------------------------------------------------- |
| Compute               | Nova              | Virtual machines, key pairs, server groups           |
| Network               | Neutron           | Private networks, routers, security groups, floating IPs |
| Block Storage         | Cinder            | Persistent volumes, snapshots                        |
| Object Storage        | Swift             | S3-compatible object store                           |
| Images                | Glance            | VM image catalog                                     |
| Kubernetes            | Magnum            | Managed cluster lifecycle                            |
| Automation            | Heat              | Cloud orchestration via Heat templates               |
| Identity              | Keystone          | Projects, users, application credentials             |

Because these are upstream APIs, anything that targets OpenStack works against Quake AI with an endpoint and credential change: the `openstack` CLI, the OpenStack Terraform provider, Pulumi providers, OpenTofu modules, Ansible collections, and third-party UIs. The control plane is OpenStack itself, so the operational vocabulary travels with it.

For a deeper look at the service map and how OpenStack flows through the stack, see [How Quake AI uses OpenStack](/resources/migration/openstack).

## Services

Each service has its own section under `/docs/{service}` with concepts, how-to guides, and reference. The shape is consistent across services so you can move between them without learning a new layout.

<PlatformServiceLinks />

## Frequently asked questions

<PlatformFaqLinks />

## Storage

Quake AI has two storage offerings:

- **Block storage (volumes):** persistent NVMe-backed volumes that attach to compute instances as filesystems. Use for databases, application state, and boot volumes.
- **Object storage (S3-compatible):** scalable bucket-based storage accessed over HTTP. Use for files, backups, static assets, and archives at any scale.

[OpenStack Cinder](https://docs.openstack.org/cinder/latest/) backs block storage and [OpenStack Swift](https://docs.openstack.org/swift/latest/) backs object storage. For details on how Quake AI implements OpenStack, see [How Quake AI uses OpenStack](/resources/migration/openstack).

<Figure
  size="lg"
  caption="Two storage offerings at a glance: block volumes attach to instances and snapshot for recovery, and object storage exposes S3-compatible buckets."
>

```d2
direction: down

block: Block Storage {
  instance: Instance
  volume: NVMe Volume {shape: cylinder}
  snapshot: Snapshot
  backup: Backup

  instance <-> volume: attach
  volume -> snapshot: point-in-time
  volume -> backup: long-term
}

object: Object Storage {
  api: S3-compatible API
  bucket: Bucket {shape: cylinder}

  api <-> bucket
}
```

</Figure>

### Block storage (volumes)

Block volumes are persistent NVMe-backed disks that you create, attach to instances, and format with any filesystem. A volume's lifecycle is independent of the instance; detach it, reattach it to a different VM, or snapshot it for point-in-time recovery. Volume snapshots are fast (copy-on-write) and suitable for rapid rollback. Volume clones create a full independent replica.

### Object storage (S3-compatible)

Object storage organizes data into **buckets** (containers) and **objects** (files). Access is via an S3-compatible API, so existing tools, SDKs, and libraries work without modification. Bucket policies and access control lists control who can read or write objects. Server-side encryption protects data at rest. Versioning lets you retain previous versions of objects for compliance or recovery.

**When to use which:** Use block storage when your application needs a mounted filesystem: databases, application servers, and anything that reads or writes files through POSIX calls. Use object storage for files accessed over HTTP: backups, media assets, static site content, log archives, and data pipeline outputs.

### Get started with storage

- For persistent disk on a VM, start with [Create a block storage volume](/docs/block/how-to/create-volume).
- For file and backup storage, start with [Create an object storage bucket](/docs/object/how-to/create-container).

See [Block storage](/docs/block) and [Object storage](/docs/object) for concepts, how-to guides, migration paths, and reference links.

## Why Quake AI

Quake AI gives you IaaS you can script, inspect, and move.

### No egress fees

Quake AI includes unlimited outbound data transfer with every plan. Quake AI does not meter per-GB egress on data leaving your instances or object storage. See the [Quake AI pricing page](https://www.quake.ai/pricing/) for current terms.

Outbound transfer is separate from CDN traffic. Quake AI does not bundle a global edge network; if you terminate TLS and serve bytes from a VM or object storage, those bytes still avoid an egress line item on Quake AI while counting toward your bandwidth bill on most other clouds.

For reference points elsewhere in the market, several major providers meter outbound data transfer:

- **AWS** charges per-GB for outbound data transfer after a small free allowance, with rates that vary by region. See the [AWS pricing page](https://aws.amazon.com/pricing/) for your region.
- **DigitalOcean** includes a transfer allowance per Droplet, then charges per-GB for overage. See the [DigitalOcean pricing page](https://www.digitalocean.com/pricing).
- **Hetzner** includes a monthly transfer allowance that differs between EU and US regions on many server plans. See the [Hetzner pricing page](https://www.hetzner.com/cloud).

At high outbound volumes, the difference between a metered-egress model and Quake AI's included-egress model dominates the bill before any compute or storage line items.

Object storage follows the same principle. The bill reflects stored data; download volume does not change it. You still design caching and CDN strategy yourself when you need global edge performance; Quake AI keeps egress surcharges out of the baseline IaaS bill.

### Fixed monthly pricing

Quake AI plans use fixed monthly pricing. The plan price covers the following rather than splitting them into separate line items:

- VPCs, subnets, and routers
- Security groups
- Data transfer (inbound and outbound)
- API requests

Plan tiers differ in vCPU, RAM, storage quotas, and which add-ons you provision. Your invoice reflects the plan tier and the add-ons attached to it. For current plan rates and the custom-package calculator, see the canonical [Quake AI pricing page](https://www.quake.ai/pricing/).

The model differs from a metered hyperscaler in shape:

| Resource | AWS billing model | Quake AI billing model |
| --- | --- | --- |
| VM instance | Per-second (On-Demand) or reserved | Fixed monthly per plan tier |
| Floating IP | Hourly when unattached | Add-on; dedicated-vCPU plans include one |
| Object storage | Per-GB metered with storage-class tiering | Per-TB add-on; dedicated-vCPU plans include 1 TB |
| Outbound transfer | Per-GB metered after allowances | Included |
| Security group | No separate charge; requires a VPC and related networking | Included |

Your bill is the same each month until you change plan tier or add billable add-ons.

### AMD EPYC across plans

Quake AI compute runs on AMD EPYC at every plan tier, including the entry-level Developer plan. A homogeneous fleet keeps the hardware variable out of benchmarking; SIMD features, cache behavior, and CPU-specific tuning behave the same across plans.

### Standard OpenStack APIs

The Quake AI public APIs are upstream OpenStack APIs:

- Object storage is S3-compatible. Your `boto3` code, `rclone` configs, and `aws-cli` workflows work with an endpoint and credential change.
- Kubernetes clusters from Magnum expose standard Kubernetes APIs.
- OpenTofu and Terraform use the `openstack` provider, so the same resource types apply on any OpenStack cloud.
- Orchestration through Heat uses standard templates and parameters.
- SSH access, standard Linux images, and `cloud-init` support match the baseline of any serious IaaS provider.

Your data and automation use standard APIs, so they stay portable. IaC configurations work across OpenStack clouds, S3-compatible storage systems, and Kubernetes clusters. Moving a workload means changing endpoints and credentials.

Client libraries, SDKs, and the OpenStack CLI you use on Quake AI are the same ones operators run against private clouds and other public OpenStack deployments. Documentation you read upstream for Neutron, Nova, or Swift often applies directly, with Quake AI-specific endpoints and limits noted in this site's service guides.

An engineer who has run OpenStack elsewhere recognizes Quake AI's network, volume, and instance workflows. Onboarding covers Quake AI's portal layout and quotas.



For how Quake AI maps to OpenStack projects day to day, read [How Quake AI uses OpenStack](/resources/migration/openstack). For AWS concept names side by side with Quake AI, read [Coming from AWS](/resources/migration/coming-from-aws).



### First-principles infrastructure

Quake AI's catalog is compute, networking, block storage, object storage, Kubernetes, and orchestration.

If you need a VM, a database you operate yourself, object storage, and a deployment pipeline, Quake AI gives you those primitives directly. You choose your software, images, and automation; the platform supplies the underlying IaaS.

Higher-level application services run on top of those primitives. Databases, queues, edge caching, observability, secrets management, and backup systems are software choices you deploy, automate, or connect as external services.

Teams that want a small, inspectable surface area (security review, compliance questionnaires, or teaching junior engineers what runs in production) often prefer that restraint over an ever-growing service menu.

You bring your own observability stack, secrets store, and backup tooling, or you adopt patterns from the [automation templates](/resources/iac-templates). Quake AI supplies the networks, volumes, and instances those tools attach to.

Quake AI fits when you want a narrow contract with the provider, a broad choice of software you run yourself, and a bill that is the plan price plus the add-ons you provisioned.

### AI-native development

If you already work with Cursor, Claude Code, Claude Desktop, VS Code Copilot agent mode, or another AI coding assistant, Quake AI's developer platform meets your tool where it lives. The anchor is a hosted MCP server at `https://docs.quake.ai/api/mcp` that gives the assistant callable tools for searching the docs, fetching IaC templates, and looking up service endpoints. Setup is a single JSON block in the tool's MCP config, and you do not need a Quake AI account to install it.

Around the MCP server, a few plain-URL surfaces serve the same content for tools that do not speak MCP yet: documentation pages are available as plain markdown at `/docs/{slug}.md`, `llms.txt` and `llms-full.txt` package the corpus as a single context payload, and `knowledge-graph.json` exposes services, concepts, templates, and competitor analogs as typed entities. The industry is still settling on which of these conventions stick, so we treat MCP as the durable anchor and keep the rest flexible.

To wire up your AI tool, see [How to connect AI tools to Quake AI docs](/resources/ai-assisted-development/ai-assisted-development).

### Validated against the platform

The documentation, infrastructure templates, and launch manifests on this platform pass a set of checks before they ship. We confirm pages against the running platform and stamp each one with the date of its last check, every infrastructure template passes `tofu validate` in continuous integration, and the machine-readable surfaces (`/docs/{slug}.md`, `llms.txt`, and `knowledge-graph.json`) regenerate from the same source on every build. For how those checks work and what they do and do not guarantee, see [How the platform validates its content](/docs/platform/validation).

## Pricing

Quake AI pricing combines fixed-monthly plans with a small list of per-resource add-ons. The model is legible:

- **Compute** pricing follows the plan tier. Developer, OpenClaw Starter, and Basic charge a fixed monthly rate; Custom builds from the [pricing calculator](https://www.quake.ai/pricing/). Stopped instances continue to bill for attached resources until you release them.
- **Block storage** runs on NVMe. The plan covers block storage up to the tier's quota. The Custom calculator prices capacity beyond the plan quota.
- **Object storage** bills as a per-TB add-on. Quake AI does not meter outbound transfer per-GB.
- **Network** primitives (private networks, routers, security groups) come with the plan. Public IPs are an add-on; dedicated-vCPU plans include one.
- **Kubernetes** clusters bill for the underlying compute and network resources; the plan covers the control plane.

For the authoritative price list, current rates, and the custom-package calculator, see the canonical [Quake AI pricing page](https://www.quake.ai/pricing/). The Developer plan is the entry tier intended for personal projects, prototypes, and learning.

Where the fixed-plan model lands against a metered hyperscaler depends on the workload shape. Steady-state workloads with predictable outbound transfer track the plan price closely. Workloads that push large volumes of outbound data benefit most, because Quake AI does not add a per-GB egress line item that scales with traffic. To compare scenarios against another provider, use the canonical pricing pages on both sides; recompute with current rates before bringing numbers to a procurement or budgeting decision.

### Capacity planning with fixed pricing

Fixed monthly pricing means you pay for provisioned capacity. A VM costs the same whether it is idle or at 100% utilization, so the model rewards steady-state workloads and deliberate capacity planning.

For workloads with short burst windows, compare the full architecture rather than compute alone. AWS **Savings Plans** and **Reserved Instances** lower compute rows when you commit for one or three years. Compute savings on AWS still leave data transfer and storage growth in the bill until the architecture changes. Quake AI keeps its infrastructure primitives in a fixed-capacity model.

## Regions

Quake AI is a single-cloud, multi-region platform. Each region is an independent failure domain with its own Console URL, API endpoints, and resource pool. No automatic cross-region replication exists; geographic redundancy is something you build into your architecture using object storage replication, IaC, and your own data movement.

### Current regions

| Region    | Location           | Console URL                            | Status    |
| --------- | ------------------ | -------------------------------------- | --------- |
| us-east-1 | US East            | https://us-east-1.console.rumble.cloud | Available |
| us-east-2 | US East            | https://us-east-2.console.rumble.cloud | Available |
| us-west-1 | US West            | https://us-west-1.console.rumble.cloud | Available |

All three regions are in the United States today. For cross-continent active-active layouts, design the application layer around DNS or routing, object replication, and the external services your architecture already uses.

### Services per region

All three regions run the same IaaS services: Compute, Network, Block Storage, Object Storage, Kubernetes, and Automation. If you need written confirmation of a specific service in a specific region for compliance, [contact support](/support).

### Choosing a region

If you have no preference, pick the region closest to your users. Object storage URLs include the region (`object.<region>.rumble.cloud`); moving between regions requires recreating resources.

### Cross-region patterns

- **Backup**: replicate object storage from one region to another using your tool of choice ([rclone, AWS CLI, MinIO Client](/docs/object/migration/tools-comparison)).
- **Disaster recovery**: run IaC-managed environments in two regions and promote the standby with DNS or routing changes.
- **Data egress between regions**: included with Quake AI's no-egress-fee policy.

### Availability zones

Quake AI does not expose AWS-style **availability zone** IDs in the Console. Placement across failure domains uses **[server groups](/docs/compute/concepts/server-groups)** with affinity or anti-affinity policies so Nova spreads instances across hypervisors when capacity allows.

When a migration guide says "launch in two AZs," translate that to multiple instances on a private network, anti-affinity server groups, and a self-managed reverse proxy or external edge for front-end redundancy. For multi-instance patterns, see [High availability](/docs/compute/concepts/high-availability).

### Provider mapping

| Provider concept | On Quake AI |
| --- | --- |
| Region | [Region](#regions) (independent endpoint and pool) |
| Availability zone | Anti-affinity [server group](/docs/compute/concepts/server-groups) + architecture (no AZ label) |
| Cross-region replication | Your tooling (object replication, IaC standby); not automatic |
| Local zone / edge | Not offered; use closest US region |

Every region exposes the full OpenStack API surface for the services listed above, plus the platform API (`papi`). The exact base URLs for your project are in the **API > API Endpoints** view of the cloud console for that region. See [service endpoints](/docs/tools/service-endpoints) for the full list and how to construct them programmatically.

## SLA and operational shape

Quake AI is an IaaS platform: Quake AI operates the hardware, hypervisor, control plane, and the storage and network fabrics. Above that line (guest operating systems, application data, configuration) is your responsibility. The split is the same one you use from any OpenStack-based or hyperscaler-based cloud.

- **Regions** are independent failure domains. No automatic cross-region replication exists; design it into your architecture using object storage replication, IaC, and your own data movement.
- The [SLA](/docs/account/sla) documents availability targets for compute, block storage, and object storage. The SLA defines what gets credited; your application's availability is a function of your architecture across instances, zones, and regions.
- Quake AI announces maintenance windows in the portal and the [changelog](/docs/changelog).
- Quake AI publishes status for live operational events on the [status page](https://status.rumble.cloud).

## Self-managed services and deployment patterns

Quake AI is a focused IaaS platform. The product surface stays close to compute, storage, networking, Kubernetes, and orchestration. Application-level services sit above that layer, which gives you direct control over the software, topology, and lifecycle.

| Requirement | Quake AI pattern | Implementation path |
| --- | --- | --- |
| Databases | Run the database stack you choose | PostgreSQL, MySQL, Redis, or another data store on VMs or Kubernetes, managed through your IaC and backup tooling |
| Traffic distribution | Run a reverse proxy or connect an external edge service | HAProxy, Nginx, Caddy, Traefik, Envoy, a CDN, or a WAF in front of application instances |
| Multi-region applications | Treat each region as an independent failure domain | Three US regions, object replication, IaC-managed standby environments, DNS, and routing controls |
| Function-style workloads | Run event handlers and jobs on infrastructure you control | Containers on VMs, Kubernetes jobs, queue workers, or schedulers |
| Edge caching | Pair Quake AI origin services with your preferred edge layer | Cloudflare, Fastly, another CDN provider, or self-managed Nginx caching |
| Operational knowledge | Use standard OpenStack and Linux operating models | OpenStack upstream documentation, Quake AI service guides, and Quake AI support |

The table sketches the path from a common requirement to a Quake AI pattern and an implementation route. When a workload depends on automatic database failover, global edge routing, or event-driven execution, make those layers explicit in the design. You can run them on Quake AI primitives, connect an external service, or keep that layer in a system your team already operates.



For compute, storage, networking, Kubernetes, and orchestration, Quake AI keeps the provider contract narrow and portable. For application services above that layer, choose the operating model you want: self-managed software, external managed services, or a hybrid pattern.





The sample code, IaC templates, CLI snippets, and AI-generated outputs surfaced through this developer platform are reference material, not production deployments. You are responsible for testing, securing, and adapting any sample to your environment before running it against production accounts or production data. Deploying a sample against your Quake AI account incurs charges for any chargeable resources it creates.



## Where to go next

<UseCaseGrid>
<UseCaseCard
  title="Ways to build"
  description="The common ways to build on Quake AI, from the Console to IaC, containers, Kubernetes, and AI-assisted development, with the rationale for each and who it fits."
  href="/docs/platform/ways-to-build"
  difficulty="beginner"
  services={["Platform"]}
/>
<UseCaseCard
  title="Quickstart"
  description="Sign up, add an SSH key, and launch your first server. About 20 minutes from start to finish."
  href="/docs/quickstart"
  difficulty="beginner"
  services={["Compute"]}
/>
<UseCaseCard
  title="Migration"
  description="Evaluate Quake AI against AWS, Azure, GCP, DigitalOcean, or Hetzner, then move workloads. Per-provider concept translation paired with phased migration workflows."
  href="/resources/migration"
  difficulty="intermediate"
  services={["Compute", "Storage", "Network", "Kubernetes", "Automation"]}
/>
<UseCaseCard
  title="API conventions"
  description="Cross-service API behavior: error response format, retry and resilience, and the request correlation fields to capture for support."
  href="/reference/api-conventions"
  difficulty="intermediate"
  services={["Platform"]}
/>
<UseCaseCard
  title="Automation"
  description="OpenTofu and Heat templates for common Quake AI infrastructure patterns."
  href="/docs/automation"
  difficulty="intermediate"
  services={["Automation"]}
/>
</UseCaseGrid>