Chocolatey on a Windows Server VPS: install and maintain your software from the command line

On a fresh Windows VPS, installing Git, 7-Zip, the Sysinternals tools and every dependency by hand takes time and produces servers that are slightly different from one another. Chocolatey lets you describe those programs, install them silently, identify the outdated ones and replay the same baseline on another VPS.

The point is therefore not to memorise ten choco commands. The real subject is operations:

how to install Chocolatey without blindly running a downloaded script;
how to define a reproducible software state;
how to control updates and reboots;
how to know who wrote the package that will run PowerShell as administrator;
when to replace the community repository with an internal one;
what the paid editions actually bring.

Method, scope and limits

The procedures were verified on 31 August 2026 in the official documentation of Chocolatey CLI, the Chocolatey community repository, Chocolatey Software and Microsoft PowerShell.

Chocolatey CLI 2.x requires .NET Framework 4.8. The installer will try to install it if it is missing, but that operation may require a reboot. This guide targets supported Windows Server versions and a PowerShell console started as administrator.

A community package, its maintainer, its script or the URL of the underlying software can change after publication. For professional use, validate the exact version in a test environment and then publish it to a source you control. The prices and features quoted also change: check them on the official pages when you make your decision.

This guide does not replace the licences of the installed software, a vulnerability management policy, Windows Update, a backup or rebuild procedure, application qualification before updating, or your organisation's EDR, antivirus, proxy and firewall controls.

1. What Chocolatey manages and what it does not

Chocolatey is a package manager for Windows. A .nupkg package is an archive based on the NuGet format. It contains .nuspec metadata and may contain PowerShell scripts such as chocolateyInstall.ps1, chocolateyBeforeModify.ps1 or chocolateyUninstall.ps1.

A package can embed software where redistribution rights allow it, download an MSI, an EXE or an archive from the vendor's site, verify its checksum, launch the silent installation, create command shortcuts known as shims, declare dependencies and perform configuration steps.

This distinction matters:

Item	Responsible party
the software itself	the software vendor
the community Chocolatey package	one or more maintainers, sometimes unrelated to the vendor
community repository and moderation	Chocolatey Software and its validation services
the decision to allow the package	your organisation
internal repository and version promotion	your operations team

Chocolatey primarily manages the state of its own packages. With the Open Source edition, software updated or removed outside Chocolatey can create a gap between the Windows state and the package state. Licensed editions offer synchronisation with Programs and Features, but that feature does not remove the need to monitor the server's real state.

Chocolatey does not replace Windows Update

Use Windows Update for the operating system, Microsoft components and OS patches. Use Chocolatey for the software and tools you have chosen to manage as packages. A community package named after a Windows update must not become an automatic substitute for your Microsoft patching policy.

2. The trust model on a server

A Chocolatey installation combines several links:

the Chocolatey installation script;
the installed choco client;
the configured repository;
the package and its scripts;
the server the package may download the software from;
the vendor's installer;
the package's dependencies.

An HTTPS connection protects transport and authenticates the remote server through the certificate chain. It does not prove that a script matches your policy, nor that its behaviour will stay appropriate for your environment.

On a VPS, scripts generally run with administrator rights. A package can therefore modify services, the registry, environment variables, scheduled tasks and system files. Treat every source as a supplier of privileged code.

Three levels of use

Level	Source	Recommended management
personal testing	community repository	package review and one-off installation
small professional estate	internal repository, manual import	approved versions, manifest and change log
industrialised estate	test and production repositories, automation	internalisation, CI, testing, approval, audit and central deployment

3. Prepare the VPS

Connect over RDP or through your usual administration channel. If the VPS has just been delivered, start with our guide on getting started with your Windows VPS.

Before Chocolatey: install the Windows updates, reboot if needed, check the clock and DNS resolution, check outbound HTTPS access, open PowerShell as administrator, and take a precautionary snapshot if the platform allows it.

Initial collection:

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion,
        OsBuildNumber, OsArchitecture

