IaC on Quake AI: OpenTofu and Terraform
Coming from another cloud?
▸AWS·Stacks
Stacks
- Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
- EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
- CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
- Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
▸Azure·Resource Manager deployment (deployment)
Azure Resource Manager deployment (deployment)
- Authoring format differs: ARM templates are JSON documents for Azure Resource Manager deployments, whereas Quake AI offers Heat (legacy, HOT/YAML format) and recommends OpenTofu (HCL) for new infrastructure automation.
- Deployment target/scope differs: ARM templates can deploy at multiple scopes (resource group, subscription, management group, tenant) via Azure Resource Manager's management layer, while Heat orchestrates within a single OpenStack project/tenant. OpenTofu can target multiple projects via provider configuration.
- Change-preview behavior differs: ARM supports a built-in “what-if” style preview of changes via Resource Manager deployments, while OpenTofu provides `tofu plan` for change previews. Heat relies on stack update events (legacy workflow).
- Resource coverage lifecycle differs: ARM templates support Azure resource types exposed by Azure resource providers; OpenTofu covers OpenStack resource types via the OpenStack provider, and Heat (legacy) supports a narrower set via built-in resource plugins.
▸Google Cloud·Deployment Manager
Deployment Manager
- Uses YAML configurations with optional Jinja2/Python templates expanded server-side; Quake AI offers Heat (legacy, HOT/YAML) and recommends OpenTofu (HCL) for new work.
- Resource types named as service.v1.resource (e.g., compute.v1.instance) tied to GCP APIs, vs OpenStack prefixed types like OS::Nova::Server.
- Single integrated GCP service (no separate API/engine processes); Heat has a multi-service architecture (heat-api, heat-engine) but is legacy. OpenTofu runs client-side with no server component.
- No additional service fee; bills only for deployed GCP resources, same as OpenStack resources billing via provider.
IaC on Quake AI: OpenTofu and Terraform
OpenTofu is the default Infrastructure as Code tool for Quake AI. It is fully open source (MPL-2.0), backed by the Linux Foundation, and compatible with Terraform providers, modules, and state files. Quake AI templates and IaC how-to guides use OpenTofu.
If your team already uses Terraform, Quake AI templates work without modification: replace tofu with terraform in commands and you are set.
For rules when you author or extend templates, see Authoring IaC templates for Quake AI.
OpenTofu vs. Terraform#
The diagram places Ansible in the imperative + stateless quadrant, but only for ad-hoc provisioning. That placement reflects how the openstack.cloud modules execute: each task issues an API call and reports changed: true based on the response, with no state file kept between runs. For provisioning workloads, OpenTofu's stateful, declarative model is a better fit; reach for OpenTofu first.
Ansible's primary role on Quake AI is configuration management, not provisioning. For Day 1 and Day 2 work, configuring an OS, deploying applications, rotating credentials, the same imperative + stateless properties become a feature: Ansible is idempotent at the task level (file present, package installed, service running), so reruns converge a host without needing a global state file. The full split is documented in Ansible on Quake AI and the getting-started how-to.
| OpenTofu | Terraform | |
|---|---|---|
| License | MPL-2.0 (open source) | BSL 1.1 (source available) |
| Maintained by | Linux Foundation | HashiCorp / IBM |
| Provider model | OpenStack + AWS providers | OpenStack + AWS providers |
| State management | Local or remote (S3-compatible) | Local or remote (S3-compatible) |
| Template format | HCL (.tf files) | HCL (.tf files) |
| Module ecosystem | Terraform Registry compatible | Terraform Registry |
| Quake AI status | Recommended | Fully supported |
In practice, there are no functional differences for Quake AI usage. The providers, state format, and HCL syntax are identical. The difference is licensing and governance.
Why OpenTofu#
- License clarity. MPL-2.0 is a well-understood open-source license with no usage restrictions. BSL 1.1 restricts competitive use, which creates ambiguity for some organizations.
- Community governance. The Linux Foundation provides neutral stewardship. No single vendor controls the roadmap.
- Feature parity. OpenTofu tracks Terraform provider compatibility. The OpenStack provider works identically in both tools.
OpenTofu on Quake AI#
OpenTofu uses the OpenStack provider
OpenTofu authenticates to Quake AI via environment variables, with no credentials in template files. Use the application credential file produced by Generate app credentials:
export OS_AUTH_URL="https://keystone.rumble.cloud"
export OS_AUTH_TYPE="v3applicationcredential"
export OS_APPLICATION_CREDENTIAL_ID="YOUR_APP_CREDENTIAL_ID"
export OS_APPLICATION_CREDENTIAL_SECRET="YOUR_APP_CREDENTIAL_SECRET"
export OS_REGION_NAME="us-east-1"Terraform on Quake AI#
Terraform remains fully supported. The same OpenStack and AWS providers, the same HCL syntax, and the same state format work on Quake AI. OpenTofu templates in the Quake AI library run with terraform instead of tofu.
If your team uses Terraform Cloud, Terraform Enterprise, or Spacelift for remote state and runs. Those workflows are compatible with Quake AI resources through the OpenStack provider.
Choosing the right tool#
| Situation | Recommendation |
|---|---|
| New project, no existing IaC | OpenTofu |
| Existing Terraform workflows | Keep Terraform, or swap to OpenTofu (same templates) |
| Multi-cloud (Quake AI + AWS/GCP) | OpenTofu or Terraform (multi-provider support) |
| Existing Heat stacks in production | Keep Heat for those stacks; use OpenTofu for new resources |
| Need to install software, deploy apps, or harden OS on existing VMs | Ansible (configuration management above OpenTofu provisioning) |
For a new project, start with OpenTofu. The getting started guide walks you through installation, authentication, and your first deployment.
Legacy: Heat#
Quake AI also supports Heat.tfstate files. However, Heat cannot manage resources outside OpenStack (no S3 buckets, DNS records, or external services), has no module ecosystem, and does not support a plan step before applying changes.
Heat is a legacy path. Existing Heat stacks on Quake AI keep running. For new infrastructure, use OpenTofu.
Choosing a deployment pattern#
Quake AI ships OpenTofu templates under Infrastructure templates. Each template is a deployment pattern: a composition of primitives, not a standalone service. Use the table below to pick a starting pattern; each reference page includes a When to use this pattern blurb with sibling alternatives.
| Workload shape | Start with | Consider instead when |
|---|---|---|
| Single public VM | Simple VM with Floating IP | Development Environment for multi-subnet labs; Containerized App for Docker on one host |
| Public web entry point | Edge Reverse Proxy | API Gateway for API routing and policy enforcement; Edge WAF for a filtered public origin |
| Multi-tier application | Three-Tier Application or Full-Stack Application | Edge Reverse Proxy in front of private application instances; WordPress + MySQL for a CMS plus database pair |
| Team dev sandbox | Development Environment | Simple VM for one VM; Private Network + VPN for WireGuard remote access |
| Managed database host | Self-Managed PostgreSQL | WordPress + MySQL for MySQL; tiered patterns above when the database sits behind web and app layers |
| Object storage bucket | S3 Storage with ACLs | Compute templates when the workload needs VMs alongside storage |
| Kubernetes | Kubernetes Cluster Bootstrap | Containerized App for Docker without orchestration |
| Observability | Monitoring Stack (Prometheus + Grafana) | Pair with an application pattern above to scrape production instances |
After you deploy, customize any OpenTofu pattern through the shared how-tos linked from each template reference page.
See also#
Related content
Pages
How-tos
How to add a block volume to a template
Automation
How to customize a template's image and flavor
Automation
How to debug Terraform errors
Automation
How to deploy a multi-tier application with Terraform
Automation
How to deploy an application to a Quake AI VM from CI
Automation
How to deploy VMs with Terraform (simple example)
Automation
How to emulate a branchable Postgres workflow
Automation
How to integrate OpenTofu with CI/CD
Automation
How to launch a Windows Server VM
Compute
How to manage multiple environments with OpenTofu
Automation
How to manage OpenTofu state with Quake AI S3
Automation
How to parameterize a template with a tfvars file
Automation
How to restore PostgreSQL from a self-managed-postgres backup
Automation
Tutorials
Explanations
Overviews
migration
How to migrate from AWS CloudFormation to OpenTofu on Quake AI
Automation
How to migrate from Docker Compose to OpenTofu on Quake AI
Automation
How to migrate from Hetzner Cloud to Quake AI with OpenTofu
Automation
How to migrate from Linode (Akamai) to Quake AI with OpenTofu
Automation
How to migrate from Vultr to Quake AI with OpenTofu
Automation
Migrate a Docker container app from AWS to Quake AI
Compute
Migration Guides
Automation
deployment
Deploy a private container registry with OpenTofu
Automation
Deploy a self-hosted git forge and CI with OpenTofu
Automation
Deploy an inference gateway with OpenTofu
Automation
Deploy the audio post-production worker template with OpenTofu
Automation
Deploy the CPU render-farm worker pool template with OpenTofu
Automation
Deploy the Creator-AI inference worker template with OpenTofu
Automation
Deploy the development environment template with OpenTofu
Automation
Deploy the full-stack application template with OpenTofu
Automation
Deploy the Kubernetes cluster bootstrap template with OpenTofu
Automation
Deploy the live RTMP/SRT ingest and restream template with OpenTofu
Automation
Deploy the monitoring stack template with OpenTofu
Automation
Deploy the MySQL/MariaDB database template with OpenTofu
Automation
Deploy the private network + VPN template with OpenTofu
Automation
Deploy the S3 Storage with ACLs template with OpenTofu
Automation
Deploy the self-managed PostgreSQL template with OpenTofu
Automation
Deploy the Simple VM template with OpenTofu
Automation
Deploy the three-tier application template with OpenTofu
Automation
Deploy the WordPress + MySQL template with OpenTofu
Automation