# Ways to build on Quake AI

Source: https://docs.quake.ai/docs/platform/ways-to-build
Markdown: https://docs.quake.ai/docs/platform/ways-to-build.md
> The common ways to build on Quake AI, from the Console to infrastructure as code, containers, Kubernetes, and AI-assisted development, with the rationale for each and who it fits.

---

# 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](/resources/migration/openstack), 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.

| You are | Start with | Then read |
|---|---|---|
| New to cloud, or building with an AI assistant | The Console and the Quickstart | [Quickstart](/docs/quickstart) |
| A solo or small team shipping fast with AI | AI-assisted development plus infrastructure as code | [AI-assisted development](/resources/ai-assisted-development) |
| Coming from AWS, Azure, GCP, DigitalOcean, or Hetzner | The CLI and a migration guide | [Migration](/resources/migration) |
| Building a SaaS or multi-tier application | Containers or Kubernetes with a reference architecture | [Solutions](/resources/solutions) |

## 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](/docs/platform)
- [Provision your first server](/docs/quickstart)
- [Create a project](/docs/account/projects)
- [Install the CLI](/docs/tools/install-openstack-client)
- [Authenticate with API tokens](/docs/tools/api-tokens)

### Build

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

- [Compute](/docs/compute)
- [Network](/docs/network)
- [Storage](/docs/platform#storage)
- [Deploy a containerized app](/docs/quickstart/deploy-containerized-app)
- [Infrastructure templates](/resources/iac-templates)

### Operate

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

- [Harden a production VM](/docs/compute/how-to/harden-production-vm)
- [Run blue/green or canary deployments with a reverse proxy](/docs/network/how-to/blue-green-canary-deploys)
- [Deploy monitoring](/docs/operate/monitoring/how-to-deploy-monitoring)
- [Schedule volume snapshots and restore data](/docs/block/how-to/schedule-snapshots-and-restore)
- [Security model](/docs/security/shared-responsibility)

### Scale

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

- [Run Kubernetes](/docs/kubernetes)
- [Migrate from another cloud](/resources/migration)
- [Capacity and tiers](/docs/account/resource-tiers)
- [Operations runbooks](/docs/operate)

## The build ladder

<Figure caption="The build ladder: each step up trades direct control over primitives for reuse and convention">

```d2
direction: down

console: Console (click-ops)
cli: CLI, API, SDK
iac: Infrastructure as code
containers: Containers and PaaS on a VM
k8s: Kubernetes and cloud-native

console -> cli: script it
cli -> iac: make it reproducible
iac -> containers: package the app
containers -> k8s: orchestrate at scale
```

</Figure>

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](#automating-any-rung)).

### Console: click to build

The [Console](https://cloud.rumble.cloud) 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](/docs/compute/how-to/create-instance). The [Quickstart](/docs/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](/docs/tools), and construct per-region endpoints from [Service endpoints](/docs/tools/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](/docs/automation/concepts/iac-comparison) covers the tool choice; [Get started with IaC](/docs/automation/how-to/getting-started-iac) covers your first deployment. The [infrastructure template library](/resources/iac-templates) ships [validated OpenTofu templates](/docs/platform/validation#how-infrastructure-templates-are-checked) 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](/docs/automation/concepts/ansible).

### 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](/resources/iac-templates/containerized-app) or the [Coolify host template](/resources/iac-templates/coolify-host).

### 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](/docs/kubernetes), [Create a cluster](/docs/kubernetes/how-to/create-cluster), and [Deploy a Helm chart](/docs/kubernetes/how-to/deploy-helm-chart). Engineers arriving from GKE, EKS, or AKS can read the matching [Kubernetes migration guides](/docs/kubernetes/migration).

## 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](/docs/automation/how-to/cicd-integration) and [Deploy to Kubernetes from CI](/docs/kubernetes/how-to/deploy-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](/resources/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](/docs/platform/validation) 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](/resources/migration/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](/docs/operate).
- **Observability.** Run your own stack, for example Prometheus and Grafana from the [monitoring stack template](/resources/iac-templates/monitoring-stack), or connect an external service.
- **Cost and capacity.** Fixed monthly plans reward deliberate capacity planning. See [Pricing on the platform overview](/docs/platform#pricing) and the [Quake AI pricing page](https://www.quake.ai/pricing/).

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](/docs/platform#self-managed-services-and-deployment-patterns) maps common requirements to implementation paths.

## Where to go next

<UseCaseGrid>
<UseCaseCard
  title="Quickstart"
  description="Sign up, add an SSH key, and launch your first server from the Console. About 20 minutes start to finish."
  href="/docs/quickstart"
  estimatedTime="About 20 minutes"
  services={["Compute"]}
/>
<UseCaseCard
  title="Infrastructure templates"
  description="Validated OpenTofu templates for common patterns: VMs, networks, full stacks, Kubernetes, and object storage."
  href="/resources/iac-templates"
  services={["Automation"]}
/>
<UseCaseCard
  title="Solutions"
  description="Reference architectures for SaaS, AI/ML, media, gaming, and other workloads, each with a diagram and a walkthrough."
  href="/resources/solutions"
  services={["Compute", "Network", "Storage", "Kubernetes"]}
/>
<UseCaseCard
  title="Migration"
  description="Translate your current cloud's concepts to Quake AI and move workloads with per-provider, phased guides."
  href="/resources/migration"
  services={["Compute", "Storage", "Network"]}
/>
</UseCaseGrid>