$PSVersionTable |
    Format-List PSVersion, PSEdition, CLRVersion

Get-ExecutionPolicy -List

[System.Net.ServicePointManager]::SecurityProtocol

Test-NetConnection community.chocolatey.org -Port 443

A snapshot makes rolling back a system change easier, but it does not replace an external backup. A software update can also modify application data that reverting to the snapshot would roll back.

4. Install Chocolatey with the official method

The official installation page offers this PowerShell command:

Set-ExecutionPolicy Bypass -Scope Process -Force

[System.Net.ServicePointManager]::SecurityProtocol =
    [System.Net.ServicePointManager]::SecurityProtocol -bor 3072

iex ((New-Object System.Net.WebClient).DownloadString(
    "https://community.chocolatey.org/install.ps1"
))

The Process scope limits the execution policy change to the current console. The number 3072 corresponds to TLS 1.2 in the relevant .NET versions.

This command is official, but it downloads and then immediately runs code. Chocolatey itself asks you to inspect install.ps1 before using it. For a practice consistent with our hardening guide, which advises against running a downloaded script without reading it, prefer the following procedure.

5. Download the script, read it, then run it

Create a working directory and download the script without running it:

$BootstrapDirectory = "C:\Windows\Temp\Chocolatey-Bootstrap"
$InstallScript = Join-Path $BootstrapDirectory "install.ps1"
$InstallUri = "https://community.chocolatey.org/install.ps1"

New-Item -Path $BootstrapDirectory -ItemType Directory -Force |
    Out-Null

[System.Net.ServicePointManager]::SecurityProtocol =
    [System.Net.ServicePointManager]::SecurityProtocol -bor 3072

$DownloadParameters = @{
    Uri             = $InstallUri
    UseBasicParsing = $true
    OutFile         = $InstallScript
}

Invoke-WebRequest @DownloadParameters

Check the file:

Get-Item $InstallScript |
    Format-List FullName, Length, CreationTimeUtc,
        LastWriteTimeUtc

Get-FileHash -Path $InstallScript -Algorithm SHA256

Get-Content -Path $InstallScript

You can also open it in Notepad:

notepad.exe $InstallScript

What to look for during the review

Check in particular the URL the Chocolatey package is downloaded from, the environment variables consulted, the paths created, changes to PATH, any secondary downloads or executables, dynamic PowerShell calls, and the absence of any unexpected destination or command.

The recorded SHA-256 checksum proves that the same file was reviewed and executed. It does not authenticate the script on its own until it is compared with a value published through an independent channel. HTTPS verification and content review therefore remain necessary.

After internal validation, run the local file:

Set-ExecutionPolicy Bypass -Scope Process -Force
& $InstallScript

if (-not (Get-Command choco -ErrorAction SilentlyContinue)) {
    $env:Path += ";$env:ProgramData\chocolatey\bin"
}

choco --version

The machine's permanent execution policy has not been lowered. Closing the console removes the Bypass set at Process level.

For professional automation

Do not silently re-download the current install.ps1 every time you create a server. After validation:

archive the approved script or the official MSI in your artefact repository;
record its SHA-256 and the Chocolatey version;
point the bootstrap at that internal copy;
validate a new version before replacing the old one;
remove the community source from production servers if it is not needed.

Chocolatey has also offered an MSI since version 2.0.0. The documentation specifies that this MSI is for bootstrapping: it installs Chocolatey, but it cannot upgrade or uninstall the client.

6. Check the installation

The default path is C:\ProgramData\chocolatey. Chocolatey states that permissions there are hardened for administrators. If you choose another location with ChocolateyInstall, the documentation asks you to manage the ACLs yourself.

choco --version
choco source list
choco config list
choco feature list

Get-Command choco |
    Format-List Name, Source, Version

Get-ChildItem $env:ChocolateyInstall

Get-Acl $env:ChocolateyInstall |
    Format-List Owner, AccessToString

Check at least:

