Install with PowerShell.exe

With PowerShell, there is an additional step. You must ensure Get-ExecutionPolicy is not Restricted. We suggest using Bypass to bypass the policy to get things installed or AllSigned for quite a bit more security.

Run Get-ExecutionPolicy. If it returns Restricted, then run Set-ExecutionPolicy AllSigned or Set-ExecutionPolicy Bypass -Scope Process.

Additional considerations

NOTE: Please inspect https://chocolatey.org/install.ps1 prior to running any of these scripts to ensure safety. We already know it's safe, but you should verify the security and contents of any script from the internet you are not familiar with. All of these scripts download a remote PowerShell script and execute it on your machine.

Install from PowerShell v3+

With PowerShell, there is an additional step or two. You must ensure Get-ExecutionPolicy is not Restricted. We suggest using Bypass to bypass the policy to get things installed or AllSigned for quite a bit more security.

Run Get-ExecutionPolicy. If it returns Restricted, then run Set-ExecutionPolicy AllSigned or Set-ExecutionPolicy Bypass.

Completely offline install

With completely offline use of Chocolatey, you want to ensure you remove the default community package source (choco source list followed by choco source remove -n chocolatey, or however you would do that with a configuration manager like Puppet).

Then you would run a script similar to the below to address that local install. If it is on a repository somewhere, you will need to enhance the below script to get that file (the Chocolatey Puppet provider install script shows that).

Install with Puppet

Here's an example of setting Chocolatey up with Puppet that sets up and configures Chocolatey, sets up an internal package repository, and shows setting up the licensed edition and ensuring some packages.

If you prefer to have the install.ps1 file already, comment out the download line in the batch file and download the install.ps1 from chocolatey.org and save it as install.ps1 next to the installChocolatey.cmd file.

Run installChocolatey.cmd from an elevated cmd.exe command prompt and it will install the latest version of Chocolatey. You can not run this from powershell.exe without making changes to your execution policy.

NOTE: To create and save a .cmd file, please use a text editor and nothing fancy like Microsoft Word or OneNote.

Install using NuGet Package Manager

When you have Visual Studio 2010+ and the NuGet extension installed (pre-installed on any newer versions of Visual Studio), you can simply type the following three commands and you will have Chocolatey installed on your machine.

Open a PowerShell command shell and navigate into the unzipped package's tools folder.

NOTE: Ensure PowerShell execution policy is set to at least bypass or remote signed (if you have issues, you may need to set it to Unrestricted).

Call & .\chocolateyInstall.ps1 to allow Chocolatey to install.

NOTE: This will not set Chocolatey as an installed package, so it may be a good idea to also call choco upgrade chocolatey -y and let it reinstall the same version, but at least it will be available for upgrades then.

Installing behind an explicit proxy

Installing to a different location

Create a machine level (user level will also work) environment variable named ChocolateyInstall and set it to the folder you want Chocolatey to install to prior to installation (this environment variable must be set globally or available to PowerShell- it is not enough to simply make it available to your current command prompt session).

Don't use "C:\Chocolatey" unless necessary.

Create the folder manually.

If you have already installed (and want to change the location after the fact):

Follow the above steps.

Install Chocolatey again.

Copy/Move over the items from the old lib/bin directory.

Delete your old install directory.

NOTE: There is one really important consideration when installing Chocolatey to a non-default location - Chocolatey only locks down the permissions to Admins when installed to the default location.
If you are installing to another location, you will need to handle this yourself.
This is due to alternative locations could have a range of permissions that should not be changed.
See Why does Chocolatey install where it does and https://github.com/chocolatey/choco/issues/398 for more details.

Installing with restricted TLS

NOTE: If your server is restricted to TLS 1.1+, you need to add additional logic to be able to download and install Chocolatey (this is not necessary when running Chocolatey normally as it does this automatically). If this is for organizational use, you should consider hosting the Chocolatey package internally and installing from there. Otherwise, please see this section.

It's possible that you are attempting to install from a server that needs to use TLS 1.1 or TLS 1.2 (has restricted the use of TLS 1.0 and SSL v3), you have some options.

Option 1

If you have the following:

