--- title: "Terraform Module Releaser — GitHub Action for Terraform Monorepos" description: "GitHub Action for Terraform monorepos: semantic versioning, per-module tags, releases, and wiki docs on every pull request. MIT-licensed, GHES-compatible." canonical: "https://www.techpivot.com/work/terraform-module-releaser" source: "https://www.techpivot.com/work/terraform-module-releaser" --- # Terraform Module Releaser A [TechPivot](https://github.com/techpivot) open-source project by Mark Johnson ([virgofx](https://github.com/virgofx)) · Actively maintained · Case study · published July 2026 · Latest release v2.2.0 · Aug 2026 A GitHub Action that automates versioning, releasing, and documentation for Terraform modules kept in a monorepo: per-module tags, releases, and wiki docs, cut automatically on every pull request. [Terraform](https://www.terraform.io/) · [GitHub](https://github.com/techpivot/terraform-module-releaser) One GitHub Action step against any Terraform monorepo. MIT-licensed, zero-config by default, and compatible with GitHub Enterprise Server. [Add this Action](https://github.com/marketplace/actions/terraform-module-releaser) [220+ · GitHub stars](https://github.com/techpivot/terraform-module-releaser) · [19 · releases · latest v2.2.0 (Aug 2026)](https://github.com/techpivot/terraform-module-releaser/releases) · [MIT · license · self-hostable, no lock-in](https://github.com/techpivot/terraform-module-releaser/blob/main/LICENSE) · [Listed · on the GitHub Marketplace](https://github.com/marketplace/actions/terraform-module-releaser) ## GitHub repo sprawl The same pattern appears inside nearly every large GitHub organization: infrastructure teams publish each Terraform module from its own repository, because that is the only way to give each module its own version history. The modules are small. The overhead around them is not. An enterprise repository is never just code. Before the first module ships, the repo has to carry the GitHub-specific plumbing that makes it fit for production, and every piece of that plumbing is defined per repository: - CI workflows - compliance & security scanning - pull request templates - CODEOWNERS - branch protection rules - required status checks - secrets & runner config - Dependabot policy Now run the thought experiment. At five module repositories the duplication is an annoyance. At one hundred, it is a standing tax: a hundred copies of every workflow to patch when a scanner changes, a hundred branch-protection policies to audit, a hundred places for a compliance update to land or quietly miss. Platform teams end up writing automation whose only job is keeping repository scaffolding in sync, which is effort spent on plumbing instead of infrastructure. ## The Terraform monorepo answer The structural fix is to keep every Terraform module in one repository. All of the GitHub-specific machinery is defined once: one set of workflows, one pull request template, one CODEOWNERS file, one branch-protection policy, one surface for compliance to review. The modules themselves are just subdirectories, and the hundredth module costs what the fifth did: a new folder and a pull request. Teams that try it usually hit the same wall, and it is the reason the polyrepo pattern survives: release granularity. Git tags and GitHub releases are repository-wide, not per-directory, while Terraform consumers pin modules by tag. A monorepo with a single version stream either lies about what changed or forces every module to move in lockstep. What was missing was never the monorepo — it was the release pipeline that lets one repository behave like a hundred small ones. ## What the GitHub Action automates Terraform Module Releaser is that pipeline, packaged as a single GitHub Action and driven entirely by pull requests. When a pull request opens or updates, the Action detects exactly which modules changed and computes each one's next semantic version from conventional commits: breaking changes bump major, features bump minor, fixes and chores bump patch. It then comments the release plan on the pull request, so versioning becomes part of code review rather than an afterthought. When the pull request merges, it cuts the releases. Each changed module receives its own Git tag and GitHub release, scoped to just that module's directory contents, so consumers fetch a small, precise artifact instead of the whole repository and Terraform's module retrieval stays fast. The Action also generates a per-module wiki with usage examples, terraform-docs input and output tables, and a full changelog, and it removes tags and releases for modules that have been deleted, so the repository stays clean as it evolves. ![GitHub pull request comment listing two changed modules with planned version bumps](https://www.techpivot.com/assets/pr-separate-modules-updating.By8Tz96N_19jn2i.jpeg) *Two modules changed in one pull request: the Action plans an independent version for each.* The release pipeline on: pull_request 1. detect which modules changed in the monorepo 2. calculate each module's semver bump from conventional commits 3. comment the release plan on the pull request 4. tag + release on merge, scoped to each module's directory 5. generate per-module wiki docs + changelog 6. clean up tags for deleted modules Setup is one workflow file, taken directly from the project README: .github/workflows/release.yml ```yaml name: Terraform Module Releaser on: pull_request: types: [opened, reopened, synchronize, closed] # Closed required branches: - main permissions: contents: write # Required to push tags, create releases, and push changes to the wiki pull-requests: write # Required to comment on pull request jobs: release: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v6 - name: Terraform Module Releaser uses: techpivot/terraform-module-releaser@v2 ``` The defaults are deliberate: zero configuration produces a working release pipeline, and every behavior is overridable when a team's conventions require it, from the semver keywords and first-tag format to wiki layout, tag naming, and cleanup of legacy tags. ## GitHub-native, built for the enterprise The Action is 100% GitHub-native. There is no external service, no registry to operate, no storage bucket, and no credential that leaves your organization: it reads pull request data through the GitHub API and writes tags, releases, and wiki pages back through the same API. For regulated environments that is the difference between adopting a tool and onboarding a vendor; the entire release path stays inside the platform you already govern and audit. It also runs where enterprise GitHub actually lives. The Action detects GitHub Enterprise Server automatically and adjusts its API endpoints, so the same workflow file works on GitHub.com and behind the firewall. It is MIT-licensed, distributed through the GitHub Marketplace, and has shipped steadily since 2024: 19 releases, v2.2.0 current as of August 7, 2026, with dozens of dependent repositories building on it in the open. ### Secure by design - **one action**: A single MIT-licensed Action with auditable source. One dependency to review, not a toolchain. - **your runners**: Runs on the infrastructure you specify: GitHub-hosted, self-hosted, or private GitHub Actions runners. - **your boundary**: No external services. No credentials leave the organization. Every call is the GitHub API you already govern. ![GitHub pull request comment posted by Terraform Module Releaser showing the planned module release and version bump](https://www.techpivot.com/assets/pr-initial-module-release.IZkvI1fV_Z2t1RAk.jpeg) *The Action comments the computed release plan on the pull request, so versioning happens in code review.* ![GitHub release page for a single Terraform module created by the Action, with directory-scoped release notes and assets](https://www.techpivot.com/assets/release-details.CIRNctfU_c73aN.jpeg) *Each changed module gets its own tag and GitHub release, scoped to that directory.* ![Generated GitHub wiki page for one Terraform module showing usage, inputs, and outputs documentation](https://www.techpivot.com/assets/wiki-module-example.BDHbzP2h_1Ojw0V.jpeg) *Usage examples, terraform-docs inputs and outputs, and a changelog, generated per module.* [View on GitHub](https://github.com/techpivot/terraform-module-releaser) · [Back to the practice](https://www.techpivot.com/#open-source) This work grew out of an approach first sketched publicly in [an early community post on GitHub-powered Terraform monorepos](https://cloudchronicles.blog/blog/GitHub-Powered-Terraform-Modules-Monorepo/); the Action turns that idea into a maintained, production-grade tool. ## Let's talk. We take on a small number of engagements where judgment across security, infrastructure, and AI actually moves the needle. If that's the problem you have, we'd like to hear about it. Direct email, no intake forms, no account managers. If it's a fit, you'll know quickly. [Start a conversation](mailto:info@techpivot.com) · [TechPivot on GitHub](https://github.com/techpivot) [info@techpivot.com](mailto:info@techpivot.com) San Diego, California · Working with teams anywhere. --- ```json { "@context": "https://schema.org", "@graph": [ { "@type": "SoftwareApplication", "@id": "https://www.techpivot.com/work/terraform-module-releaser#software", "name": "Terraform Module Releaser", "applicationCategory": "DeveloperApplication", "operatingSystem": "GitHub Actions (GitHub.com and GitHub Enterprise Server)", "softwareVersion": "v2.2.0", "datePublished": "2024-10-09", "dateModified": "2026-08-07", "license": "https://opensource.org/licenses/MIT", "url": "https://github.com/techpivot/terraform-module-releaser", "installUrl": "https://github.com/marketplace/actions/terraform-module-releaser", "description": "A GitHub Action that automates semantic versioning, per-module tags and releases, and wiki documentation for Terraform modules kept in a GitHub monorepo.", "mainEntityOfPage": "https://www.techpivot.com/work/terraform-module-releaser", "author": { "@type": "Person", "@id": "https://www.techpivot.com/#person", "name": "Mark Johnson", "alternateName": "virgofx", "url": "https://www.techpivot.com/" }, "publisher": { "@type": "Organization", "@id": "https://www.techpivot.com/#organization", "name": "TechPivot", "url": "https://www.techpivot.com/" }, "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" } }, { "@type": "BreadcrumbList", "@id": "https://www.techpivot.com/work/terraform-module-releaser#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "TechPivot", "item": "https://www.techpivot.com/" }, { "@type": "ListItem", "position": 2, "name": "Terraform Module Releaser", "item": "https://www.techpivot.com/work/terraform-module-releaser" } ] } ] } ``` Security-first technology consulting. **Site** - [Practice](https://www.techpivot.com/#practice) - [Capabilities](https://www.techpivot.com/#capabilities) - [Services](https://www.techpivot.com/#services) - [Security](https://www.techpivot.com/#security) - [About](https://www.techpivot.com/#about) - [Contact](https://www.techpivot.com/work/terraform-module-releaser#contact) **Open source** - [The work](https://www.techpivot.com/#open-source) - [terraform-module-releaser](https://github.com/techpivot/terraform-module-releaser) - [GitHub Marketplace](https://github.com/marketplace/actions/terraform-module-releaser) - Case study - [@virgofx](https://github.com/virgofx) **Connect** [TechPivot on GitHub](https://github.com/techpivot) · [TechPivot on LinkedIn](https://www.linkedin.com/company/techpivot/) [info@techpivot.com](mailto:info@techpivot.com) San Diego, California © 2026 TechPivot. A San Diego technology consultancy. Sole proprietorship of Mark Johnson. · Cookieless. Privacy by default.