Check	Expected result
`choco --version`	a version number, with no error
resolved command	binary under the Chocolatey directory
installation folder	writable only by the intended identities
community source	present only if your policy allows it
log	`C:\ProgramData\chocolatey\logs\chocolatey.log`

Do not make C:\ProgramData\chocolatey writable by a standard user: they could replace a shim, a script or a package that is later run with elevated privileges. Our guide on configuring the Windows Server firewall on a VPS complements this hardening on the network side.

7. Understand who publishes community packages

The community.chocolatey.org repository contains packages created by community members. The package maintainer is not necessarily the software vendor. The community repository FAQ explicitly distinguishes package support, provided by its maintainers, from software support, provided by its vendor.

Since October 2014, every version of every submitted package goes through a moderation process before going live. According to the Chocolatey security documentation and the moderation documentation, that process can include automated quality validation, an install and uninstall verification, a VirusTotal scan, human review for packages that are not in trusted status, and provenance and checksum checks on binaries.

A "trusted" package can be approved after the automated checks without further human review if nothing is flagged. Moderation reduces risk; it does not turn a community repository into a source under your control.

Chocolatey also states that only en-US installers are tested by default by its package scanner. A package can work in the verification environment and fail with another language, another architecture, a proxy, a pending reboot or a particular server configuration.

Check a package before installing it

Start with the metadata:

choco info 7zip
choco info git
choco info sysinternals

On the package page, check the identity of the maintainers, the link to the package source code, the validation, verification and scan status, the version history, the Files section, the chocolateyInstall.ps1 file, the URLs downloaded, the declared checksums, the dependencies, and the silent parameters and arguments.

The official FAQ explains that the .nupkg file can be downloaded, renamed to .zip and extracted for inspection. Examine the exact package, not just the main branch of its source repository: the branch may have changed since the version was published.

What VirusTotal does not guarantee

A clean result is not proof of safety. It does not validate the PowerShell logic, the maintainer's intent, licence compliance or the future behaviour of a remote URL. The runtime malware protection in the Pro and Business editions covers files downloaded from an external source during installation; Chocolatey specifies that binaries embedded directly in a package are not scanned by that feature at that point.

8. Install tools without turning the server into a workstation

On a server, every piece of software increases the maintenance surface. Only install the tools the VPS role requires.

An explicit installation example, checking each result:

$PackageIds = @(
    "7zip",
    "git",
    "sysinternals"
)

foreach ($PackageId in $PackageIds) {
    & choco install $PackageId --yes --no-progress
    $InstallCode = $LASTEXITCODE

    if ($InstallCode -notin @(0, 1641, 3010)) {
        throw "Installation of $PackageId failed: code $InstallCode"
    }

    if ($InstallCode -in @(1641, 3010)) {
        Write-Warning "$PackageId installed; reboot required."
    }
}

choco list

Codes 1641 and 3010 respectively mean success with a reboot initiated and success with a reboot required. Chocolatey in fact defines 0, 1605, 1614, 1641 and 3010 as valid exit codes. A script that treats every non-zero code as a failure would therefore wrongly report some installations as errors.

Do not use --force by default. The Chocolatey commands documentation explains that this option bypasses protective behaviours and advises against it in ordinary scripts.

9. Make the installation reproducible

A series of commands copied from a PowerShell history is not yet a reproducible configuration. You need to keep the exact package identifier, the validated version, the authorised source, the package parameters, the arguments passed to the installer, the return code, the reboot requirement and a functional test after installation.

Export the state of a reference VPS

The choco export command creates a packages.config file. On an already validated reference machine:

$ManifestDirectory = "C:\Ops\Chocolatey"
$ManifestPath = Join-Path $ManifestDirectory "packages.config"

New-Item -Path $ManifestDirectory -ItemType Directory -Force |
    Out-Null

choco export $ManifestPath --include-version-numbers

Get-Content $ManifestPath

Put that manifest into your configuration repository with a code review, a change number, the validation date, the test environment and the matching internal source.

Do not treat the export as a complete backup. It does not necessarily capture each installation's parameters, application settings, secrets, data, or software installed outside Chocolatey.