PowerShell v3+

.NET Framework 4.5

You can just run the following instead of just the one-liner to get Chocolatey installed:

$securityProtocolSettingsOriginal = [System.Net.ServicePointManager]::SecurityProtocol
try {
# Set TLS 1.2 (3072), then TLS 1.1 (768), then TLS 1.0 (192), finally SSL 3.0 (48)
# Use integers because the enumeration values for TLS 1.2 and TLS 1.1 won't
# exist in .NET 4.0, even though they are addressable if .NET 4.5+ is
# installed (.NET 4.5 is an in-place upgrade).
[System.Net.ServicePointManager]::SecurityProtocol = 3072 -bor 768 -bor 192 -bor 48
} catch {
Write-Warning 'Unable to set PowerShell to use TLS 1.2 and TLS 1.1 due to old .NET Framework installed. If you see underlying connection closed or trust errors, you may need to do one or more of the following: (1) upgrade to .NET Framework 4.5 and PowerShell v3, (2) specify internal Chocolatey package location (set $env:chocolateyDownloadUrl prior to install or host the package internally), (3) use the Download + PowerShell method of install. See https://chocolatey.org/install for all install options.'
}
iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
[System.Net.ServicePointManager]::SecurityProtocol = $securityProtocolSettingsOriginal

Option 2

You need to download and unzip the Chocolatey package, then call the PowerShell install script from there. See the Download + PowerShell Method section below.

Non-Administrative install

NOTE: This option should be a last resort and is considered to be a more advanced scenario - most things you do on Windows require administrative rights, especially surrounding software management, so you are going to be limited even in packages you attempt to install. If you are using the community package repository, there are over 200 packages you can install from the community repository without administrative permission - see https://chocolatey.org/packages?q=id%3Aportable.

You must choose a different location than the default (see Installing to a different location above). The default is a more secure location that only administrators can update.

Follow that with the command line / PowerShell methods of installation.

Upgrading Chocolatey

Once installed, Chocolatey can be upgraded in exactly the same way as any other package that has been installed using Chocolatey. Simply use the command to upgrade to the latest stable release of Chocolatey:

I'm getting a 403 attempting to install

Why isn't there an MSI?

Chocolatey was born out of providing automation for Windows and doing that with packages, packages that could surround an installer but didn't necessarily need to. The Chocolatey install scripts use the Chocolatey package (a nupkg file itself) to be installed and upgraded as just another package. This means Chocolatey is "eating its own dogfood" and it is unlikely we'd offer it as an MSI (native installer)as it would fly a bit in the face of what Chocolatey represents (although it is something that we would not rule out).

The installation actually ensures a couple of things:

PowerShell is installed and is set up properly.

PowerShell is a requirement for using Chocolatey, not just for install. It is what drives the package installation process in most cases. Every package can have binaries and/or installation/uninstallation scripts (written in PowerShell). Chocolatey is the framework and each package gets to define how it is installed, upgraded, and uninstalled. It's an extremely flexible framework that has been proven to meet the insanity that is the Windows software installation ecosystem. That flexibility would not be easily achieved without PowerShell.

We do recognize there are a few organizations that disable PowerShell, so it's very likely in the future our Business Edition will meet that need. PowerShell is a staple of Windows automation, so it is not the norm for an organization in this day and age to disable PowerShell.

Having an install process that uses PowerShell helps you determine quickly if Chocolatey will be able to be used in your environment.

You are open to doing things in a slightly different way, e.g. working with packages as opposed to installers.

You are open to the concept of using packages. Some folks might say this means we are asking folks to learn to 'do things "our way" because we know better'. It's less about "knowing better" and more about learning that Chocolatey does things in a slightly different way. It does that because the world of software is not just installers. Software goes beyond Programs and Features and a system that can track all of that also needs to as well. Package management is not a new concept in the world of software, perhaps just newer to Windows. If folks are not open to that, then they are probably not going to be open to Chocolatey. And that's completely fine. Chocolatey is not for everyone. We may eventually get to more of a masses approach. Right now we are targeting a specific type of audience - those that are looking for better ways to manage software on Windows and open to looking for the best process of doing that.