---
title: Automation (IaC)
description: Use infrastructure as code and policy as code to deliver consistent and repeatable landing-zone capabilities.
sidebar:
  label: Automation (IaC)
  order: 15
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/landing-zones/automation-iac/"
source_file: "docs/migration/design-and-mobilize/landing-zones/automation-iac.mdx"
---

## Purpose

Automation ensures that landing-zone capabilities are reproducible, versioned, and tested instead of manually configured.

For migration landing zones, automation is the delivery backbone that connects platform APIs, IaC tools, developer workflows, and release controls into one reliable operating model.

## Core automation building blocks

- **STACKIT API**: Use the API as the foundational control surface for platform automation and integration patterns. <LinkChip href="https://docs.stackit.cloud/developer-tools/stackit-api/">Documentation</LinkChip>
- **Terraform Provider**: Use the official provider for declarative infrastructure provisioning and lifecycle control. <LinkChip href="https://registry.terraform.io/providers/stackitcloud/stackit/latest/docs">Documentation</LinkChip>
- **OpenTofu Provider**: Use OpenTofu with the STACKIT provider as an open IaC option with comparable declarative workflows. <LinkChip href="https://search.opentofu.org/provider/stackitcloud/stackit/latest">Documentation</LinkChip>
- **Pulumi**: Use Pulumi when teams prefer general-purpose languages for infrastructure automation. <LinkChip href="https://github.com/stackitcloud/pulumi-stackit">Documentation</LinkChip>
- **Ansible**: Use Ansible primarily for post-provisioning configuration and operational tasks. In a combined model, Terraform/OpenTofu provision infrastructure while Ansible applies OS and middleware configuration.
- **STACKIT CLI**: Standardize CLI-based operations for scripting, troubleshooting, and repeatable operational run tasks. <LinkChip href="https://docs.stackit.cloud/developer-tools/stackit-cli/">Documentation</LinkChip>
- **SDKs (Go, Python, Java)**: Use SDKs for custom automation and service integrations where IaC abstractions are not sufficient. <LinkChip href="https://docs.stackit.cloud/developer-tools/stackit-sdk/stackit-go-sdk/">Go SDK</LinkChip>, <LinkChip href="https://docs.stackit.cloud/developer-tools/stackit-sdk/stackit-python-sdk/">Python SDK</LinkChip>, <LinkChip href="https://docs.stackit.cloud/developer-tools/stackit-sdk/stackit-java-sdk/">Java SDK</LinkChip>.
- **STACKIT Git**: Use Git as the source of truth for IaC modules, policies, and delivery workflows. <LinkChip href="https://docs.stackit.cloud/products/developer-platform/git/basics/introduction-to-stackit-git/">Documentation</LinkChip>
- **CI/CD Pipeline**: Use pipelines for validation, policy checks, controlled promotion, and auditable releases. <LinkChip href="https://docs.stackit.cloud/products/developer-platform/git/basics/stackit-pipelines/">Documentation</LinkChip>
- **Container Registry**: Use a central registry for versioned build artifacts and deployment consistency across environments. <LinkChip href="https://docs.stackit.cloud/products/developer-platform/container-registry/basics/introduction-to-container-registry/">Documentation</LinkChip>

## How these elements work together

- **Control layer**: STACKIT API, CLI, and SDKs provide direct and programmable control interfaces.
- **Provisioning layer**: Terraform/OpenTofu and Pulumi define and reconcile desired infrastructure state.
- **Configuration layer**: Ansible applies host and middleware configuration after infrastructure provisioning.
- **Delivery layer**: Git and CI/CD pipelines enforce quality gates, policy checks, and controlled rollout across environments.
- **Artifact layer**: Container Registry delivers immutable and versioned artifacts for predictable deployments.

## Terraform/OpenTofu and Ansible delivery flow

Terraform or OpenTofu and Ansible solve different parts of one delivery workflow. Keep the boundary
explicit so infrastructure changes remain reviewable and host configuration remains repeatable.

<CardGrid>
  <Card title="Terraform / OpenTofu">
    Own the infrastructure lifecycle: projects, networks, security controls, compute, storage,
    managed services, and the outputs required by configuration management.
  </Card>
  <Card title="Ansible">
    Own configuration inside the reachable target: operating-system packages, middleware,
    application artifacts, service units, and workload-level validation.
  </Card>
</CardGrid>

<Steps>

1. Version infrastructure inputs, configuration, and application artifact references in Git.
2. Validate and review the Terraform/OpenTofu plan, including replacement and security effects.
3. Apply the approved plan and expose only the target inventory and outputs required by Ansible.
4. Run Ansible idempotently to configure the operating system, middleware, workload, and telemetry.
5. Validate infrastructure state, service health, and operational controls, then retain the evidence.
6. Promote the same versioned workflow through environments instead of repeating manual setup.

</Steps>

Do not use provisioners or ad hoc scripts to blur ownership between both layers. Triggering Ansible
from Terraform can be a practical bridge, but each tool must remain independently understandable,
testable, and rerunnable.

## Recommended operating model

- **Recommendation 1**: Use Git plus CI/CD as default control path and avoid direct manual changes in productive scopes.
- **Recommendation 2**: Choose one primary IaC engine per platform domain (Terraform or OpenTofu) to reduce fragmentation.
- **Recommendation 3**: Use Ansible for configuration management, not as a replacement for declarative infrastructure provisioning.
- **Recommendation 4**: Use SDKs for domain-specific automation where provider resources do not cover required behavior.
- **Recommendation 5**: Version and promote container artifacts through clear environment stages with rollback-ready tags.

## Key design decisions

- **Automation interface strategy**: Define where API, CLI, SDK, and IaC tools are used as primary interfaces.
- **IaC engine strategy**: Decide Terraform versus OpenTofu versus Pulumi based on skills, governance, and ecosystem fit.
- **Module and repository strategy**: Define reusable module boundaries, versioning, and ownership.
- **Pipeline control model**: Implement validation, policy checks, approvals, and promotion gates.
- **Artifact and release strategy**: Define registry usage, image versioning, and rollback standards.

## Typical outputs

- **Reusable automation baseline**: IaC modules, templates, and configuration playbooks with ownership model.
- **Delivery blueprint**: CI/CD flow with quality gates, policy checks, and staged promotions.
- **Integration toolkit**: Standardized use of CLI and SDK automation for operational and product-specific workflows.
- **Release baseline**: Versioned artifact lifecycle in Container Registry with rollback-ready practices.

## Anti-patterns to avoid

- **Too many automation paradigms**: Parallel tool stacks with no clear ownership or governance model.
- **Provisioning and configuration mixed ad hoc**: No clean boundary between IaC provisioning and Ansible configuration.
- **No artifact discipline**: Mutable container tags and unclear release traceability.
- **CLI scripts without Git and pipeline controls**: Operational automation cannot be audited or reproduced reliably.