{"id":20976,"date":"2026-05-20T12:56:10","date_gmt":"2026-05-20T20:56:10","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/powershell\/?p=20976"},"modified":"2026-05-20T12:56:10","modified_gmt":"2026-05-20T20:56:10","slug":"powershell-psresource-roadmap-and-best-practices","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/powershell-psresource-roadmap-and-best-practices\/","title":{"rendered":"PowerShell PSResource Roadmap and Best Practices"},"content":{"rendered":"<p>PowerShell is a critical automation and configuration platform across enterprises\u2014and as that automation grows, <strong>how you source, validate, and distribute PowerShell packages<\/strong> becomes just as important as the scripts themselves.<\/p>\n<p>Modern security guidance increasingly treats package feeds as part of the <strong>software supply chain<\/strong>. For PowerShell, that means being deliberate about which repositories you trust, how packages get promoted into your environment, and what your production systems are allowed to install at runtime.<\/p>\n<p>Below, I outline <strong>PSResourceGet<\/strong> best practices for secure environments, then highlight roadmap investments that reinforce secure-by-default package management.<\/p>\n<h2>PSResourceGet Best Practices<\/h2>\n<p>If you aren\u2019t already familiar, PSResourceGet is the modern package management solution for PowerShell, designed for:<\/p>\n<ul>\n<li>PowerShell modules, scripts, and DSC resources<\/li>\n<li>Multiple repository types, including NuGet-style feeds and OCI registries<\/li>\n<li>Explicit repository trust configuration<\/li>\n<li>Enterprise scenarios where packages are curated, mirrored, and approved before production use<\/li>\n<\/ul>\n<p>A core design principle of PSResourceGet is to support multiple repository options so that you can <strong>separate package discovery from package consumption<\/strong>. That separation enables validation, approval, and governance gates\u2014without blocking package discovery.<\/p>\n<p>In practice, the best outcomes come from defining a small set of repositories with clear roles (discovery vs. production), then configuring PSResourceGet trust settings to enforce those boundaries.<\/p>\n<h3>Trusted Sources: Microsoft Artifact Registry (MAR)<\/h3>\n<p>For Microsoft-owned and Microsoft-published PowerShell modules, <strong>Microsoft Artifact Registry (MAR)<\/strong> is the trusted source<\/p>\n<p>MAR provides:<\/p>\n<ul>\n<li>A Microsoft-controlled publishing pipeline<\/li>\n<li>Strong provenance and ownership guarantees<\/li>\n<li>Operational reliability suitable for enterprise automation<\/li>\n<li>Improved availability guarantees compared to PowerShell Gallery<\/li>\n<\/ul>\n<p>MAR is positioned as the <strong>default trusted source for Microsoft-owned content<\/strong>, removing ambiguity about where Microsoft modules should be sourced from and reducing reliance on community mirrors for first-party artifacts.<\/p>\n<p>PSResourceGet supports <strong>OCI-compliant registries<\/strong>, enabling enterprises to use the same infrastructure they already trust for container images and other artifacts.<\/p>\n<p>This allows organizations to:<\/p>\n<ul>\n<li>Reuse existing identity, RBAC, auditing, and networking controls<\/li>\n<li>Centralize PowerShell packages alongside other enterprise artifacts<\/li>\n<li>Apply consistent supply chain governance across technologies<\/li>\n<\/ul>\n<p>Today we only have support for <strong>Azure Container Registry (ACR)<\/strong> as a private repository, but we are working to adopt the .NET ORAS library which will enable support through any container registry (GitHub Container registry is an exciting one).<\/p>\n<h3>The PowerShell Gallery: A Community Repository<\/h3>\n<p>The <strong>PowerShell Gallery<\/strong> remains a critical part of the PowerShell ecosystem. It enables discovery, experimentation, and community collaboration. PowerShell would not be anywhere close to where it is today in terms of reach and popularity without all of the amazing package contributors.<\/p>\n<p>From a security perspective, however, the PowerShell Gallery should be treated as:<\/p>\n<ul>\n<li>Untrusted by default<\/li>\n<li>Community-owned<\/li>\n<li>Unsuitable for direct production dependency<\/li>\n<\/ul>\n<p>Because the Gallery is community-focused and doesn\u2019t fall under any SLAs for availability it should not be treated as a guaranteed, controlled dependency for production workloads. We do our very best to make the gallery a dependable platform (and are in the midst of many infrastructure improvements) but for most environments, it is <strong>not recommended to use the PowerShell Gallery directly from production systems<\/strong>.<\/p>\n<p>Instead, the Gallery should be treated as an <strong>intake and discovery source<\/strong>, with packages promoted into trusted enterprise repositories only after review and approval. At Microsoft we do this through Azure Artifacts feeds and a gated central feed system.<\/p>\n<h3>Private Repositories and Centralized Approval<\/h3>\n<p>A secure enterprise pattern is to introduce a <strong>central private repository<\/strong> that acts as the only trusted source for production systems.<\/p>\n<p>This repository:<\/p>\n<ul>\n<li>Is fully controlled by the enterprise<\/li>\n<li>Contains only vetted and approved packages<\/li>\n<li>Provides predictable availability and performance<\/li>\n<li>Is explicitly configured as trusted in PSResourceGet<\/li>\n<\/ul>\n<p>Azure Artifacts and private Azure Container Registry instances are commonly used for this role.<\/p>\n<h2>Example Enterprise Package Flow<\/h2>\n<ol>\n<li><strong>Discovery<\/strong>\nDevelopers discover packages from:<\/p>\n<ul>\n<li>PowerShell Gallery (community)<\/li>\n<li>Microsoft Artifact Registry (Microsoft-owned)<\/li>\n<li>Trusted partners or internal teams<\/li>\n<\/ul>\n<\/li>\n<li><strong>Review and approval<\/strong>\nPackages are evaluated for:<\/p>\n<ul>\n<li>Security posture (signing, provenance, vulnerabilities)<\/li>\n<li>Licensing and compliance<\/li>\n<li>Compatibility and quality<\/li>\n<\/ul>\n<\/li>\n<li><strong>Promotion to an enterprise feed<\/strong>\nApproved packages are:<\/p>\n<ul>\n<li>Mirrored or re-published into a central enterprise repository<\/li>\n<li>Version-pinned (and optionally scanned) before broader rollout<\/li>\n<\/ul>\n<\/li>\n<li><strong>Production consumption<\/strong>\nProduction systems:<\/p>\n<ul>\n<li>Use PSResourceGet for installs and updates<\/li>\n<li>Trust only the enterprise repository<\/li>\n<li>Do not depend on external feeds at runtime<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h3>Limitations to this workflow<\/h3>\n<p>We are in the design phase of two improvements to this workflow that we hope will make it easier to use and maintain. The first is allowing cross-repository dependencies to be specified in a psd1 and handled in an appropriate manner by PSResourceGet. The second is to allow packages that have been re-published to a central feed to be able to get updates from their original feed. Check out <a href=\"https:\/\/github.com\/PowerShell\/PowerShell-RFC\/pull\/412\">the RFC for cross-repository dependencies here<\/a>.<\/p>\n<h2>Roadmap for PSResourceGet 1.3 (vNext)<\/h2>\n<p>PSResourceGet 1.3 continues the shift toward enterprise-friendly package management: clearer trust defaults, better support for modern registries, and features that reduce friction when you scale installs across fleets and CI\/CD.<\/p>\n<p>We are excited to announce that <a href=\"https:\/\/www.powershellgallery.com\/packages\/Microsoft.PowerShell.PSResourceGet\/1.3.0-preview1\">PSResourceGet 1.3-preview1<\/a> is available with the following updates:<\/p>\n<ul>\n<li>Add\u00a0MARas default registered repository<\/li>\n<li>Add concurrent (parallel) execution for\u00a0Install-PSResourceworkflows<\/li>\n<li>Add DSC V3 resource for PSResourceGet<\/li>\n<\/ul>\n<h3>First-Class DSC Resource Support<\/h3>\n<p>Earlier iterations of package management relied on mechanisms such as <strong>RequiredResourceFiles<\/strong> for Desired State Configuration scenarios.<\/p>\n<p>The roadmap moves toward:<\/p>\n<ul>\n<li>Native DSC resource support<\/li>\n<li>Clear, consistent handling of configuration artifacts<\/li>\n<li>Better integration with modern DSC workflows<\/li>\n<\/ul>\n<p>This simplifies authoring, improves clarity, and reduces special-case behaviors in package management.<\/p>\n<h3>Microsoft Artifact Registry as a Default Repository<\/h3>\n<p>To reduce ambiguity and improve trust defaults, MAR is expected to become a <strong>default repository for Microsoft-owned PowerShell packages<\/strong>.<\/p>\n<p>This:<\/p>\n<ul>\n<li>Makes trust boundaries explicit<\/li>\n<li>Reduces reliance on community mirrors for first-party content<\/li>\n<li>Aligns PowerShell with broader Microsoft artifact distribution patterns<\/li>\n<\/ul>\n<h3>Concurrent Installs and Performance Improvements<\/h3>\n<p>Enterprise automation often installs multiple packages at scale.<\/p>\n<p>Upcoming work focuses on:<\/p>\n<ul>\n<li>Supporting concurrent package installs<\/li>\n<li>Improving performance and reliability<\/li>\n<\/ul>\n<p>Reducing friction in large-scale automation and CI\/CD scenarios<\/p>\n<h3>ORAS Support<\/h3>\n<p>ORAS support improves how PSResourceGet works with OCI registries by using the ORAS client library for pushing and pulling PowerShell artifacts. This strengthens compatibility with enterprise registry implementations and helps align PowerShell packages with the broader OCI ecosystem.<\/p>\n<h3>Cross-Repository Dependencies<\/h3>\n<p>Cross-repository dependency support reduces the need to copy every upstream dependency into the same feed during development. In enterprise environments, this is most useful when paired with policy: allow broader repository access for dev\/test but restrict production to approved repositories only.<\/p>\n<h3>Dropping Support for Windows PowerShell<\/h3>\n<p>Future versions of PSResourceGet (beginning with 1.3) are aligned with the broader PowerShell platform direction, focusing on <strong>PowerShell (Core)<\/strong>.<\/p>\n<p>Removing Windows PowerShell support allows:<\/p>\n<ul>\n<li>Reduced complexity in release and validation process<\/li>\n<li>Support for ORAS library and other new features<\/li>\n<li>Alignment with cross-platform and cloud-native scenarios<\/li>\n<\/ul>\n<p>This reinforces the expectation that modern automation environments standardize on supported, actively developed runtimes.<\/p>\n<h2>Why This Matters<\/h2>\n<p>Together, these investments reinforce our direction:<\/p>\n<ul>\n<li>PowerShell packages are part of the enterprise supply chain<\/li>\n<li>Trust boundaries must be explicit and enforceable<\/li>\n<li>Production automation must be deterministic and reliable<\/li>\n<li>Community innovation and enterprise governance can coexist<\/li>\n<\/ul>\n<p>PSResourceGet is evolving to make secure-by-default behavior the easiest path forward\u2014so teams can move fast <em>and<\/em> keep trust boundaries explicit.<\/p>\n<p><strong>Next steps:<\/strong> If you manage PowerShell in an enterprise, inventory which repositories your automation can reach today, decide what your single trusted production feed should be, and set PSResourceGet trust configuration to enforce that model. Then, build a lightweight intake process (review, scan, approve, promote) for anything sourced from the broader community.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>PowerShell is a critical automation and configuration platform across enterprises\u2014and as that automation grows, how you source, validate, and distribute PowerShell packages becomes just as important as the scripts themselves. Modern security guidance increasingly treats package feeds as part of the software supply chain. For PowerShell, that means being deliberate about which repositories you trust, [&hellip;]<\/p>\n","protected":false},"author":2299,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-20976","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell"],"acf":[],"blog_post_summary":"<p>PowerShell is a critical automation and configuration platform across enterprises\u2014and as that automation grows, how you source, validate, and distribute PowerShell packages becomes just as important as the scripts themselves. Modern security guidance increasingly treats package feeds as part of the software supply chain. For PowerShell, that means being deliberate about which repositories you trust, [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/20976","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/2299"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=20976"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/20976\/revisions"}],"predecessor-version":[{"id":20977,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/20976\/revisions\/20977"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=20976"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=20976"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=20976"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}