Want the full power of Terraform providers and modules — without a repo full of .tf files, without a PR for every environment, without GitOps ceremony?

Give your CI pipeline input only, and let it do the rest.

---

How It Works

• One module, one place. Written once by the platform team, checked out at run time. Consumers never see it.
• Workspace per input, not per repo. terraform workspace select -or-create=true "$KEY" — the workspace name is the record of what was requested.
• Variables travel as data. Input goes straight into terraform apply -var=... or TF_VAR_*. Nothing touches disk beyond the ephemeral CI runner.
• Nothing gets committed. No .tf, no generated tfvars, no scaffolding PR.

name: Provision Resource
on:
  workflow_dispatch:
    inputs:
      team: { required: true }
      environment: { required: true, type: choice, options: [dev, staging, prod] }
      size: { required: true, type: choice, options: [small, medium, large] }

jobs:
  apply:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          repository: platform-team/terraform-modules
          path: module

      - uses: hashicorp/setup-terraform@v3

      - working-directory: module
        run: |
          terraform init
          terraform workspace select -or-create=true \
            "${{ inputs.team }}-${{ inputs.environment }}"

      - working-directory: module
        env:
          TF_VAR_team: ${{ inputs.team }}
          TF_VAR_environment: ${{ inputs.environment }}
          TF_VAR_size: ${{ inputs.size }}
        run: terraform apply -auto-approve

Works the same in GitLab CI, Jenkins, CircleCI, or any pipeline that can run a shell step — nothing here is GitHub Actions-specific. Swap workflow_dispatch for a Jenkins parameterized build or a GitLab CI manual job and the rest is unchanged.

---

Is This a Known Pattern?

Mostly. HCP Terraform’s No-Code Provisioning does almost exactly this — but it’s HashiCorp’s own hosted runner, not your CI. Atlantis, Terragrunt catalogs, and Backstage self-service portals get the same UX but deliberately commit a generated file to git as their audit trail — that’s a GitOps choice, not an accident. Crossplane is the closest thing to truly code-free, but it’s a Kubernetes control loop, not an on-demand apply.

The gap: nobody else combines your own CI, any provider with zero git footprint at all — not even generated files.

---

Trade-offs

• Audit trail moves from git to CI logs. Ship them to long-term storage.
• Constrain every input. Use type: choice enums, plus variable validation blocks in the module — never trust raw CI input.
• Add a policy gate before apply on anything production-facing (OPA, Sentinel, or a manual approval environment).

---

Further Reading:

• Terraform No-Code Provisioning — HashiCorp
• Atlantis with Terragrunt — Spacelift
• Crossplane vs Terraform — Crossplane
• Terraform custom validation rules — Terraform Docs