Replay the manifest

On a new VPS:

$ManifestPath = "C:\Ops\Chocolatey\packages.config"
$ApprovedSource = "internal-production"

if (-not (Test-Path $ManifestPath)) {
    throw "Chocolatey manifest not found: $ManifestPath"
}

$Arguments = @(
    "install",
    $ManifestPath,
    "--source=$ApprovedSource",
    "--yes",
    "--no-progress"
)

& choco @Arguments
$InstallCode = $LASTEXITCODE

if ($InstallCode -notin @(0, 1641, 3010)) {
    throw "Software bootstrap failed: code $InstallCode"
}

Do not confuse frozen versions with maintenance

A pinned version makes a rebuild predictable, but it can also preserve a vulnerability. The right cycle is:

detect a new version;
import the package and its resources;
review the changes;
test installation, upgrade and reboot;
promote the version;
update the manifest;
deploy in waves;
keep the previous version during the rollback window.

10. Update software without a blind "upgrade all"

Show outdated packages:

choco outdated

Update a specific package after validation:

choco upgrade git -y --no-progress
$UpgradeCode = $LASTEXITCODE

if ($UpgradeCode -notin @(0, 1641, 3010)) {
    throw "Git upgrade failed: code $UpgradeCode"
}

Update to an approved version:

$ApprovedVersion = "VALIDATED_VERSION"
$UpgradeArguments = @(
    "upgrade",
    "git",
    "--version=$ApprovedVersion",
    "--source=internal-production",
    "--yes",
    "--no-progress"
)

& choco @UpgradeArguments

The value VALIDATED_VERSION is deliberately a placeholder: replace it with the version you have actually qualified and that exists in your repository.

Why to avoid an automatic global upgrade in production

This command exists:

choco upgrade all -y

It can be acceptable on a test machine or a non-critical workstation. On a production VPS, it can simultaneously update a runtime, a tool used by a service, a dependency and Chocolatey itself. If something fails, the source of the regression becomes harder to isolate.

Prefer a maintenance window, a precautionary snapshot, a list of approved versions, updates in coherent batches, application tests, a controlled reboot and a progressive rollout across servers.

The Chocolatey documentation also notes that a global upgrade can leave dependencies in an inconsistent state if part of the chain fails. In that case, start with the package or dependency explicitly named in the error.

Temporarily pin a package

choco pin add --name=git
choco pin list
choco pin remove --name=git

A pin is a temporary measure, not a security strategy. Attach a reason, a ticket, an owner and a review date to it.

11. Produce an update report without changing the server

For simple monitoring, enable enhanced exit codes:

choco feature enable --name=useEnhancedExitCodes

With that feature on, choco outdated returns:

Code	Meaning
0	no outdated packages
2	at least one outdated package
1 or -1	an error occurred

An audit script, with no installation:

$AuditDirectory = "C:\Ops\Chocolatey\Reports"
$Timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
$ReportPath = Join-Path $AuditDirectory "outdated-$Timestamp.txt"

New-Item -Path $AuditDirectory -ItemType Directory -Force |
    Out-Null

$Output = & choco outdated --limit-output 2>&1
$ExitCode = $LASTEXITCODE

$Output | Set-Content -Path $ReportPath -Encoding UTF8

switch ($ExitCode) {
    0 {
        Write-Output "No Chocolatey updates detected."
    }
    2 {
        Write-Warning "Updates are available: $ReportPath"
    }
    default {
        throw "Chocolatey audit failed: code $ExitCode"
    }
}

Schedule this check with your monitoring tool, a GPO, a scheduler or a Windows task. Do not automatically turn this report into an upgrade all without validation.

12. Why an organisation should use its own repository

Chocolatey Software explicitly writes that an organisation should not use the community repository directly as a production source. Its automated internalisation guide gives three reasons:

trust: external creators and maintainers are not under the organisation's control;
stability: packages and downloads must remain available during operations;
control: testing, approval and publication should belong to the organisation.

