Ways to build on Quake AI

There are several common ways to build on Quake AI. They sit on a ladder, from working hands-on with primitives to running applications through higher-level abstractions. Each step up trades some direct control for reuse, automation, and convention.

The approaches share a foundation. Quake AI exposes standard OpenStack APIs, so every method below targets the same compute, network, storage, and Kubernetes primitives. You can start at any rung, mix rungs, and climb later without re-platforming or rewriting your application. This page maps the terrain and points you to the guide for each path.

Pick your starting point#

Find the row that sounds like you and follow the link to a concrete starting point.

The developer journey#

The path from a new account to a production workload runs through four stages. Each stage links the guides you need at that point. You can enter at any stage and climb as a real workload asks for it.

Get started#

Create a project, install the CLI, and stand up your first server.

• Platform overview
• Provision your first server
• Create a project
• Install the CLI
• Authenticate with API tokens

Build#

Provision the compute, networking, and storage a real workload needs.

• Compute
• Network
• Storage
• Deploy a containerized app
• Infrastructure templates

Operate#

Harden, monitor, back up, and load-balance what you shipped.

• Harden a production VM
• Run blue/green or canary deployments with a reverse proxy
• Deploy monitoring
• Schedule volume snapshots and restore data
• Security model

Scale#

Orchestrate with Kubernetes, migrate more workloads in, and plan capacity.

• Run Kubernetes
• Migrate from another cloud
• Capacity and tiers
• Operations runbooks

The build ladder#

Two threads cut across every rung rather than sitting on the ladder: configuration management (covered with infrastructure as code below) and automation, including CI/CD and AI-assisted development (covered in Automating any rung).

Console: click to build#

The Console is the web interface for creating instances, networks, volumes, and clusters by hand. It is the fastest path to a running resource and the clearest view of the object model, because you see each primitive and how it connects.

Use the Console for first steps, exploration, and one-off changes. Each service section documents its Console workflow under console, for example Create an instance. The Quickstart walks a first server end to end.

Command line, API, and SDKs#

The openstack CLI, the REST API, and language SDKs let you script work that the Console does by hand. This is repeatability without adopting a full infrastructure-as-code workflow, and it is the natural home for anyone who already lives in a terminal.

Because the public APIs are the upstream OpenStack APIs, tools you already run carry over with an endpoint and credential change. Object storage is S3-compatible, so boto3, rclone, and aws-cli workflows work against it. Set up the CLI and credentials from Tools, and construct per-region endpoints from Service endpoints.

Infrastructure as code#

Infrastructure as code describes your resources in version-controlled files that a tool reconciles against the platform. This is the first rung where infrastructure becomes a reviewable artifact: you diff a change, plan it, and apply it the same way across environments.

OpenTofu is the default on Quake AI, Terraform is fully supported with the same templates, and Heat is the legacy OpenStack-native path. The IaC comparison covers the tool choice; Get started with IaC covers your first deployment. The infrastructure template library ships validated OpenTofu templates for common patterns.

Infrastructure as code provisions resources. Configuration management is the companion job of configuring the operating system and applications on those resources. Ansible fills that role on Quake AI: provision the instances and networks with OpenTofu, then configure the hosts, deploy software, and handle Day-2 changes with Ansible. See Ansible on Quake AI.

Containers and platform-style hosting#

Containers package an application and its dependencies so it runs the same way on any host. On a single instance you can run Docker and Docker Compose directly, which suits one-host apps and side projects.

For a platform experience on infrastructure you own, a self-hosted control plane such as Coolify gives you git-push deploys, automatic TLS, and database backups on a VM. This is a familiar way to host applications without operating a managed application platform. Start from the containerized app template or the Coolify host template.

Kubernetes and cloud-native#

The Kubernetes service (OpenStack Magnum) provisions clusters through the OpenStack API and exposes the standard Kubernetes APIs. You get horizontal scaling, self-healing, and the cloud-native ecosystem of Helm charts and operators, on a control plane your team operates.

