PowerShell
How to Publish PowerShell Modules to a Private Repository
There are many public ways to store your PowerShell modules (like the PowerShell Gallery and GitHub). However, these often aren’t acceptable for organizations that need extra privacy and security.
Creating your own private repository is like having your own, private PowerShell Gallery. Use ProGet to easily create and manage your private PowerShell repositories in just a few minutes.
ProGet’s “feeds” allow you to safely store and share PowerShell modules with all members of your organization without the risks associated with a public repository.

Creating a PowerShell Module Repository in ProGet
Repositories in ProGet are called feeds. A feed is like a private “app store” for your own applications and components. Feeds are used to store packages, container images, and other assets. ProGet users can easily see the feed’s content and download what they need.
To create a PowerShell module feed in ProGet:
- Start off by creating a new feed by clicking on Feeds > Create New Feed
- Choose “PowerShell Modules” and give it a name and optional description.
- Specify the usage for this feed. We’ll be using “Private/Internal packages.”
- Click on “Create New Feed”
- And that’s it for creating your own, private PowerShell module repository!
Create a PowerShell Module
Modules combine several PowerShell functions into a single reusable and easily sharable resource. You can put lots of files such as: .dlls and tools in a module. But this is the bare minimum – a .psm1 file.
For demonstration purposes, we’ll combine two functions: “Get-Foobar” and “Set-Foobar” into a single simple PowerShell Module, “Foobar.psm1” and save it to “C:\Foobar”.
function Get-Foobar {
<#
.SYNOPSIS
Take the inputs for two variables $Foo and $Bar. THen return $Foo$Bar
.PARAMETER Foo
Foo
.PARAMETER Bar
Bar
#>
param ([String]$Foo = "Foo", [String]$Bar = "Bar")
return "$Foo$Bar"
}
function Set-Foobar {
<#
.SYNOPSIS
Take the inputs for two variables $Foo and $Bar. Then return $Foo$Bar
.PARAMETER Foo
Foo
.PARAMETER Bar
Bar
#>
param ([String]$Foo = "Foo", [String]$Bar = "Bar")
Write-Debug "$Foo$Bar"
}
Create PowerShell Module Manifests
A module manifest is a PowerShell data file (.psd1) that, is simply an “about” file for your module that contains information about the module, including the version number, copyright, exported variables, etc.
Note: Module manifests are required for publishing modules to a repository.
You don’t need to write the entire document; PowerShell will do most of the heavy lifting for you. However, you need to ensure that the Author and Description within the document are defined. Parameters can and should be used; these are an easy way to create manifests and to make sure all relevant information is present.
To create a module manifest, open PowerShell and type:
New-ModuleManifest -Path «target directory for manifest» -Author «script author's name» -Description «"description for what the module does"» -PassThru
For our example, we’ll type:
New-ModuleManifest -Path «C:\Foobar\Foobar.psd1» -Author Inedo -Description "Contains functions that will write Foobar to the console and debug" -PassThru
Foobar.psd1 will now be in C:\Foobar.
Note: -PassThru is optional but will write the manifest to the console.
You can get a full list of parameters from Microsoft.
Publish your Module to a Private Repository / Feed
Adding a PowerShell Module to a feed will allow you to securely share it with your entire organization.
Create API Key in ProGet (Optional)
The first step in this process is to create an API Key that allows your PowerShell to connect to your ProGet instance.
For more information on how to create a new API key please refer to the API Access and API Keys Inedo ProGet Documentation.
Note: Instead of creating an API key in ProGet, you can alternatively use username: password (or Admin:Admin in our case) for the NuGetAPIKey parameter.
Import PowerShellGet Module
PowerShellGet is a module that enables publishing modules to a repository, as well as import them from a repository. It is installed by default but running the command will ensure that the module is up to date.
To do this in PowerShell, enter:
Import-Module PowerShellGet
Register target feed
By default, PowerShell will try to publish to and pull modules from the PowerShell Gallery, Microsoft’s public PowerShell module repository. Registering a new repository will shift the target from powershellgallery.com to that new repository.
Use the cmdlet “Register-PSRepository” to designate a new target repository.
You’ll also need to use the following parameters to publish to your ProGet PowerShell repository/feed.
-Name | Name of the target feed |
-SourceLocation | The location path of your target feed |
-PublishLocation | The location path you want to publish your module to (Should be the same as -SourceLocation) |
For our example:
Register-PSRepository -Name MyPowerShell -SourceLocation «host-name»/nuget/MyPowerShell/ -PublishLocation «host-name»/nuget/MyPowerShell
Publish Module to Feed
To publish the module, use the cmdlet “Publish-Module” in combination with the following parameters:
-Path | The location of the target module on your system |
-NuGetApiKey | The API key you are using to connect your PowerShell to ProGet. |
-Repository | The repository (feed) you are publishing your module too |
–verbose | Optional but displays additional information that can help you identify errors if any occur |
In our example we’ll use:
Publish-Module -Path c:\Foobar -NuGetApiKey Admin:Admin -Repository MyPowerShell -verbose
“Foobar” will now appear in your ProGet feed.
Note: If PowerShell displays a message saying “NuGet.exe is required to continue…”, please press “y” to install the service. This is required for PowerShell to publish modules.
Installing Modules from Your Feed
To use the module in your ProGet feed on the server/computer you are using, you must first download and install the module to the target system.
Start by opening PowerShell and registering the feed from which you want to download the module. As with publishing, this is necessary to set a custom location instead of the main PowerShell Gallery.
Register Feed For Downloads
Use Register-PSRepository in combination with the following parameters:
-Name | The name of the feed you want to download the module from |
-SourceLocation | The location path of the feed |
Note: ProGet will display the command to use under Usage Instruction in “Feeds/«feed-name»/«module-name»/ Repository.”
For this example, we’ll use:
Register-PSRepository -Name «MyPowerShell» -SourceLocation «host-name»/nuget/«MyPowerShell»/
Note: If you get an error message saying that “«feed-name» exists,” you can run Unregister-PackageSource -Name «feed-name», and then try registering the new feed again.
Download and Install Modules from Your Feed
Use Install-Module with the following parameters:
-Name | Name of the module you want to download |
-RequiredVersion | version of the module you want to download as specified in the module manifest. Note that ProGet will keep a copy of versions of your module as you update it |
-Repository | Name of the feed you are downloading the module from |
Note: ProGet will display the command to use under Usage Instruction in “Feeds/«Feed Name»/«Module Name»/ Module.
We’ll use the following in our example:
Install-Module -Name "Foobar" -RequiredVersion "1.0" -Repository MyPowerShell
The Future of Your Modules
Modules combine several PowerShell functions into a single reusable and easily sharable file.
By utilizing ProGet’s feeds, you can safely store and share PowerShell modules with all members of your organization without the risks associated with a public repository.
ProGet offers seamless integration with PowerShell and does not require any additional software beyond the default modules required for publishing files to the PowerShell Gallery. We even have a step by step guide that walks you through how to setup a ProGet feed to use only approved PowerShell Gallery packages.
Read more about Version Control Best Practices and how to use ProGet to help with versioning and repackaging of your PowerShell modules.