The open source Terraform registry landscape, honestly reviewed
If your budget is zero and you have the ops capacity, you do not need to pay anyone to host a private Terraform registry. The open source field is real and some of it is genuinely good. This is a practitioner's tour of it, checked against the projects as they stand, because half the comparison posts out there are quoting feature lists from 2022.
I run a competing product, so read the closing section with that in mind. Everything before it I have tried to write the way I would want a competitor to write about me: fairly, with the good parts named.
All figures below were checked in July 2026 against each project's public repository. Star counts and activity move, so treat them as a snapshot; there is a dated changelog at the foot.
Terralist
The one I would reach for first if I wanted a registry and only a registry. Terralist does both modules and providers, follows the HashiCorp protocols, and is deliberately lightweight, which is the point. It is MPL-2.0, and at the time of checking it was the most actively developed of the pure registries, with commits landing the week I looked.
Its storage story is the sane one. Modules and providers go in private storage, S3 or Azure Blob, and on download it mints a temporary URL and forwards that, so the bucket stays private. There is also a Proxy mode that just forwards whatever source URL you gave it, which is handy if your artifacts already live somewhere addressable. It uses go-getter, the same library Terraform uses, so your usual source protocols keep working. Auth is token-based with API keys for pipelines, and it plugs into Terraform's native terraform login flow.
Where to be clear-eyed: the docs lead with token and API-key auth rather than a rich role model, so if you need fine-grained RBAC out of the box, check the current state before assuming it. But for "I want a private registry for modules and providers, backed by my own bucket, without running a platform," Terralist is the tight, honest option.
Choose it if you want a focused modules-and-providers registry with your own object storage and minimal moving parts.
Terrareg
The registry with the best analysis story. Terrareg is modules-focused, GPL-3.0, and where it stands out is depth: it indexes modules with README rendering, sub-module and example discovery with code snippets, security scan results, and analytics on where modules are used and which Terraform versions call them. It supports Git-based module ingestion with GitHub and Bitbucket push hooks, SSO via SAML or OpenID Connect, and API keys. It self-hosts as a Docker container against MySQL, or SQLite for small instances.
Two honest notes. There is an experimental Go rewrite in progress living alongside the Python codebase; it is explicitly development-only for now, so do not plan around it, but it signals the project is being invested in. And the maintainers themselves flag that Terrareg downloads and analyses modules, which means untrusted modules or providers can run arbitrary code during analysis, so mind what you point it at. It was actively maintained at the time of checking, a single-primary-maintainer project, which is worth knowing for bus-factor reasons even though the activity is real.
Choose it if module analytics, security scan surfacing, and rich module discovery matter more to you than serving providers.
Terrakube
The one that is not really a registry, and that is the point. Terrakube is a full open source IaC platform, aiming to replace closed-source tools like Terraform Enterprise, Scalr, or env0, and the registry is one component of it. It is Apache-2.0, the most-starred and among the most active of the group, and it runs on Kubernetes against any Liquibase-supported database.
The registry serves private modules and providers, though at the time of checking the UI only published modules and providers went through the API. Where Terrakube pulls ahead is everything around the registry: organization-based RBAC, remote state, run orchestration, scheduled workspaces, visual state, and auth through Dex connectors into Azure AD, Google, GitHub, GitLab, and more.
The tradeoff is honest and it is the whole tradeoff of the platform category: you are standing up and operating a Kubernetes platform to get a registry. If you also want remote runs, drift detection, and org RBAC, that is a feature and Terrakube is a serious option. If you only want to distribute modules, it is a lot of surface area, and one of the lighter tools will cost you far less to run.
Choose it if you want a self-hosted Terraform Enterprise replacement and the registry is one piece of that, not the whole ask.
citizen
Worth mentioning mostly so you can make an informed call about it. citizen is an MPL-2.0 module and provider registry that was well-regarded, but at the time of checking its last commit was in October 2024, roughly twenty-one months earlier. That is not automatically disqualifying, a protocol implementation can be "done," and the registry protocol does not churn much. But an unmaintained registry means no security patches, no fixes if a Terraform release changes something, and nobody to ask. Go in with eyes open, and prefer one of the actively-developed options unless you have a specific reason.
Choose it if you have looked at the commit history yourself and are comfortable running something effectively frozen.
At a glance
| Project | Modules | Providers | Auth | Storage | License | Activity (Jul 2026) |
|---|---|---|---|---|---|---|
| Terralist | yes | yes | token / API keys | S3, Azure, Proxy | MPL-2.0 | very active |
| Terrareg | yes | limited | SSO, API keys | Docker + MySQL/SQLite | GPL-3.0 | active, single maintainer |
| Terrakube | yes | API-published | Dex, org RBAC | K8s + RDBMS | Apache-2.0 | very active |
| citizen | yes | yes | token | filesystem | MPL-2.0 | last commit Oct 2024 |
Where Terramantle fits
Here is the pitch, kept honest, because an audience of engineers can smell spin and spin costs the trust this whole post runs on.
Terramantle is the supported-product option. The trade it asks you to make is money for maintenance burden, plus a set of lifecycle features the OSS tools do not attempt. What is actually different and shipping: a dependency graph across your repos showing which workspaces consume which module version, so you can see blast radius before a breaking change; CVE scanning across modules, providers, and state; keyless OIDC publishing from GitHub Actions and GitLab CI; and state hosting, which the pure OSS registries above do not do at all.
What I will not claim, because it would be the exact spin that loses you: Terramantle does not generate a per-module SBOM (the SBOM support is provider-scoped), and the air-gapped bundle-transfer mechanics are architecture we are building toward, not something to point at today. Terralist and Terrakube are genuinely good, and if budget is zero and you have ops capacity, self-hosting one of them is a completely defensible choice that I would not argue you out of.
The registry protocol is the same one everything here speaks, so you are never locked in by the protocol itself. You are choosing who carries the operational weight.
Last checked: July 2026. Star counts, activity, and feature status change; this page is reviewed quarterly.
Changelog: July 2026, first published.
For the protocol these all implement, see the registry protocol explained. If the reason you are shopping is HCP's new pricing, the RUM maths post prices the alternatives, including these.
Last reviewed
Terramantle is a private Terraform and OpenTofu registry. See pricing or read the FAQ.