Host Packages Internally
Host Packages Internally
NOTE
Refer to the Chocolatey for Business Organizational Deployment Guide in tandem with this article.
The Rationale Behind Hosting Your Own Packages
Since its inception in 2011, Chocolatey has been able to work with packages from one or more sources, and Chocolatey comes with a default package repository configured as a source - the Chocolatey Community Repository. However, being publicly available and subject to distribution rights, it has a failure point: it’s not 100% reliable (most packages can’t contain software and must download it at runtime).
The answer is to use an internal package repository; hosted on your own network and filled with your own packages, or packages internalized by Chocolatey. This allows for testing packages locally before distributing them across your entire environment.
Organizations looking to use Chocolatey should review the following topics to learn more:
- Chocolatey Community Repository - organizational use
- Security and the Chocolatey Community Repository
Recommendations
The Chocolatey Support team’s current suggestion for organizational use is Inedo ProGet. ProGet is a free and robust repository solution that offers Chocolatey-specific feeds. For other commercially supported repository solutions, see commercially supported options.
Known Hosting Options
Some of these options also work from a non-Windows hosting perspective. See Non-Windows Hosting.
- Inedo ProGet - ProGet gives you a free on-premises option. The paid version also offers feed replication and package cleanup.
- Sonatype Nexus - Nexus has a free Community Edition, but it has strict usage limits which makes Community Edition unusable at scale.
- JFrog Artifactory Pro - a paid-only option that offers a lot of features. More information here
- MyGet - a paid-only solution offering on-premises and cloud options.
- Cloudsmith - free for individuals but paid for teams and organizations. Cloudsmith also offers Chocolatey-specific feeds.
- File Share\UNC share (below) - While this is perhaps the easiest to setup for testing, it is not recommended for organizations and is not supported.
- SCCM Distribution Points (when used as a file share) - this is also not recommended and is not supported.
Package Version Immutability
A package version is immutable on some sources; meaning that everybody’s version 1.0.1 of a particular package is the same. You don’t need to worry about this when updating with newer versions of packages, because each Chocolatey package (the compiled .nupkg) has the unique version in the name (e.g bob.1.0.0.nupkg vs bob.1.0.1.nupkg ).
Package immutability is usually desired because you know that everyone on v1.0.0 of a Chocolatey package has exactly the same code, which simplifies administration.
Without immutability, there’s no guarantee that the version of a package installed is the same as the version of that package at the source.
Local Folder / UNC Share (CIFS)
WARNING
Local Folder / UNC Shares are not supported by the Chocolatey Support team.
Perhaps the easiest to set up for testing scenarios, a local folder is a strong contender when you need a quick source for packages.
If you’re creating large packages, see Package Reducer for keeping used space down on client machines.
Local Folder Share Setup
Set your permissions appropriately and put packages in the folder (no subfolders). It’s that easy; you’re already done. You should consider the structure and permissions listed below.
Local Folder Or Share Structure
The structure should just be a flat folder or share (no subfolders) with Chocolatey packages (.nupkgs) inside that folder. This occurs when using choco push to push packages to that location. See the Push command for more information.
Local Folder or Share Permissions
File share permissions can be interesting to configure. If you’re using machine accounts like LocalSystem, they may not have access to network resources. However, there is a way to handle that in domain environments. You would need to grant access to machines or anonymous access to the share (Everyone Read is likely not enough).
A great read on your options can be found at the following Stack Exchange links:
A way to do this with LocalSystem:
- Create a global group on the domain.
- Add all machines to the newly created global group.
- Add this group to the share permissions with “Read” Access.
- Add this group to the NTFS permissions with “Read” Access.
Commercially Supported Options
NOTE
The options below are commercially supported by the Chocolatey Support team for licensed customers. You must have a paid version of Chocolatey to qualify for commercial support.
Commercial support for repository solutions extends only to Chocolatey and its configuration. If an issue is related to the repository solution itself and not related to Chocolatey, reaching out to the repository vendor for assistance will be required.
Non-Windows Hosting
WARNING
The options below are not supported by the Chocolatey Support team.
If you don’t want to host on Windows you have only the following options (from least advanced to most advanced - these options typically also work on Windows):
- CIFS share
- Express Chocolatey Server - Open source, OS-agnostic, read-only, does not require .NET or Windows, based on Express
- TeamCity - contains built-in simple server
- Hazel - Simple server built in Rust
- Cloudsmith - see Cloudsmith Chocolatey Repository
- Artifactory Pro - see Artifactory NuGet Repositories
- Sonatype Nexus - see Nexus NuGet Repositories