Deploy Terraform resources defined in a GitHub repository using S3 remote

Run Terraform infrastructure as code straight from a GitHub repository with Kestra. This blueprint clones a Git repo, runs terraform init, terraform plan, and terraform apply in a single isolated working directory, and stores state in a remote S3 backend so your team always plans and applies against shared, consistent state. It closes the gap between writing HCL and actually shipping it: instead of running Terraform from someone's laptop or a brittle CI script, you get a declarative, auditable pipeline that deploys cloud resources on schedule or on every merge.

How it works

1. The git task (io.kestra.plugin.core.flow.WorkingDirectory) creates an isolated workspace that keeps the cloned files and Terraform working files together for the run.
2. Inside it, clone_repository (io.kestra.plugin.git.Clone) clones the repository and main branch.
3. terraform (io.kestra.plugin.terraform.cli.TerraformCLI) runs terraform init via beforeCommands, then terraform plan and terraform apply -auto-approve, piping each through tee into plan_output.txt and apply_output.txt.
4. A terraform.tfvars file is injected through inputFiles, supplying the target username, hostname, and a password pulled from a secret. Matching outputFiles (*.txt) capture the plan and apply logs as downloadable artifacts.
5. AWS credentials are passed as env so Terraform can reach the remote S3 backend and provision resources.

What you get

• One-click, repeatable Terraform deployments from version-controlled HCL.
• Remote S3 state shared across the team, avoiding local state drift.
• Captured plan and apply logs as run artifacts for review and audit.
• A foundation for GitOps: deploy on schedule or when a pull request merges.

Who it's for

• Platform and DevOps engineers automating cloud provisioning.
• SRE teams enforcing GitOps and reproducible infrastructure.
• Data and ML teams that need infrastructure spun up alongside pipelines.

Why orchestrate this with Kestra

The Terraform CLI has no scheduler, no retry logic, and no event awareness of its own. Kestra adds event triggers (schedule or a GitHub webhook on merge), automatic retries on transient failures, full run lineage with captured plan and apply logs, and a declarative YAML definition you keep in Git. You orchestrate Terraform alongside the rest of your stack rather than wiring it into a separate CI tool.

Prerequisites

• A Kestra instance with the Git and Terraform plugins available.
• A GitHub repository containing valid Terraform configuration with an S3 backend.
• An AWS account and S3 bucket for remote state and resource provisioning.

Secrets

• CI_CD_PASSWORD: password injected into terraform.tfvars.
• AWS_ACCESS_KEY_ID: AWS access key for the S3 backend and providers.
• AWS_SECRET_KEY_ID: AWS secret key paired with the access key.
• AWS_DEFAULT_REGION: AWS region for the backend and resources.

Quick start

1. Add the secrets above to your Kestra instance.
2. Point clone_repository at your own repository and branch.
3. Adjust the terraform.tfvars values to match your configuration.
4. Execute the flow and inspect the plan_output.txt and apply_output.txt artifacts.

How to extend

• Add a Schedule trigger to apply infrastructure on a recurring cadence (GitOps).
• Add a Webhook trigger to deploy whenever a pull request merges.
• Use the -chdir flag if your Terraform lives in a subdirectory, for example terraform apply -auto-approve -chdir=environment/production.
• Split plan and apply into separate flows gated by a manual approval step.

Links

• Terraform plugin documentation
• Terraform orchestration with Kestra