A private repository also lets you keep the versions actually deployed, stop depending on a vendor URL that changed or disappeared, reduce the Internet domains allowed from the VPS, qualify a binary before distributing it, create your own configuration packages, operate in an isolated network, separate import, test and production, and tie each promotion to a review and a change record.

Recommended architecture

Stage	Function
community or vendor repository	external origin, never consumed directly by production
internalisation	retrieval of the package and its resources
Git repository	scripts, manifests, checksums and review history
Chocolatey test repository	installation on a representative server
checks	antivirus, signatures, checksums, functional tests and reboot
Chocolatey production repository	approved versions only
VPS	read access to the production repository

For clients, use a read-only identity. Reserve publishing rights for the CI system or a separate identity. Never place a publishing token in a VPS bootstrap script.

Compatible repositories

The Chocolatey documentation cites Inedo ProGet, Sonatype Nexus Repository, JFrog Artifactory, a compatible NuGet source and, in some cases, an internal file share.

The older Chocolatey.Server product is deprecated. Chocolatey recommends migrating to a third-party solution and names ProGet, Nexus or Artifactory. So do not start a new project around Chocolatey.Server.

Open Source or Business for the internal repository?

The Open Source edition can consume several sources, create packages and use a private repository. It also allows manual internalisation: download the package, retrieve the resources, edit the scripts, recompile and publish.

Chocolatey for Business automates that work with Package Internalizer: the client downloads the package and its external resources, rewrites the references and recompiles a package usable without Internet access. The feature saves time, but the decision to approve and test remains yours.

13. Configure an internal source

An example with a fictitious HTTPS source:

$SourceArguments = @(
    "source",
    "add",
    "--name=internal-production",
    "--source=https://packages.example.net/nuget/chocolatey/v2",
    "--priority=1"
)

& choco @SourceArguments
choco source list

A lower numeric priority is evaluated before a higher one. Always check the result with choco source list.

Once you have confirmed that the internal repository holds Chocolatey and every needed package, disable the community repository:

choco source disable --name=chocolatey
choco source list

For a fully isolated environment, the Chocolatey documentation recommends removing the community source:

choco source remove --name=chocolatey

Disabling is more easily reversible; removing prevents an uncontrolled re-enable from reintroducing the source. Choose according to your configuration management.

Authentication and secrets

Chocolatey supports username and password authentication as well as X.509 client certificates. The source add command encrypts the password in the configuration file, but a secret passed on a command line may be visible through other logging or inventory mechanisms.

Good practice: use a read-only technical account on the VPS, prefer a short-lived token or a client certificate if the repository supports it, retrieve the secret from a vault at deployment time, never place it in Git, in packages.config or in the template image, separate read and publish identities, and rotate secrets while testing their revocation.

14. Compare the editions without overselling them

Features and prices can change. The table below reflects the official Compare Chocolatey Editions and Pricing pages as consulted on 31 August 2026.

Edition	Intended audience	What it brings in this guide	Limit to know
Open Source	individuals and organisations	package management, package creation, multiple sources, private repository, global upgrade	internalisation and advanced governance to be built manually
Pro	an individual, named licence	Open Source features plus CDN cache, runtime malware protection, synchronisation and convenience features	personal, named licence; up to 8 personal machines
Business (C4B)	organisations	Package Internalizer, Central Management, auditing, self-service, full synchronisation and deployment features	cost per node, infrastructure and processes to operate

Prices listed on 31 August 2026

Open Source: free, with no machine limit;
Pro: 96 dollars per year, a personal named licence, up to 8 personal machines;
Business: from 18 dollars per licence per year;
the pricing page shows an annual Business subscription starting at 1,800 dollars per year, corresponding to a 100-node minimum at 18 dollars per node per year, with volume discounts beyond 500 nodes.

Check the official page at purchase time. Taxes, quotes, discounts, premium support and contract terms can change the real cost.

A sensible choice by size

