Publishing Modules¶

Once you’ve built a PowerShell module, the next step is making it available to others—your team, your organization, or the broader PowerShell community. Publishing a module transforms it from a local tool into a distributable package that can be installed, updated, and version‑controlled using PowerShellGet.

This section explains how to publish a module to:

• A private repository (internal use)
• The PowerShell Gallery (public distribution)

Both processes use the same core concepts, but private repositories give you full control over access, versioning, and security.

1. Understanding PowerShell Repositories¶

A PowerShell repository is a package source that stores modules in a structured format. PowerShellGet interacts with repositories using commands like:

• Find-Module
• Install-Module
• Publish-Module
• Update-Module

There are two main types:

1.1. PowerShell Gallery (public)¶

• Accessible to everyone
• Requires a free account
• Ideal for open‑source modules

1.2. Private repositories¶

• Hosted internally
• Can be file shares, NuGet servers, Azure Artifacts, or Nexus/Artifactory
• Ideal for enterprise automation

2. Preparing Your Module for Publishing¶

Before publishing, your module must:

2.1. Have a manifest (.psd1)¶

Created with:

New-ModuleManifest -Path .\MyModule\MyModule.psd1 -RootModule MyModule.psm1 -ModuleVersion "1.0.0"

2.2. Follow the correct folder structure¶

MyModule
│
├── MyModule.psm1
└── MyModule.psd1

2.3. Have a version number¶

Increment the version for every release.

2.4. Export only intended functions¶

Ensure your manifest or .psm1 file defines:

FunctionsToExport = @("Get-Thing","Set-Thing")

2.5. Include comment‑based help¶

Professional modules must be self‑documenting.

3. Publishing to a Private Repository¶

Private repositories are common in enterprise environments. They allow you to distribute internal automation securely.

You can use:

• A file share
• A NuGet server
• Azure Artifacts
• JFrog Artifactory
• Sonatype Nexus

The process is the same regardless of backend.

3.1 Register the Private Repository¶

Before publishing, PowerShell must know where the repository is.

Example: registering a file‑share repository¶

Register-PSRepository `
    -Name "InternalRepo" `
    -SourceLocation "\\Server\PSRepo" `
    -PublishLocation "\\Server\PSRepo" `
    -InstallationPolicy Trusted

Example: registering a NuGet‑based repository¶

Register-PSRepository `
    -Name "InternalNuGet" `
    -SourceLocation "https://nuget.contoso.com/api/v2" `
    -PublishLocation "https://nuget.contoso.com/api/v2/package" `
    -InstallationPolicy Trusted

3.2 Publish the Module¶

Once registered:

Publish-Module -Name "MyModule" -Repository "InternalRepo"

If your repository requires authentication:

$cred = Get-Credential
Publish-Module -Name "MyModule" -Repository "InternalRepo" -Credential $cred

PowerShell packages the module into a .nupkg file and uploads it.

3.3 Installing from the Private Repository¶

Users can now install your module with:

Install-Module -Name "MyModule" -Repository "InternalRepo"

Or update it:

Update-Module -Name "MyModule"

This gives your organization a clean, versioned distribution pipeline.

4. Publishing to the PowerShell Gallery¶

The PowerShell Gallery is the public repository for PowerShell modules. Publishing here makes your module available to the entire world.

4.1 Create a PowerShell Gallery Account¶

Go to:

https://www.powershellgallery.com/

Sign in with a Microsoft account and create an API key.

4.2 Register the Gallery as a Repository¶

PowerShell Gallery is already registered by default as PSGallery.

You can verify:

Get-PSRepository

4.3 Publish the Module¶

Use your API key:

Publish-Module -Name "MyModule" -Repository "PSGallery" -NuGetApiKey "YOUR-API-KEY"

PowerShell uploads the module and makes it publicly available.

4.4 Updating the Module¶

Increment the version in your .psd1 file, then republish:

Publish-Module -Name "MyModule" -Repository "PSGallery" -NuGetApiKey "YOUR-API-KEY"

The Gallery automatically tracks versions.

5. Best Practices for Publishing¶

5.1. Always increment the version number¶

Use semantic versioning:

• 1.0.0 — initial release
• 1.1.0 — new features
• 1.1.1 — bug fixes

5.2. Include complete comment‑based help¶

Modules without documentation are not professional.

5.3. Include tests (Pester)¶

Especially for enterprise modules.

5.4. Use a clean folder structure¶

Public/private separation improves maintainability.

5.5. Sign your scripts¶

Required in many organizations.

5.6. Avoid breaking changes¶

If unavoidable, increment the major version.

6. Summary¶

Publishing a module—whether internally or publicly—turns your code into a reusable, versioned, and professionally distributed package. The process involves:

• Preparing the module with a manifest and exports
• Registering a repository
• Publishing with Publish-Module
• Installing and updating with PowerShellGet

Private repositories support secure enterprise automation, while the PowerShell Gallery enables global distribution.

Mastering module publishing is a key milestone in becoming a professional PowerShell developer.