PSResourceGet: Fast, Secure PowerShell Package Management for Enterprises

PSResourceGet is the modern, faster package manager for PowerShell that replaces the old PowerShellGet provider model and gives administrators a more predictable, secure, and flexible way to discover, install, update and publish PowerShell artifacts across environments.

Background​

PowerShellGet served administrators well for years, but its architecture—built on the PackageManagement (OneGet) provider model—introduced complexity, dependency bottlenecks and maintenance challenges. PSResourceGet (published as Microsoft.PowerShell.PSResourceGet) rewrites that model with a simpler engine, broader artifact support, and tighter integration with modern PowerShell releases. The module is included in PowerShell 7.4 and is available for older supported PowerShell versions via the gallery; Microsoft describes it as a continuation of the PowerShellGet v3 project and a fresh-engine implementation aimed at stability and faster iteration.
PSResourceGet is intentionally positioned as the canonical package manager for PowerShell artifacts (modules, scripts, DSC resources, role capabilities and other resource types), exposing a new cmdlet surface—Install-PSResource, Find-PSResource, Update-PSResource, Save-PSResource, Register-PSResourceRepository, Unregister-PSResourceRepository and others—that simplifies common admin workflows while offering advanced features such as NuGet-style version ranges, repository priority, and improved credential handling.

---

Why PSResourceGet matters for Windows administrators​

Adopting PSResourceGet is less about chasing the latest tool and more about addressing persistent operational problems:

• Performance and predictability. PSResourceGet removes the intermediary provider model and reduces the number of moving parts in lookups and installs, yielding measurable speed improvements for Find/Install operations. Microsoft and the project team prioritized performance improvements to make gallery browsing and automation faster.
• Cleaner compatibility path. PSResourceGet ships in PowerShell 7.4 and is supported on all supported PowerShell versions. For shops not yet ready to refactor scripts, Microsoft ships a compatibility layer so older PowerShellGet-style commands can be proxied to PSResourceGet behavior—this reduces friction for CI/CD and automation pipelines.
• Modern dependency and version handling. The engine accepts NuGet-style version ranges for Install and Find operations, which simplifies pinning, ranges, and dependency expression in automated deployments. This is especially helpful for large estates where you want a minimum or an allowed window of versions rather than a single hard-coded version.
• Better repository control. PSResourceGet introduces repository priorities, per-call trust flags and improved repository registration semantics, which make multi-repository estates (public gallery + internal gallery + GitHub Packages, for example) much easier to manage.

---

Overview of core capabilities​

Discovery and search​

• Find-PSResource looks across registered repositories for matching resource names and supports:
• Wildcards and prerelease filtering.
• NuGet-style version ranges to search for highest-compatible versions within bounds.
• Search performance is materially improved compared with the older provider-backed Find-Module approaches, making ad-hoc gallery browsing from the console practical and fast. Microsoft’s engineering notes and the module’s GitHub repository explain the changes to caching and the removal of the provider layer as a root cause for the speed boost.

Installation, updates and removal​

• Install-PSResource replaces Install-Module/Install-Script semantics for new scripts and modules. It accepts:
• Exact versions and NuGet-style version ranges (e.g., '[1.5,2.0)' ), which let you express minimum and maximum bounds in one parameter.
• A -TrustRepository switch to avoid interactive prompts when installing from a repository you already trust for that operation.
• Update-PSResource and Uninstall-PSResource provide lifecycle control similar to older cmdlets but integrated with the new engine’s dependency resolution and repository priorities.

Repository management​

• Register-PSResourceRepository / Get-PSResourceRepository / Unregister-PSResourceRepository manage the set of repositories available to PSResourceGet. Repositories support:
• A Priority property (0–100) so administrators can prefer internal feeds over the public gallery.
• Repository trust semantics and a -Force parameter on registration to simplify scripted updates to repository lists.
• PSResourceGet recognizes several repository types including PowerShell Gallery, GitHub Packages (via NuGet feed endpoints), Artifactory and Azure artifacts; preview releases expanded support to more private feed types.