Situation	Often sufficient choice
one or a few VPS, a team able to maintain its packages	Open Source with a private repository and manual import
strictly personal use	Open Source or Pro depending on the features wanted
company estate with frequent import of external packages	Business, worth evaluating for the Internalizer and auditing
need for self-service for non-administrator users	Business
need for a central compliance dashboard	Business, or a third-party management tool already in place

Business does not automatically make packages safe. It makes internalisation, central control and auditing easier. If the organisation already has a NuGet repository, a CI system, an EDR and a configuration tool, the Open Source edition can be enough for a small, properly operated scope.

15. A reproducible bootstrap script

The script below does not choose the software for you. It requires an existing manifest, an already configured Chocolatey source, an approved bootstrap URL and the expected SHA-256 checksum of the installation script.

In a mature production setup, BootstrapUri should point to your validated internal copy.

param(
    [Parameter(Mandatory = $true)]
    [string]$ManifestPath,

    [Parameter(Mandatory = $true)]
    [string]$SourceName,

    [Parameter(Mandatory = $true)]
    [string]$BootstrapUri,

    [Parameter(Mandatory = $true)]
    [ValidatePattern("^[A-Fa-f0-9]{64}$")]
    [string]$ExpectedBootstrapSha256
)

$ErrorActionPreference = "Stop"
$BootstrapDirectory = "C:\Windows\Temp\Chocolatey-Bootstrap"
$BootstrapPath = Join-Path $BootstrapDirectory "install.ps1"

if (-not (Test-Path $ManifestPath)) {
    throw "Manifest not found: $ManifestPath"
}

if (-not (Get-Command choco -ErrorAction SilentlyContinue)) {
    New-Item -Path $BootstrapDirectory -ItemType Directory -Force |
        Out-Null

    [System.Net.ServicePointManager]::SecurityProtocol =
        [System.Net.ServicePointManager]::SecurityProtocol -bor 3072

    $DownloadParameters = @{
        Uri             = $BootstrapUri
        UseBasicParsing = $true
        OutFile         = $BootstrapPath
    }

    Invoke-WebRequest @DownloadParameters

    $ActualHash = (
        Get-FileHash -Path $BootstrapPath -Algorithm SHA256
    ).Hash

    if ($ActualHash -ne $ExpectedBootstrapSha256) {
        throw "Invalid bootstrap checksum."
    }

    Set-ExecutionPolicy Bypass -Scope Process -Force
    & $BootstrapPath

    $env:Path += ";$env:ProgramData\chocolatey\bin"
}

$ConfiguredSources = & choco source list --limit-output
$SourcePattern = [regex]::Escape($SourceName)
$SourceFound = $ConfiguredSources |
    Where-Object { $_ -match $SourcePattern }

if (-not $SourceFound) {
    throw "Chocolatey source missing: $SourceName"
}

$InstallArguments = @(
    "install",
    $ManifestPath,
    "--source=$SourceName",
    "--yes",
    "--no-progress"
)

& choco @InstallArguments
$InstallCode = $LASTEXITCODE

if ($InstallCode -notin @(0, 1641, 3010)) {
    throw "Manifest installation failed: code $InstallCode"
}

& choco list

if ($InstallCode -in @(1641, 3010)) {
    Write-Warning "Bootstrap complete; reboot required."
}

The script is idempotent for installing the client: it does not reinstall Chocolatey if the command already exists. Reproducibility comes above all from the versioned manifest, the immutable internal source and the tests run after installation.

Recommended improvements for an estate: Authenticode signing of your bootstrap script, execution from a reference image or a configuration tool, sending the log to central storage, a unique deployment identifier, a disk space check, detection of an already pending reboot, an application test specific to the VPS role, and a lock preventing two simultaneous deployments.

16. Proxy, cache and network access

With the community repository, the VPS must reach community.chocolatey.org, the Chocolatey package infrastructure, and the domains of each vendor the scripts download binaries from.

That last dependency explains why allowing only the Chocolatey domain in a proxy is not always enough. An internal repository with internalised resources sharply reduces the number of external destinations.

Show the configuration:

choco config list
choco source list

