Skip to content

IaC on Quake AI: OpenTofu and Terraform

Explanation · Updated Jun 2026

Coming from another cloud?

▸AWS·Stacks

Stackshigh

  • 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.
AWS docs ↗
▸Azure·Resource Manager deployment (deployment)

Azure Resource Manager deployment (deployment)high

  • 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.
Azure docs ↗
▸Google Cloud·Deployment Manager

Deployment Managerhigh

  • 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.
Google Cloud docs ↗

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#

Declarative + statefulOpenTofu, Terraform, HeatDeclarative + statelessKubernetes manifestsImperative + statefulAWS CDK, PulumiImperative + statelessBash, Ansible (ad hoc), CLI
Click to zoom
IaC tooling landscape: OpenTofu and Terraform sit in the declarative, stateful quadrant

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.

OpenTofuTerraform
LicenseMPL-2.0 (open source)BSL 1.1 (source available)
Maintained byLinux FoundationHashiCorp / IBM
Provider modelOpenStack + AWS providersOpenStack + AWS providers
State managementLocal or remote (S3-compatible)Local or remote (S3-compatible)
Template formatHCL (.tf files)HCL (.tf files)
Module ecosystemTerraform Registry compatibleTerraform Registry
Quake AI statusRecommendedFully 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 to manage compute instances, networks, security groups, block storage, and floating IPs. For S3-compatible object storage, it uses the AWS provider with a custom endpoint.

OpenTofu authenticates to Quake AI via environment variables, with no credentials in template files. Use the application credential file produced by Generate app credentials:

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

SituationRecommendation
New project, no existing IaCOpenTofu
Existing Terraform workflowsKeep Terraform, or swap to OpenTofu (same templates)
Multi-cloud (Quake AI + AWS/GCP)OpenTofu or Terraform (multi-provider support)
Existing Heat stacks in productionKeep Heat for those stacks; use OpenTofu for new resources
Need to install software, deploy apps, or harden OS on existing VMsAnsible (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 (OpenStack-native orchestration). Heat uses HOT YAML templates with server-side state management. You do not manage .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 shapeStart withConsider instead when
Single public VMSimple VM with Floating IPDevelopment Environment for multi-subnet labs; Containerized App for Docker on one host
Public web entry pointEdge Reverse ProxyAPI Gateway for API routing and policy enforcement; Edge WAF for a filtered public origin
Multi-tier applicationThree-Tier Application or Full-Stack ApplicationEdge Reverse Proxy in front of private application instances; WordPress + MySQL for a CMS plus database pair
Team dev sandboxDevelopment EnvironmentSimple VM for one VM; Private Network + VPN for WireGuard remote access
Managed database hostSelf-Managed PostgreSQLWordPress + MySQL for MySQL; tiered patterns above when the database sits behind web and app layers
Object storage bucketS3 Storage with ACLsCompute templates when the workload needs VMs alongside storage
KubernetesKubernetes Cluster BootstrapContainerized App for Docker without orchestration
ObservabilityMonitoring 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

deployment

Templates

Was this page helpful?