Formats/Terraform

A private Terraform module registry, fully managed

Cloudsmith gives your platform and infrastructure teams a fully managed, private Terraform module registry that supports version constraints, access controls, and native CLI integration. Stop reinventing distribution infrastructure and start shipping reusable modules with confidence.

Private module registry

One registry for every Terraform module your platform teams depend on. Cloudsmith gives you version-pinned, access-controlled module distribution with no infrastructure to run.

  • Use Terraform + 30 other formats in one place
  • Serve private modules via the native Terraform Module Registry API, with full version constraint support out of the box
  • Centrally manage Terraform modules alongside containers, Helm charts, and raw binaries in a single platform

Signs you're ready to switch to Cloudsmith for Terraform

If your team manages Terraform modules at scale, the gaps in ad-hoc or Git-based distribution grow fast. Here is what teams typically hit before they move to Cloudsmith.
    No proper version pinning or enforcement
    Modules referenced directly from VCS give consuming teams no stable version contract. Any commit to the default branch can silently change infrastructure. Cloudsmith enforces semantic versioning via the native Terraform Module Registry API, so teams pin a version and get exactly that artifact every time.
    Modules scattered across Git repos with no discoverability
    When modules live in individual repositories, engineers have no way to discover what already exists. Teams reinvent the same networking or IAM modules repeatedly. Cloudsmith gives you a single, searchable registry so platform teams publish once and application teams find and consume with confidence.
    Self-hosted registry infrastructure with ongoing overhead
    Running a self-hosted Terraform registry means provisioning servers, managing storage backends, and owning uptime. Any outage blocks every team that depends on modules from that registry. Cloudsmith is fully managed, so reliability and scaling are handled for you.
    Weak or unscoped access controls
    Access to modules sourced from Git or tied to a platform token is often all-or-nothing. Cloudsmith gives you entitlement tokens and API keys scoped per repository, team, or service account so you control exactly who reads or publishes which modules.
    No audit trail for module consumption
    When a misconfigured module reaches production, knowing which teams consumed which version is critical for impact scoping. Without Cloudsmith's audit logs and download analytics, that investigation takes days instead of minutes.

Why teams choose Cloudsmith for Terraform

Fragmented module distribution slows down platform teams and creates hard-to-audit dependencies. Cloudsmith centralises your private Terraform modules with proper versioning and access control, so your teams ship faster and with fewer surprises.
Without CloudsmithModules referenced from VCS have no stable version contract. Any commit to the default branch can silently change infrastructure across all consumers, with no warning and no rollback path.
With CloudsmithCloudsmith enforces semantic versioning via the native Terraform Module Registry API. Consuming teams declare a specific version in their configuration and Cloudsmith serves exactly that artifact, every time.
Without CloudsmithRunning a self-hosted registry means owning servers, databases, and storage backends. Any outage or misconfiguration blocks every team that depends on modules from that registry.
With CloudsmithCloudsmith is fully managed with no infrastructure to operate. Reliability, scaling, and storage are handled for you, so platform teams spend time building modules rather than babysitting registry infrastructure.
Without CloudsmithAccess to private modules is either all-or-nothing or tied to platform-specific tokens that are awkward to rotate and impossible to scope to individual repositories or consumers.
With CloudsmithCloudsmith gives you entitlement tokens and API keys with per-repository scope, configurable directly in <code>.terraformrc</code>. Rotate credentials without touching module configurations and audit exactly who downloaded what.

How we support Terraform

Cloudsmith gives your infrastructure teams a fully managed private Terraform module registry with native CLI integration, granular access controls, and version pinning out of the box.
    Native Terraform Registry API
    Push and pull Terraform modules via the Cloudsmith CLI or API, then reference them natively using the terraform.cloudsmith.io hostname. Full version constraint support means your infrastructure teams can pin and upgrade modules with confidence.
    Granular Access Controls
    Control access to your module repositories using entitlement tokens and API keys configured directly in .terraformrc. Assign granular permissions per repository, team, or service account to enforce who can read or publish modules.
    Multi-Format, One Platform
    Store your Terraform modules alongside 30+ other artifact formats in a single platform. Manage your entire software supply chain without stitching together separate tools for each format.
    Zero Infrastructure Overhead
    Cloudsmith is fully managed with no infrastructure to operate. You get the elasticity and reliability your teams need without provisioning servers, managing databases, or maintaining registry software yourself.
    Fast Global Distribution
    Modules are served from a globally distributed CDN-backed network, keeping terraform init fast for teams wherever they are. No single-region bottlenecks or slow artifact resolution during CI runs.

Get started with Terraform on Cloudsmith

Frequently asked questions

  1. The Terraform Module Registry API is the standard protocol Terraform uses to resolve and download modules declared with a registry source. Cloudsmith implements this protocol natively, meaning you configure Cloudsmith as your registry host in .terraformrc and run terraform init as you normally would, with no changes to your module declarations.

  2. You add a credentials block to your .terraformrc file pointing at your Cloudsmith registry hostname and supplying an entitlement token or API key. Cloudsmith supports per-repository and per-organisation scoped tokens, so you can issue least-privilege credentials to individual teams or CI pipelines without sharing a single shared secret.

  3. Yes. Modules pushed to Cloudsmith are indexed by version, and consumers can use standard Terraform version constraints such as >= 1.0.0, ~> 2.1, or an exact pin. Cloudsmith serves the requested version exactly, giving your platform teams a stable, reproducible artifact for every environment.

  4. You package your module as a .tar.gz archive and push it using the Cloudsmith CLI or API. The CLI command is cloudsmith push terraform / . From there, the module is immediately available to any consumer with the appropriate credentials.

  5. Yes. Cloudsmith supports 30+ artifact formats in a single platform, including Docker OCI, Helm, NPM, Python, and raw binaries. Your platform team can manage Terraform modules, container images, and Helm charts all in one place, with consistent access controls and audit logging across every format.

  6. Cloudsmith gives you entitlement tokens and API keys scoped to individual repositories or organisations. You can assign read or write permissions per token, rotate credentials independently of module consumers, and audit every download against a specific identity. SAML SSO and SCIM provisioning are also available for enterprise teams.

  7. Yes. Because Cloudsmith implements the standard Terraform Module Registry Protocol, it is compatible with OpenTofu and any other tool that speaks the same protocol. No special configuration is required beyond pointing your registry credentials at the Cloudsmith hostname.

  8. Yes. Cloudsmith provides full audit logs and download analytics for every artifact in your repositories. You can see exactly which identity pulled which module version and when, making it straightforward to scope impact when a module update needs investigating.

  9. Migration is a configuration change, not a code change. You push your existing module archives to Cloudsmith, update the registry hostname in .terraformrc for your teams and CI pipelines, and consuming module source addresses remain unchanged. Cloudsmith's support team can assist with migration planning for larger rollouts.

  10. Cloudsmith distributes artifacts via a CDN-backed network with 600+ edge points of presence, so module downloads are fast regardless of where your engineers or CI runners are located. For teams with strict data residency requirements, Cloudsmith offers dedicated storage regions. Reach out to discuss air-gapped or private link deployment options.

Formats

There’s more than just Terraform on Cloudsmith