Thanks for the clarification on the differences between Terraform Modules and Providers, @atripp, and for highlighting the current options in ProGet such as Asset Directories. I completely understand the security concerns you're raising around proxying the public Terraform Registry for Providers. In high-control environments, the risk of unvetted uploads is a valid concern, and prioritizing curated approaches to reduce supply-chain risk makes sense.

That said, I don't fully agree that proxying Providers inherently introduces excessive risk for high-control organizations when combined with appropriate internal controls. In our setup, we use around 15 Providers across the organization and rely on automated update tools like Dependabot or Renovate, configured to use a custom internal registry. Proxying the registry enables these tools to surface updates automatically for the Providers we actually use, which is valuable both from a security perspective (timely visibility into fixes and CVEs) and from a developer-experience standpoint. All update suggestions are reviewed and approved by our platform team before being merged, so nothing is consumed unchecked.

Manually downloading and uploading Providers into Asset Directories is certainly a viable option, and I appreciate you calling it out. For us, however, maintaining that process across multiple Providers and frequent releases doesn't scale well long-term and adds operational overhead that automation can handle more reliably.

@stevedennis just checking in, any updates on the rewrite / refactoring of the APIs and adding support for feed groups?

Cheers,
Mikael

Thanks for the clarification on the differences between Terraform Modules and Providers, @atripp, and for highlighting the current options in ProGet such as Asset Directories. I completely understand the security concerns you're raising around proxying the public Terraform Registry for Providers. In high-control environments, the risk of unvetted uploads is a valid concern, and prioritizing curated approaches to reduce supply-chain risk makes sense.

That said, I don't fully agree that proxying Providers inherently introduces excessive risk for high-control organizations when combined with appropriate internal controls. In our setup, we use around 15 Providers across the organization and rely on automated update tools like Dependabot or Renovate, configured to use a custom internal registry. Proxying the registry enables these tools to surface updates automatically for the Providers we actually use, which is valuable both from a security perspective (timely visibility into fixes and CVEs) and from a developer-experience standpoint. All update suggestions are reviewed and approved by our platform team before being merged, so nothing is consumed unchecked.

Manually downloading and uploading Providers into Asset Directories is certainly a viable option, and I appreciate you calling it out. For us, however, maintaining that process across multiple Providers and frequent releases doesn't scale well long-term and adds operational overhead that automation can handle more reliably.

I’d like to add some practical experience to this discussion.

We are currently using Terraform providers extensively, and have done so for several years, against self-hosted, offline installations of HashiCorp Vault, Grafana, our Git platform, ArgoCD, and Artifactory (which we are in the process of replacing, hence our interest in ProGet). None of these environments require outbound internet access at runtime.

Based on that, I don’t fully agree with the documentation saying "In our research, users [...]. They also saw no value in proxying these plugins from Hashicorp's public registry, as internet access was inherently required to use Terraform." In our case, Terraform is very much an offline IaC tool once providers are available. Providers are fetched through proxy, and then used entirely against on-prem/self-hosted services.

For organizations operating in restricted or air-gapped environments, proxying or mirroring the public Terraform Registry is about ensuring controlled, repeatable, and compliant access to upstream providers. This enables a proven, production-grade Terraform workflow, using standard, well-maintained providers, while still meeting strict network and security requirements that are common in enterprise and regulated environments.

@davidroberts63 is spot on — I completely agree with what you’re saying.

In our current setup, we use Terraform with Artifactory to manage everything as code for the past six years. For teams outside the core infrastructure group, this mainly means defining proxies, repositories, and permissions via pull requests in Git. All changes go through review, and this workflow has worked very well for us in practice.

This kind of Git-based, reviewable configuration is something we would definitely have been interested in if we were to go with ProGet as well.

Hi,

We are currently evaluating ProGet for use in our organization, and overall it looks like a very strong product. One of our core requirements, however, is infrastructure-as-code (IaC) and fully reproducible configuration.

For most of our internal tooling (e.g. Grafana, Vault, Artifactory), we manage configuration declaratively using Terraform and Crossplane providers, and aim for a setup where the UI is largely read-only for users, with configuration changes flowing through version-controlled code instead.

I wasn’t able to find an official or community Terraform provider for ProGet, is that correct, or am I missing something?

I see that ProGet exposes a REST API. Does this API cover all configuration aspects (feeds, permissions, retention rules, connectors, etc.), and is it considered stable and supported for full lifecycle management? In other words, could the REST API reasonably serve as the foundation for a complete IaC workflow?

I also noticed the CLI utility, which looks useful, but from our perspective it would require a fair amount of scripting and custom state management to function as an IaC alternative.

What we are ideally looking for is:

• A declarative configuration model
• State management (Terraform / Crossplane style)
• Minimal configuration drift between environments
• The ability to treat the ProGet UI as mostly read-only

Does ProGet currently support (or have plans to support) this kind of workflow, either directly or via recommended tooling?

Thanks in advance, happy to clarify our use case further if helpful.