When a third party owns and curates your PowerShell modules, you risk introducing problems and have to give up the dream of keeping proprietary stuff private. ProGet gives you all the self-service and storage with none of the common risks.

Before diving into the How-To, I wanted to share a bit about the Why – and how ProGet can increase control without limiting self-service; ensure better quality for public PowerShell; and maintain near-constant access to the public Gallery.

But I’ll also show you how to set up your own private repository in 15 minutes.

Hosting Private PowerShell Modules

Benefit 1: Increase control without limiting self-service with private storage for proprietary PowerShell modules

Using PowerShell modules with ProGet helps keep first-party PowerShell both private and easily accessible for internal use.

Connectors let you aggregate or separate feeds to meet your unique needs. And unlimited PowerShell feeds mean you can keep production-ready and -unready modules clearly separated with feeds like “Validated” and “Private.”

ProGet can enforce access rules on top of separating modules by quality in different feeds. Feed-level privilege controls in ProGet give granular control over per-feed permissions. Make it even easier by integrating with AD/LDAP to use existing teams and roles.

Benefit 2: Ensure better quality for public PowerShell modules

When developers go to the PowerShell Gallery to find a solution to a specific problem, they can inadvertently introduce new problems.

ProGet offers vulnerability scanning to automatically detect package vulnerabilities and to define risk (allow, block, caution, custom) for each vulnerability type on an ongoing basis.

License detection and blocking offer additional peace of mind to avoid the liability and litigation of licenses like GPL-3. License detection and blocking in ProGet read package metadata to alert you of licenses present. Then you can configure ProGet to block (or allow) certain license types, keeping unwanted licenses far away from production (and from the engineers who don’t know to avoid them).

Benefit 3: Unfettered access to the PowerShell Gallery with storage and caching

Proxying the PowerShell Gallery with ProGet gets your developers the packages they need while following organizational rules for security and privacy, and while letting you filter out unacceptable packages.

ProGet can “stand in front of” PowerShell as your proxy to get 100% of the modules you need with 0% direct contact with the site.

And with package and metadata caching, you can avoid developer interruptions. Cache locally to reduce response times and ensure your third-party packages are available even if the Gallery is running slow or goes down.

Additional Feature for Efficiency and Safety: Promotion

Keep your modules separated by team or by quality without difficult, time-consuming package-sharing. Package promotion copies a package between feeds in just three clicks. And a package promotion pipeline restricts the ‘promote to’ feed, adding an extra layer of privilege controls. And to further indicate production-ready packages, use repackaging to change its pre-release tag while maintaining package immutability. Exactly what was tested goes to production.

Here’s How to Use ProGet for Your PowerShell Modules

In less than 15 minutes, you could already be publishing your PowerShell modules.

Step 1: Install ProGet

Download ProGet, which will install the lightweight Inedo Hub. Depending on your Internet connection, you can have ProGet installed in as little as two minutes. Don’t have a license key? Let ProGet know when you install it, and you’ll be prompted to create one after installation. And don’t worry about extra costs: you can create as many PowerShell feeds as you want in the free-forever version of ProGet.

Step 2A: Create a “Private” or “Validated” PowerShell Feed 

Navigate to “Feeds” and add a new PowerShell feed. Name it and select “Private” or “Validated.” Once you click, “Create Feed,” you can upload your PowerShell modules to your heart’s content.

Not sure how (or why) to create your own PowerShell modules? Check out this tutorial.

Step 2B: Create a “Public” PowerShell Feed

Navigate to “Feeds” and add a new PowerShell feed. Name it and select “Public/Open Source.”

Step 3B: Add a Connector to the PowerShell Gallery in Your “Public” Feed

ProGet will then prompt you to add a connector. You can either use the provided one or select your own, copied from the PowerShell Gallery.

This will populate the feed with PowerShell modules from the Gallery, appearing in ProGet as if they had been uploaded locally.

Now that you’ve set up ProGet to be your private PowerShell module repository, you can take things one step further by learning how to implement a package approval process to make sure your team is using approved PowerShell Gallery packages. Read our step-by-step guide to learn how to use approved PowerShell Gallery Packages in ProGet. 

It’s that easy! Take things to the next level by configuring security and access controls, vulnerability scanning, and more—all designed to keep your PowerShell modules both safe and accessible.