Automation
Coming from another cloud?
▸AWS·Stacks, Systems Manager
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.
Automation
Define your Quake AI infrastructure in code, version it in git, and deploy it repeatably. OpenTofu is the recommended IaC tool for Quake AI: open source (MPL-2.0), fully compatible with Terraform providers and modules, and backed by the Linux Foundation. All Quake AI templates and documentation use OpenTofu. If your team uses Terraform, the same templates work without modification.
For the configuration-management layer above provisioning (installing software, deploying applications, hardening hosts), Quake AI documents Ansible. The recommended pattern is OpenTofu for Day 0 provisioning, Ansible for Day 1 and Day 2 configuration.
What you can do#
Get started with Infrastructure as Code
Install OpenTofu, authenticate to Quake AI, and deploy your first infrastructure from code.
Deploy with OpenTofu
Provision instances, networks, and volumes using OpenTofu with the OpenStack provider.
Deploy a full stack
Build a multi-resource environment (networking, compute, storage, and security groups) in a single OpenTofu configuration.
Configure hosts with Ansible
Install Ansible, authenticate to Quake AI, and run a playbook against an existing VM over SSH.
Combine OpenTofu and Ansible
Provision a VM with OpenTofu, hand off to Ansible via dynamic inventory, and configure the host in a single workflow.
How it works#
OpenTofu and Terraform use the OpenStack provider to manage Quake AI resources. You write .tf files declaring the desired state (instances, networks, volumes, security groups), and the tool calculates the diff, plans changes, and applies them. State lives locally or in a remote backend; Quake AI object storage works as an S3-compatible backend for remote state.
OpenTofu is the primary tool for Quake AI because it is fully open source, uses the same HCL language and provider ecosystem as Terraform, and supports state management, module reuse, and CI/CD integration. If your team already uses Terraform, every Quake AI template works with terraform in place of tofu.
Get started#
If you are new to Infrastructure as Code on Quake AI, start with the getting started guide. Once you have OpenTofu running, explore the template library for repeatable patterns or the Simple VM example for a focused walkthrough.
Key concepts#
Concepts
- Ansible on Quake AI: Ansible is the configuration-management layer for Quake AI infrastructure. Where OpenTofu provisions instances, networks, and volumes, Ansible installs software, deploys applications, and manages OS...
- Authoring IaC Templates for Quake AI: You write OpenTofu or Terraform templates against the OpenStack provider the same way you would on any Antelope-era cloud. Quake AI adds a small, fixed catalog of flavors, networks, and volume types...
- Cloud Automation and Orchestration: Cloud automation replaces manual, click-through provisioning with code that describes your infrastructure. Instead of logging into a dashboard to create a VM, a network, and a security group one at a...
- 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...
- Terraform and OpenTofu on Quake AI: Terraform and OpenTofu use HashiCorp Configuration Language (HCL) to define infrastructure as code. You describe the resources you want (instances, networks, volumes, security groups) in .tf files...
Security considerations#
IaC templates and state files can contain sensitive data: credentials, IP addresses, and resource IDs. Store OpenTofu state in encrypted remote backends, never commit .tfstate files to version control, and use OpenStack application credentials instead of user passwords in provider configuration. For platform-wide security practices, see Security.
Guides and reference#
How-to guides#
- Get Started with Ansible on Quake AI: This guide walks you through installing Ansible, authenticating to Quake AI, building a minimal inventory file, and running your first playbook against an existing instance. By the end, you will have...
- Get Started with Infrastructure as Code on Quake AI: This guide walks you through installing OpenTofu, authenticating to Quake AI, and deploying your first resource. By the end, you will have a running compute instance created entirely from code.
- How to Add a Block Volume to a Template: Attach a block volume to an instance that a template provisions, format it on first boot, and record the mount in /etc/fstab so the filesystem mounts after a reboot. This guide extends templates...
- How to Auto-scale a VM Tier with Heat: Run a private worker tier that grows and shrinks by combining an OS::Heat::AutoScalingGroup with scale-up and scale-down policies. Each policy exposes a signal webhook that your monitoring or queue...
- How to Create a Heat Stack: Heat is a legacy orchestration path on Quake AI. For new projects, use OpenTofu instead.
- How to Customize a Template's Image and Flavor: Change the operating system image or hardware size on an OpenTofu template you already deployed. This guide applies to any template under Automation templates that exposes image_name and flavor...
- How to Debug Terraform Errors: Terraform errors fall into distinct categories that require different debugging approaches: configuration errors caught before any API call, provider errors from the OpenStack API, and state...
- How to Deploy a Multi-tier Application with Terraform: Deploy a public edge proxy, private application instances, and a private database instance with OpenTofu or Terraform. The edge proxy owns the floating IP and routes requests to the application tier...
- How to Deploy an Application to a Quake AI VM from Ci: Ship application changes from GitHub Actions or GitLab CI to a Quake AI instance over SSH. Quake AI does not provide hosted CI runners. Use GitHub-hosted or GitLab.com runners by default, or run a...
- How to Deploy from a Quake.yaml Manifest with Forgejo Actions: Run a Forgejo Actions or Gitea Actions workflow that turns a push into a deployment through a quake.yaml launch handoff packet. The workflow runs on a forge and runner you operate, then deploys to...
- How to Deploy on Git Push with a Webhook Listener: Run a small webhook listener on a VM you operate that redeploys your app when you push to its repository. A push fires a webhook from your forge, the listener verifies the request signature, and a...
- How to Deploy VMs with Terraform (Simple Example): Looking for a ready-to-use template? See the Simple VM template for a parameterized, validated version you can deploy directly.
- How to Emulate a Branchable Postgres Workflow: Create an isolated copy of a PostgreSQL database for a feature branch or pull request preview, then remove the copy when the work is complete. This guide covers three techniques for a self-managed...
- How to Execute a Launch Handoff Packet from Ci: Run a CI job that turns your repository's quake.yaml into a running deployment. Call the prepare_launch MCP tool to get a handoff packet, build and push the image from the resolved build recipe, apply...
- How to Integrate OpenTofu with Ci/cd: Running OpenTofu in a CI/CD pipeline eliminates manual applies, ensures consistent infrastructure changes, and creates an audit trail. This guide shows GitHub Actions and GitLab CI configurations for...
- How to Manage Multiple Environments with OpenTofu: Most production workloads need at least two environments: one for development and testing, one for production. This guide covers two approaches to managing multiple environments on Quake AI with...
- How to Manage OpenTofu State with Quake AI S3: By default, OpenTofu stores state in a local terraform.tfstate file. This works for solo development but breaks down when multiple people or CI pipelines need to apply changes to the same...
- How to Parameterize a Template with a Tfvars File: Reuse the same OpenTofu template in development, staging, and production without forking the HCL. Store environment-specific values in .tfvars files and pass them with -var-file at plan and apply...
- How to Provision a Quake AI Instance with Ansible: This guide creates a complete Quake AI stack (network, subnet, router, security group, keypair, instance, floating IP) using only the openstack.cloud Ansible collection. No OpenTofu, no separate...
- How to Restore PostgreSQL from a Self-managed-postgres Backup: Copy a scheduled pg_dumpall from a running self-managed-postgres instance onto a second, disposable instance, restore it with psql, and confirm databases, roles, and row counts match. The source...
- How to Run Ansible in Ci/cd: This guide runs Ansible playbooks against Quake AI from GitHub Actions and GitLab CI. The same pipeline patterns drive scheduled patching, release deploys, and the Day 1 configuration step that...
- How to Self-host a Ci Server on a VM: Run a continuous integration server on a Quake AI VM to watch your repositories, queue pipelines, and dispatch build jobs. A CI server is the orchestrator that schedules work. It is one component...
- How to Use Ansible Dynamic Inventory on Quake AI: This guide replaces hand-maintained inventory files with the openstack.cloud.openstack plugin, which queries Quake AI directly and groups hosts by metadata. By the end you will have an inventory that...
- Use Ansible with OpenTofu on Quake AI: This guide combines OpenTofu provisioning with Ansible configuration into a single workflow. You will use OpenTofu to create a VM with a floating IP, hand the IP to Ansible, and run a playbook that...
Console guides#
Migration guides#
- How to Migrate from AWS Cloudformation to OpenTofu on Quake AI: If your infrastructure runs on AWS and is defined in CloudFormation, moving to Quake AI means rewriting those stack definitions in OpenTofu HCL. This guide maps common CloudFormation resource types to...
- How to Migrate from Docker Compose to OpenTofu on Quake AI: Docker Compose defines multi-container applications on a single host. Moving to Quake AI with OpenTofu means shifting from container orchestration to infrastructure provisioning: the containers still...
- How to Migrate from Hetzner Cloud to Quake AI with OpenTofu: Hetzner Cloud and Quake AI attract similar audiences: cost-conscious engineers who self-manage infrastructure. If you already use Terraform or OpenTofu with the Hetzner Cloud provider, migrating to...
- How to Migrate from Linode (Akamai) to Quake AI with OpenTofu: Linode (now branded Akamai Cloud Computing) and Quake AI attract similar audiences: cost-conscious engineers who self-manage infrastructure. If you already use Terraform or OpenTofu with the linode...
- How to Migrate from Vultr to Quake AI with OpenTofu: Vultr and Quake AI attract similar audiences: cost-conscious engineers who self-manage infrastructure. If you already use Terraform or OpenTofu with the vultr provider, migrating to Quake AI is a...
CLI reference#
API reference#
Legacy: Heat orchestration#
Quake AI supports Heat (OpenStack-native orchestration) for existing stacks. Heat is a legacy path; new projects should use OpenTofu. If you have Heat stacks in production, they continue to work. For details on Quake AI's OpenStack implementation, see How Quake AI uses OpenStack.
Related services#
Automation templates manage resources across the Quake AI services: Compute instances, Network infrastructure, Storage volumes, and Kubernetes clusters. For storing OpenTofu state remotely, use Object storage with S3-compatible access.