Building a Private PowerShell Module Repository for Your Org

Sharing PowerShell scripts and modules across teams shouldn’t feel like passing around USB sticks in a data center. If you’ve ever emailed a `.psm1` file or jammed shared functions into a central server, it’s time to take things up a notch with a private PowerShell repository.

This post walks you through setting up an internal NuGet-based repository and publishing your own PowerShell modules to it. It’s faster, cleaner, and more secure—especially in enterprise environments with strict governance or version control needs.

Why Set Up a Private Repo?

• Version control: Let teams install exactly the version they need, when they need it.
• Security: Avoid fetching code from public galleries by default.
• Simplicity: Give every team a single point of truth for shared functions and tools.

Step 1: Choose a Repository Host

You’ve got a few good options here:

• Azure Artifacts – Built-in to Azure DevOps, easy to integrate with pipeline workflows.
• ProGet – A popular on-prem option with polished PowerShell support.
• Simple File Share + NuGet.Server – Lightweight and easy to stand up inside your network.

For quick setups or testing, you can even simulate a gallery on a shared SMB path or local drive using `Register-PSRepository` with the `-SourceLocation` parameter.

Step 2: Create and Publish a Module

# Define your module and manifest
New-ModuleManifest -Path .\MyModule.psd1 -RootModule MyModule.psm1 -Author "IT Ops" -Description "Functions for our internal automation needs"

# Zip it up and publish
Publish-Module -Path .\MyModule -Repository InternalRepo

Make sure your system has rights to the feed, and that `InternalRepo` is registered correctly. If using Azure Artifacts, you’ll authenticate using a personal access token (PAT) with feed permissions.

Step 3: Install and Use

Register-PSRepository -Name InternalRepo -SourceLocation https://dev.azure.com/org/_packaging/feed/nuget/v2

Install-Module -Name MyModule -Repository InternalRepo

It really is that easy. Use `-Scope CurrentUser` for non-admin installs, and consider setting `-InstallationPolicy Trusted` for internal feeds.

Governance Tips

• Code signing: For added trust, sign modules before publishing and enforce signature checks on load.
• Semantic versioning: Encourage devs to follow `major.minor.patch` versioning to reduce breakage.
• PSGallery blocking: Use group policy or `$PSRepository` settings to restrict installation from public sources.

Bonus: Auto-loading in Profiles

# Sample profile addition
Import-Module MyModule -ErrorAction SilentlyContinue

This lets every new shell session come preloaded with shared commands—great for admin workstations or CI agents.

Final Thoughts

With a private PowerShell repository in place, your scripts and tools become easier to manage, trust, and scale. Whether you're running cloud automation, compliance checks, or DevOps orchestration, this small investment can pay off across your entire org.

Next up, I’ll explore ways to track usage and version drift across teams using a custom auditing script and Power BI. Stay tuned!