Configure an explicit proxy without authentication:

choco config set --name=proxy --value=http://proxy.example.net:8080

Remove that setting:

choco config unset --name=proxy

For an authenticated proxy, do not write the password into a script or a ticket. Inject it from a vault and check which command-line traces your EDR collects.

Move the cache

Chocolatey uses a temporary directory for downloads by default. On a VPS with a small system disk, you can define a dedicated cache:

$CachePath = "D:\ChocolateyCache"

New-Item -Path $CachePath -ItemType Directory -Force |
    Out-Null

choco config set --name=cacheLocation --value=$CachePath
choco config get --name=cacheLocation

If the D: volume does not exist, choose a real path. Protect that directory against writes by unauthorised users and define a cleanup policy. A cache can contain executable installers; it is not just a harmless folder.

17. Logs, inventory and change evidence

The main log is normally here:

$ChocolateyLog = "C:\ProgramData\chocolatey\logs\chocolatey.log"

Get-Content $ChocolateyLog -Tail 200

To add a log specific to one operation:

$ChangeId = "CHG-2026-0001"
$OperationLog = "C:\Ops\Chocolatey\$ChangeId.log"
$Arguments = @(
    "upgrade",
    "git",
    "--yes",
    "--no-progress",
    "--log-file=$OperationLog"
)

& choco @Arguments

For every production change, keep:

Evidence	Example
state before	`choco list` and the software version
request	ticket or manifest commit
source	repository and approved version
command	arguments with no secrets
result	exit code and useful excerpts
reboot	required, performed and time
validation	service started, port or functional test
state after	new version and normal monitoring

Do not publish a raw log without reading it first: a URL, a username, a token or a sensitive path may appear in it.

18. Uninstall and roll back

Uninstall a package:

choco uninstall git -y --no-progress
$UninstallCode = $LASTEXITCODE

if ($UninstallCode -notin @(0, 1605, 1614, 1641, 3010)) {
    throw "Uninstall failed: code $UninstallCode"
}

Chocolatey documents code 1605 for software that is not present and 1614 for a product already uninstalled. The real outcome depends on the package script and the vendor's uninstaller.

Downgrading is not always a reliable rollback: an installer may refuse an earlier version, a configuration or data format may have migrated, a service may no longer accept the old binary, and a package may not provide a complete uninstall script.

For a critical VPS, prepare three levels:

reinstalling the previous package from the internal repository;
restoring compatible configurations and data;
rebuilding the VPS from the manifest and the backups.

The precautionary snapshot can shorten recovery time, but restoring it also cancels the writes made since it was taken. Define what must be backed up separately before the window, as described in our guide on backing up your Windows VPS.

19. Troubleshooting

The choco command is not recognised

Open a new console or refresh the session's PATH:

$env:Path += ";$env:ProgramData\chocolatey\bin"
Get-Command choco
choco --version

If a custom ChocolateyInstall path was used, adjust the value.

TLS error or closed connection

[System.Net.ServicePointManager]::SecurityProtocol =
    [System.Net.ServicePointManager]::SecurityProtocol -bor 3072

Test-NetConnection community.chocolatey.org -Port 443

Also check the date and time, DNS resolution, the proxy, TLS inspection, the certificate chain, outbound rules and the presence of .NET Framework 4.8.

Do not use an option that ignores certificate errors. Fix the trust chain or the proxy instead.

The execution policy blocks the bootstrap

Get-ExecutionPolicy -List
Set-ExecutionPolicy Bypass -Scope Process -Force

A GPO may still take precedence over this setting. In that case, use the deployment method your organisation allows, for example an approved MSI or a signed script.

Checksum mismatch

Do not ignore the error to "get the installation through". It can indicate a new version published under the same URL, a package not yet updated, an interception or intermediate cache, an incomplete download, or a resource genuinely different from the one you validated.

Compare the vendor's binary, the package script, the version and the checksum. Wait for a corrected version or internalise the approved binary.

The package is installed but the software is not

With the Open Source edition, the package state can diverge from Programs and Features if the software was changed outside Chocolatey.

