DevOps automation and CI/CD

Run CI/CD, IaC, and DevOps automation on Quake AI. You operate pipelines, runners, OpenTofu or Heat definitions, and secret stores; Quake AI provides compute for build agents, networking, object storage for artifacts, and OpenStack-compatible APIs for provisioning.

What this is for#

Platform and DevOps teams run their CI/CD and infrastructure-as-code against a provider with predictable compute cost and OpenStack-compatible APIs. Quake AI provides the build-agent compute, the Nova and Heat APIs that OpenTofu and Heat target, and object storage for artifacts and remote state; you operate the pipelines, runners, and state backends. The outcome is a CI and provisioning estate targeting Quake AI, deployable from validated OpenTofu templates and their companion tutorials.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

The base is the Development Environment template: the CI runner and toolchain VMs with a data volume. From there the runners call the OpenStack provisioning APIs to apply OpenTofu or Heat, and use Object Storage for build artifacts and remote state.

1. Developers and CI. Commits and merge events trigger pipeline runs on runners you operate.

2. CI runner VMs. Build and deploy agents run on Compute instances. The Development Environment template provisions a runner and toolchain host.

3. OpenStack APIs. Runners call the Nova, Neutron, and Heat APIs through OpenTofu (openstack_* resources) or openstack stack commands to provision and update infrastructure. The Heat Simple Stack template covers an Orchestration entry point.

4. Artifacts and state. Build artifacts, container images, and OpenTofu or Heat state live in S3-compatible Object Storage, which the runners read and write across pipeline stages.

Services involved#

Get started#

• Development Environment template and its deploy tutorial: OpenTofu bootstrap VM for toolchain installs, remote state experiments, and pipeline dry runs.
• Heat Simple Stack template and its deploy tutorial: minimal Heat stack for teams that standardize on OpenStack Orchestration on Quake AI.
• Migrate from AWS CloudFormation to OpenTofu: map CloudFormation resources to OpenTofu before you cut over production stacks.
• OpenTofu template library: browse validated IaC starting points for automation workloads.

Estimate the cost#

Migrating an existing DevOps automation / IaC estate?#

Move a team that already runs CI/CD and infrastructure-as-code on AWS, Azure, GCP, or another hyperscaler. The outcome is the same pipelines and stack definitions targeting Quake AI APIs, with OpenTofu or Heat as the provisioning layer and build agents running on Quake AI compute.

Follow this cutover path. Each step links an existing migration page; this section composes those pages into a workload-shaped sequence rather than duplicating their steps.

1. Map your source provider. Start with the concept-translation page for your current cloud: Coming from AWS, Coming from Azure, Coming from GCP, Coming from DigitalOcean, Coming from Hetzner, Coming from Linode, or Coming from Vultr.

2. Stand up the target shape on Quake AI. Pick the greenfield template that matches how you provision after migration: Development Environment for OpenTofu-first automation and runner hosts, or Heat Simple Stack when Heat remains your orchestration entry point.

3. Translate IaC definitions. Rewrite CloudFormation or CDK stacks with Migrate from AWS CloudFormation to OpenTofu. For compose-defined lab stacks, follow Migrate from Docker Compose.

4. Move build and runner compute. Provision or migrate CI runner VMs with Migrate from EC2 when your agents today run on hyperscaler instances.

5. Switch pipeline targets. Update CI job definitions so tofu apply, openstack stack create, and deployment stages call Quake AI credentials and endpoints. Run pipeline dry runs against a non-production project before you disable the source account jobs.

Workload-specific cutover callouts#

• IaC translation (CloudFormation/CDK to OpenTofu/Heat). CloudFormation keeps state in AWS; OpenTofu and Heat use client-side or stack-local state you manage. Import existing Quake AI resources into state where possible instead of recreating production objects. Run tofu plan on every translated module before apply.
• State migration. Copy or recreate remote state backends (S3, Terraform Cloud, or self-hosted) so the Quake AI workspace owns one canonical state file per stack. Lock state during cutover windows and document who may run apply.
• CI runner switch. Register new runners on Quake AI compute, drain queues on the old pool, then disable source runners so jobs cannot target the previous cloud by mistake. Keep one overlapping runner online until the last scheduled job finishes on the old pool.
• Secret store move. Export CI variables, deployment keys, and cloud credentials from the source vault or provider secret manager. Load them into the store your Quake AI pipelines use, rotate values that cannot move verbatim, and verify signing keys for artifact registries before you merge to the default branch.

Considerations and limits#

• You operate pipelines and state. Quake AI provides compute, storage, and the provisioning APIs; runners, state backends, and secret stores are yours under the shared responsibility model.
• Client-side IaC state. OpenTofu and Heat keep state you manage (a remote backend or stack-local state), not a provider-hosted state service. Lock state during apply windows.
• Flat egress. Quake AI applies a no-egress-fee policy for outbound transfer, which suits artifact pulls and image distribution from CI.
• Three US regions. All current regions are in the United States.
• CPU-only compute. Runners are AMD EPYC with no GPU option (compute FAQ).
• Compliance posture. Quake AI holds SOC 2 Type I and Type II attestations and SOC 3. See Compliance and certifications for the platform scope.