Publishing and packaging​

• The PSResourceGet project retains publish capabilities and introduces enhancements for prerelease dependencies and package metadata. It also allows saving resources locally with Save-PSResource (useful when performing offline installs or validation). The project continues to iterate on publishing and dependency features.

---

Practical examples and recommended workflows​

1) Quick install and version pinning​

Install the Microsoft.Graph module (latest available) with:

• Install-PSResource -Name Microsoft.Graph

To install a specific version:

• Install-PSResource -Name Microsoft.Graph -Version 2.21.0

To install a version satisfying a range (greater than or equal to 1.5 but less than 2.0):

• Install-PSResource -Name Microsoft.Graph -Version '[1.5,2.0)'

Find-PSResource can be used to validate available versions before install. PSResourceGet supports the NuGet version-range syntax exactly for these parameters.

2) Register an internal GitHub Packages feed and prioritize it​

To register a GitHub organization NuGet feed and prefer it over the PowerShell Gallery:

• $splat = @{
  Name = 'GitHubOrg'
  Uri = 'GitHub Actions<GitHubOrg>/index.json'
  Trusted = $true
  Priority = 10
  }
• Register-PSResourceRepository @splat

By setting Priority lower than the default (lower = higher priority), PSResourceGet will prefer the internal feed when resolving names found in multiple repositories. Use Get-PSResourceRepository to verify settings. Note that repository types and supported authentication modes may vary; feed authentication often requires credentials or token-based mechanisms and PSResourceGet has been evolving native credential handling in previews.

3) Install across many servers (remoting)​

For fleet-wide installs, use PowerShell remoting or orchestration tooling. A quick pattern using PowerShell 7’s parallel ForEach-Object:

• Get-ADComputer -Filter 'OperatingSystem -like "Server"' |
• ForEach-Object -ThrottleLimit 5 -Parallel {
  Invoke-Command -ComputerName $_.Name -ScriptBlock {
  Install-Module -Name Microsoft.PowerShell.PSResourceGet -Confirm:$false -Force
  Install-PSResource -Name PSWindowsUpdate -Confirm:$false
  }
  }

This script installs PSResourceGet if absent, then installs PSWindowsUpdate remotely; it requires PowerShell 7+ for the -Parallel parameter and proper remoting/configuration on targets. Validate remoting, credentials and firewall/endpoint policies before mass deployment.

4) Pin dependencies with RequiredResource/RequiredResourceFile​

For reproducible deployments, declare required resources in a JSON/psd1 file (or in-line hash table) and pass it to Install-PSResource using -RequiredResource/-RequiredResourceFile. This lets you declare multiple module dependencies with explicit repository and version-range metadata and centralizes dependency resolution across a deployment pipeline. The module supports these structured requirements and will install matching versions from the appropriate repositories.

5) Offline installs and artifact caching​

Use Save-PSResource to download a local nupkg and metadata so you can inspect, sign, or stage artifacts in an internal feed. Local artifact caching is especially important for controlled enterprise environments or where internet access is restricted. PSResourceGet’s Save and Install workflows help create repeatable, auditable installs.

---

Strengths: what PSResourceGet delivers well​

• Faster gallery operations. Removing the provider layer and optimizing searches makes Find and Install operations noticeably quicker for interactive use and in automation. This reduces friction when developers or admins browse for modules directly from a shell.
• Modern version semantics. NuGet-style version ranges are expressive and match what modern package managers expect—this helps maintainers express compatibility windows across module ecosystems.
• Compatibility bridge. Microsoft shipped a compatibility layer (PowerShellGet v3 preview) that proxies many classic commands to the PSResourceGet engine so existing scripts can continue to run while teams port their tooling on a schedule.
• Repository control and enterprise friendliness. Priorities, trust flags and better repository registration semantics make multi-feed deployment topologies (public + private + vendor feeds) manageable and scriptable.
• Active development and maintainability. The new codebase and Microsoft’s public GitHub development model make it quicker to address bugs and accept community feedback compared to the earlier PowerShellGet era.

---