Reach for Kubernetes when you run many services, need rolling deploys and autoscaling, or want a portable target you can move between clouds. See the Kubernetes concepts, Create a cluster, and Deploy a Helm chart. Engineers arriving from GKE, EKS, or AKS can read the matching Kubernetes migration guides.

Automating any rung#

The ladder describes how close to the primitives you work. A second question runs through all of it: who writes the steps. You can move along this axis independently of the rung you chose.

• Manual. You click in the Console or type each command.
• Scripted. You wrap commands in shell scripts or SDK code for repeatability.
• Declarative. You describe the desired state in OpenTofu or Heat and let the tool reconcile it.
• AI-generated. An AI coding assistant drafts the infrastructure code or application code, and you review and verify it.

CI/CD pipelines tie these together: a pipeline runs your tests, plans the infrastructure change, and applies it on merge. See CI/CD integration and Deploy to Kubernetes from CI.

Building with AI coding assistants#

If you build with an AI coding assistant such as Cursor, Claude Code, or VS Code Copilot, the assistant works best when it loads accurate platform context. Quake AI hosts an MCP server that gives the assistant callable tools for searching the documentation, fetching IaC templates, and looking up service endpoints, plus plain-text surfaces (llms.txt, per-page markdown, and knowledge-graph.json) for tools that do not speak MCP. Grounding the assistant in these surfaces means the code it generates targets the real Quake AI APIs and templates. Setup for each client is in AI-assisted development.

How much you lean on the assistant tends to follow a progression:

• Vibe coding. You prompt the assistant and iterate on what it generates, with little formal structure. This is fast and well suited to prototypes, spikes, and early exploration. The originator of the term scoped it to throwaway projects, and that is the right framing: treat vibe-coded output as a draft, not a production system.
• AI-accelerated development. You define the intent and architecture, the assistant drafts the implementation, and automated tests and CI gate the result. You stay accountable for the design and the review. This is where most teams land for production work.
• Agentic engineering. Agents work to a written specification within guardrails: context files that carry your conventions, policy-as-code that constrains what the agent can produce, and CI gates that verify every change. Humans review and approve the merge.

Infrastructure as code is the layer that benefits most from AI generation, because it is pattern-heavy and the templates repeat across projects. Treat AI-generated infrastructure code like any other code: review it, run tofu plan to see exactly what it changes, and gate it through CI before it touches a production account. The same validation checks that back this platform's own templates are the model: well-formed, planned, and confirmed before they run.

Portability and the OpenStack ecosystem#

Quake AI runs on OpenStack, so the broad OpenStack tool universe works against it directly: the openstack CLI, the OpenStack provider for OpenTofu and Terraform, the openstack.cloud Ansible collection, and third-party SDKs and UIs. Skills and tooling you already have for OpenStack carry over, and upstream OpenStack documentation often applies with Quake AI endpoints and limits noted in the service guides.

That portability is the reason you can start anywhere on the ladder and change approach later. Your data uses S3-compatible and standard APIs, your IaC uses providers that target any OpenStack cloud, and your Kubernetes manifests run on any standard Kubernetes cluster. For how each Quake AI service maps to its OpenStack project, see How Quake AI uses OpenStack.

Operating what you build#

Whichever rung you choose, the application layer is yours to operate. A few cross-cutting concerns apply across all of them:

• Testing. Validate infrastructure with tofu validate and tofu plan, and gate application changes through CI.
• Day-2 operations. Upgrades, patching, backups, and incident response live in Operate.
• Observability. Run your own stack, for example Prometheus and Grafana from the monitoring stack template, or connect an external service.
• Cost and capacity. Fixed monthly plans reward deliberate capacity planning. See Pricing on the platform overview and the Quake AI pricing page.

Higher-level application services such as managed databases, function runtimes, and edge caching run on these primitives as software you deploy or as external services you connect. The platform overview maps common requirements to implementation paths.

Where to go next#