choco list

Get-Package |
    Sort-Object Name |
    Select-Object Name, Version, ProviderName

Then check the service, the executable file or the registry key belonging to the software. Do not mark the server compliant on the basis of choco list output alone.

An internal source is configured but the community repository is still used

choco source list

Check the priorities, the availability of the internal package and the --source arguments. For closed production, explicitly disable or remove the community source.

An update requires a reboot

Do not immediately reboot a production server from a generic script. Report code 1641 or 3010, finish the checks you can, then reboot within the planned window and validate the services.

Where do I read the detailed error?

Get-Content "C:\ProgramData\chocolatey\logs\chocolatey.log" -Tail 300

Look first for the initial significant error and the dependent package it names. The warnings that follow may only be consequences.

20. Good practice on a Windows VPS

do not install tools the server role does not need;
use an administrator console only during the operation;
limit the Bypass policy to the process;
inspect the bootstrap before the first run;
inspect the scripts of new or sensitive packages;
use validated versions available in an internal repository;
separate the test and production repositories;
disable the community repository in production;
do not put repository secrets in Git;
treat reboot codes as successes still to be completed;
run outdated regularly, without blind automatic upgrades;
test the software's function after installation;
centralise logs and inventory;
review pins regularly;
test a full rebuild of the VPS.

Frequently asked questions

Is Chocolatey free for a company?

Yes. The official pricing page presents the Open Source edition as free, usable by organisations and with no machine limit. Business features are paid, but a private repository does not by itself require the Business edition.

Can Chocolatey Pro be deployed on a company's VPS?

No, according to the official pricing page. Pro is presented as a personal, named licence intended for the user's own machines, up to eight of them. An organisation should choose Open Source or evaluate Business.

Are community packages published by the software vendors?

Not necessarily. They are created by community maintainers, sometimes by the vendor itself, sometimes by a third party. Check each package's page.

Does moderation guarantee that a package is safe?

No. It adds validation, verification, scanning and review depending on the package's status. It reduces risk, but it does not replace internal approval, script review and testing of the exact version.

Why read install.ps1 if the URL is official?

Because the official command downloads and runs PowerShell with elevated privileges. Chocolatey itself recommends this inspection. It also lets you keep the checksum of the code you actually authorised.

Should I run choco upgrade all every night?

Not on a production server without tests. Use choco outdated to detect, qualify the versions, then deploy with a window, tests and reboot handling.

Is a packages.config enough to clone a VPS?

No. It describes the packages, but not every configuration, data set, secret, Windows role, firewall rule, certificate or scheduled task. Fold it into a wider configuration procedure.

Which internal repository should I choose?

Choose a NuGet-compatible product your team knows how to back up, update and monitor. Chocolatey names ProGet, Nexus and Artifactory. Chocolatey.Server is deprecated.

Does Chocolatey replace Winget?

The two can coexist, but multiplying package managers increases the risk of divergent state. Assign one owner per piece of software and avoid having the same program updated by Chocolatey, Winget and its own auto-updater without a clear rule.

Operations checklist

Windows Server and .NET Framework are up to date;
the console used is elevated;
the official script was downloaded before being run;
its contents and SHA-256 have been kept;
the execution policy was changed only at Process level;
the Chocolatey path has restrictive ACLs;
each package has an owner and a justification;
the maintainer, scripts, URLs and checksums have been reviewed;
versions are recorded in a manifest;
installation parameters are documented separately;
the production source is internal;
the community source is disabled or removed in production;
read and publish identities are separate;
secrets do not appear in the scripts;
codes 1641 and 3010 are handled;
updates are tested before deployment;
an outdated report is produced regularly;
logs are retained;
restore and rebuild have been tested.

Going further

This guide fits together with our other Windows articles: getting started with your Windows VPS for the initial setup, configuring the Windows Server firewall for network policy, installing IIS if the VPS hosts a website, installing Active Directory for a domain controller, and backing up your Windows VPS before any sensitive operation.