Risks, caveats and operational concerns​

• Supply chain and trust risks. By making repository access and installation very convenient, PSResourceGet also magnifies the consequences of trusting the wrong feed. Avoid using -TrustRepository casually in automated runs; prefer explicit, auditable repository registrations and vet any internal feed that proxies public artifacts. Signed artifacts, internal vetting pipelines, and artifact scanning should be part of enterprise adoption.
• Credential handling and private feed auth. While PSResourceGet has been adding native credential persistence and support for private feeds, authentication models differ by provider (GitHub Packages, Azure Artifacts, Artifactory). Test authentication flows, credential lifetime, and token rotation policies; avoid embedding long lived tokens in scripts. Preview docs note native credential management improvements, but administrators must verify behavior for their chosen repository type.
• Compatibility surprises. Although Microsoft provides a compatibility module, behavior is not always identical; scripts that rely on subtle behaviors or specific parameter sets should be validated in a staging environment. Use the compatibility layer to buy time, not as a permanent crutch.
• Version-range semantics are powerful but subtle. NuGet ranges are expressive but can be misunderstood—e.g., inclusive vs exclusive endpoints. Always verify the resolved version with Find-PSResource before mass-deploying, and use explicit pins for production-critical systems. Documentation clarifies the inclusivity rules and the way PSResourceGet interprets minimum-inclusive ranges.
• Tooling and CI integration. If your CI/cd pipelines expect the older PowerShellGet behavior, validate the pipeline’s dependencies. The compatibility proxy smooths the transition, but CI should ideally be updated to call PSResourceGet directly for new builds and deployments.

---

Recommended adoption checklist for enterprises​

• Inventory current use of Install-Module / Find-Module / Update-Module and where those commands are used in scripts, scheduled tasks and CI pipelines.
• Create a small pilot group and install PSResourceGet (or move to PowerShell 7.4 where it’s bundled) and enable the compatibility module where needed.
• Convert key deployment scripts to Install-PSResource with explicit version ranges or pins; validate using Find-PSResource queries in a test environment.
• Register internal artifact repositories with explicit Priority and Trusted settings; use Save-PSResource to stage artifacts for offline environments.
• Add repository and artifact checks to CI pipelines—verify resolved versions and artifact signatures before promoting to production.
• Implement repository vetting, scanning and signing policies; avoid -TrustRepository in unattended automation unless repository policies are enforced and auditable.
• Monitor the PSResourceGet GitHub repo and PowerShell Team blog for updates—features like native credential persistence and ACR support were added progressively in previews, so staying current avoids surprises.

---

Practical tips and quick reference​

• Use Find-PSResource -Name 'ImportExcel' to preview metadata and ProjectUri before you install a community module. Use the returned ProjectUri to validate the module’s home page and code before trusting it.
• For reproducibility, prefer NuGet range expressions in a RequiredResource file and surface that file from CI; this makes roll-forward decisions deliberate and auditable.
• Prefer private internal feeds with higher priority for production installs; use the public gallery for development or controlled promotion.
• When automating remoting installs, ensure the remote session has the module dependencies for PSResourceGet itself, or install the module first (Install-Module Microsoft.PowerShell.PSResourceGet) before calling Install-PSResource.

---

Conclusion​

PSResourceGet is a meaningful step forward in PowerShell artifact management—faster, more maintainable, and better suited to modern enterprise workflows than the provider-backed PowerShellGet of the past. It delivers better version control through NuGet-style ranges, clearer repository semantics with priorities and trust flags, and a compatibility path for legacy automation. However, its benefits come with the familiar operational responsibilities of package management: vet repositories, sign and scan artifacts, and validate changes in a controlled pipeline.
Adopt PSResourceGet methodically: inventory usage, pilot the tooling, convert critical pipelines, and bake repository governance into your release process. Doing so turns the module’s performance and usability gains into reliable, enterprise-grade deployment hygiene rather than a vector for misconfiguration or supply-chain risk.

---

Source: TechTarget Use PSResourceGet to manage PowerShell modules and scripts | TechTarget