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 to get resources running, or Migration if you are deciding whether Quake AI fits your workload and how to move from another provider.

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:

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.

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.

• Compute: Create and manage virtual machine instances on Quake AI: choose an image and flavor, connect to project networks, and snapshot, resize, or destroy.
• Network: Connect Quake AI workloads with isolated project networks, subnets, routers, floating IPs, and security group firewall rules.
• Block Storage (Volumes): Create persistent NVMe-backed block volumes on Quake AI, attach them to instances, and snapshot, extend, clone, or transfer them between projects.
• Object Storage (S3-Compatible): Store and retrieve unstructured data on Quake AI's S3-compatible object storage using standard S3 SDKs and tools, backed by OpenStack Swift.
• Kubernetes: Provision Kubernetes clusters on Quake AI from reusable templates: the platform creates master nodes, worker nodes, and networking with Magnum.
• Automation: Define Quake AI infrastructure as code with OpenTofu or Terraform for provisioning, and Ansible for configuration management and deployment.
• Access & Credentials: Access Quake AI programmatically with the REST APIs and command-line tools, and manage the credentials and tokens that authenticate your requests.

Frequently asked questions#

• Account: projects, organizations, resource tiers, subscriptions, billing cadence, invoices, payment methods, application credentials, and the portal and console.
• Compute: instances, flavors, images, key pairs, snapshots, networking, and migration.
• Network: networks, subnets, routers, floating IPs, security groups, TLS, and cloud migration.
• Block storage: creating and attaching volumes, snapshots, clones, resizing, ownership transfers, migration from other providers, and troubleshooting.
• Object storage: buckets, S3 compatibility, access control policies, versioning, encryption, CORS, FTP/SFTP, mounting, and migration from AWS S3, GCS, Azure, Backblaze, Wasabi, Hetzner, and DigitalOcean.
• Kubernetes: cluster provisioning via Magnum, cluster templates, lifecycle, high availability, migration from EKS/AKS/GKE/DOKS/Hetzner, and troubleshooting.
• Automation: OpenTofu, Terraform, Heat orchestration, Ansible configuration management, state management, templates, CI/CD integration, multi-environment patterns, and migration from CloudFormation, Hetzner, and Docker Compose.
• OpenStack on Quake AI: How Quake AI services map to OpenStack projects and APIs
• Support: Open a ticket, browse troubleshooting guides, and runbooks

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 backs block storage and OpenStack Swift backs object storage. For details on how Quake AI implements OpenStack, see How Quake AI uses OpenStack.

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.
• For file and backup storage, start with Create an object storage bucket.

See Block storage and Object storage 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 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 for your region.
• DigitalOcean includes a transfer allowance per Droplet, then charges per-GB for overage. See the DigitalOcean pricing page.
• Hetzner includes a monthly transfer allowance that differs between EU and US regions on many server plans. See the Hetzner pricing page.

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.

The model differs from a metered hyperscaler in shape:

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.

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. 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.

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.

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. 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. 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#

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.

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).
• 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 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.

Provider mapping#

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 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 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.
• Quake AI publishes status for live operational events on the status page.

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.

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.

Where to go next#