Govern Terraform applies. Chain the downstream stack.

Terraform is a CLI. It runs plan and apply when you tell it to, but it has no scheduler, no event triggers, no pause-and-resume between plan and apply, and no shared visibility layer for the steps that run before or after. Kestra provides all of those. Every Terraform run becomes a workflow step: triggered on schedule or by events, gated by a reviewer, retried on transient failure, and auditable across the full pipeline.

Terraform Cloud (now part of HCP) handles state storage, remote execution, and run management inside the Terraform ecosystem. Kestra sits above that operational layer. It schedules runs, adds a native pause-and-resume between plan and apply, chains Terraform with Ansible, ArgoCD, or any other tool, and gives you one execution history across the full infrastructure workflow. Terraform Cloud is Terraform-only by design. Kestra orchestrates everything around it, and works alongside Terraform Cloud if you use it for state and remote runs.

Kestra has a native scheduler that supports cron expressions, fixed intervals, and event-based triggers. Run terraform plan every hour, capture the diff, and post a Slack alert if the plan is non-empty. The full plan output is stored as a task artifact and replayable from the execution UI.

Kestra's Pause task suspends the flow after terraform plan completes. The plan output is surfaced in the Kestra UI. A named reviewer reads it, optionally adds a comment, and resumes the flow. Only then does terraform apply run. The reviewer identity and timestamp are logged in the execution history. Different reviewers can be wired to different namespaces or environments through Kestra's RBAC.

Each tool runs as a task inside one Kestra flow. terraform apply publishes outputs (IPs, resource IDs, hostnames) that flow forward into the Ansible task. ArgoCD runs after Ansible completes. If Ansible fails, Kestra retries the Ansible step only. The Terraform apply does not re-run. The whole pipeline shares one execution ID, one audit trail, and one place to debug.

Kestra has dedicated plugins for both. The OpenTofuCLI and TerragruntCLI tasks accept the same inputs as the Terraform task, so swapping the binary is a one-line change. The same flow, retries, approval gates, and execution history apply.

No. Kestra calls Ansible playbooks as a task and can fire Jenkins jobs over the API. Many teams start by adding Kestra above an existing Jenkins or Ansible setup: Kestra schedules the run, gates the apply, then hands off to the existing pipeline.

Yes. Wrap the migration in a flow: authenticate against the source and target backends, snapshot the current state to a versioned location, run terraform state mv (or re-init with the new backend), then verify the target backend with a list call. Every step is logged and rerunnable if the verification fails.

Kestra does not manage Terraform state. State stays in your existing backend (S3, GCS, Azure Blob, Terraform Cloud, an on-prem database, or whatever you run today). Kestra injects credentials and tfvars at run time using its built-in secrets manager or an external secrets backend like HashiCorp Vault. Outputs are stored per execution and reusable downstream.

Spacelift is purpose-built for IaC and does that one job well. Kestra is a general-purpose orchestrator. If your Terraform runs sit inside a larger workflow that also calls Ansible, ArgoCD, data pipelines, or business logic, Kestra runs the full chain from one platform with one history. Spacelift stops at the IaC layer.

Kestra ships self-hosted on Docker or Kubernetes, as a managed cloud, or air-gapped for regulated environments. The open-source edition includes unlimited workflows and event-driven triggers. Self-hosted gives full control over where Terraform plans and applies execute, with no external dependency on Kestra's infrastructure. See Kestra for infrastructure automation for the broader picture across Ansible, ArgoCD, and cloud APIs.