Windows31 agosto 2026 29 visualizzazioni

Chocolatey su un VPS Windows Server: installare e mantenere il software da riga di comando

Chocolatey su un VPS Windows Server: installare e mantenere il software da riga di comando

Su un VPS Windows nuovo, installare a mano Git, 7-Zip, gli strumenti Sysinternals e ogni dipendenza richiede tempo e produce server leggermente diversi tra loro. Chocolatey consente di descrivere quei programmi, installarli in modo silenzioso, individuare quelli obsoleti e riprodurre la stessa base su un altro VPS.

Il punto non è quindi memorizzare dieci comandi choco. Il vero tema è l'esercizio:

  • come installare Chocolatey senza eseguire alla cieca uno script scaricato;
  • come definire uno stato software riproducibile;
  • come controllare aggiornamenti e riavvii;
  • come sapere chi ha creato il pacchetto che eseguirà PowerShell come amministratore;
  • quando sostituire il repository comunitario con uno interno;
  • che cosa portano davvero le edizioni a pagamento.

Metodo, perimetro e limiti

Le procedure sono state verificate il 31 agosto 2026 nella documentazione ufficiale di Chocolatey CLI, del repository comunitario di Chocolatey, di Chocolatey Software e di Microsoft PowerShell.

Chocolatey CLI 2.x richiede .NET Framework 4.8. Il programma di installazione tenta di installarlo se manca, ma quell'operazione può richiedere un riavvio. Questa guida si rivolge a versioni supportate di Windows Server e a una console PowerShell avviata come amministratore.

Un pacchetto comunitario, il suo manutentore, il suo script o l'URL del software sottostante possono cambiare dopo la pubblicazione. Per un uso professionale, convalidate la versione esatta in un ambiente di prova e pubblicatela poi in una sorgente sotto il vostro controllo. Anche i prezzi e le funzioni citati cambiano: verificateli sulle pagine ufficiali al momento della decisione.

Questa guida non sostituisce le licenze del software installato, una politica di gestione delle vulnerabilità, Windows Update, un backup o una procedura di ricostruzione, la qualificazione applicativa prima di un aggiornamento, né i controlli EDR, antivirus, proxy e firewall della vostra organizzazione.

1. Che cosa gestisce Chocolatey e che cosa no

Chocolatey è un gestore di pacchetti per Windows. Un pacchetto .nupkg è un archivio basato sul formato NuGet. Contiene metadati .nuspec e può contenere script PowerShell come chocolateyInstall.ps1, chocolateyBeforeModify.ps1 o chocolateyUninstall.ps1.

Un pacchetto può incorporare il software se i diritti di ridistribuzione lo consentono, scaricare un MSI, un EXE o un archivio dal sito del produttore, verificarne il checksum, avviare l'installazione silenziosa, creare scorciatoie di comando dette shim, dichiarare dipendenze ed eseguire operazioni di configurazione.

Questa distinzione è essenziale:

ElementoResponsabile
il software vero e proprioil produttore del software
il pacchetto Chocolatey comunitariouno o più manutentori, talvolta estranei al produttore
repository comunitario e moderazioneChocolatey Software e i suoi servizi di convalida
decisione di autorizzare il pacchettola vostra organizzazione
repository interno e promozione delle versioniil vostro team operativo

Chocolatey gestisce anzitutto lo stato dei propri pacchetti. Con l'edizione Open Source, un software aggiornato o rimosso al di fuori di Chocolatey può creare uno scarto tra lo stato di Windows e quello del pacchetto. Le edizioni con licenza offrono una sincronizzazione con Programmi e funzionalità, ma quella funzione non esime dal sorvegliare lo stato reale del server.

Chocolatey non sostituisce Windows Update

Usate Windows Update per il sistema, i componenti Microsoft e le correzioni del sistema operativo. Usate Chocolatey per il software e gli strumenti che avete scelto di gestire come pacchetti. Un pacchetto comunitario che porta il nome di un aggiornamento di Windows non deve diventare un sostituto automatico della vostra politica di patch Microsoft.

2. Modello di fiducia su un server

Un'installazione di Chocolatey combina più anelli:

  1. lo script di installazione di Chocolatey;
  2. il client choco installato;
  3. il repository configurato;
  4. il pacchetto e i suoi script;
  5. il server da cui il pacchetto eventualmente scarica il software;
  6. il programma di installazione del produttore;
  7. le dipendenze del pacchetto.

Una connessione HTTPS protegge il trasporto e autentica il server remoto secondo la catena di certificati. Non dimostra che uno script rispetti la vostra politica né che il suo comportamento resti adatto al vostro ambiente.

Su un VPS gli script vengono eseguiti di norma con diritti di amministratore. Un pacchetto può quindi modificare servizi, registro di sistema, variabili d'ambiente, attività pianificate e file di sistema. Trattate ogni sorgente come un fornitore di codice privilegiato.

Tre livelli d'uso

LivelloSorgenteGestione consigliata
prova personalerepository comunitariorevisione del pacchetto e installazione occasionale
piccolo parco professionalerepository interno, import manualeversioni approvate, manifesto e registro delle modifiche
parco industrializzatorepository di test e produzione, automazioneinternalizzazione, CI, test, approvazione, audit e distribuzione centrale

3. Preparare il VPS

Collegatevi via RDP o tramite il vostro canale di amministrazione abituale. Se il VPS è appena stato consegnato, iniziate dalla nostra guida ai primi passi con il vostro VPS Windows.

Prima di Chocolatey: installate gli aggiornamenti di Windows, riavviate se necessario, verificate l'ora e la risoluzione DNS, verificate l'accesso HTTPS in uscita, aprite PowerShell come amministratore e create uno snapshot precauzionale se la piattaforma lo consente.

Rilevazione iniziale:

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

Lo snapshot facilita il ritorno indietro dopo una modifica di sistema, ma non sostituisce un backup esterno. Un aggiornamento software può inoltre modificare dati applicativi che il ripristino dello snapshot riporterebbe indietro.

4. Installare Chocolatey con il metodo ufficiale

La pagina di installazione ufficiale propone questo comando PowerShell:

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"
))

L'ambito Process limita la modifica dei criteri di esecuzione alla console corrente. Il numero 3072 corrisponde a TLS 1.2 nelle versioni di .NET interessate.

Questo comando è ufficiale, ma scarica ed esegue immediatamente del codice. Chocolatey chiede esso stesso di ispezionare install.ps1 prima di usarlo. Per una pratica coerente con la nostra guida all'hardening, che sconsiglia di eseguire uno script scaricato senza averlo letto, preferite la procedura seguente.

5. Scaricare lo script, leggerlo e poi eseguirlo

Create una cartella di lavoro e scaricate lo script senza eseguirlo:

$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

Verificate il file:

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

Get-FileHash -Path $InstallScript -Algorithm SHA256

Get-Content -Path $InstallScript

Potete anche aprirlo nel Blocco note:

notepad.exe $InstallScript

Che cosa cercare durante la revisione

Controllate in particolare l'URL da cui viene scaricato il pacchetto Chocolatey, le variabili d'ambiente consultate, i percorsi creati, le modifiche a PATH, eventuali download o eseguibili secondari, le chiamate PowerShell dinamiche e l'assenza di destinazioni o comandi inattesi.

Il checksum SHA-256 registrato dimostra che è stato revisionato ed eseguito lo stesso file. Non autentica lo script da solo finché non viene confrontato con un valore pubblicato tramite un canale indipendente. La verifica HTTPS e la revisione del contenuto restano quindi necessarie.

Dopo la convalida interna, eseguite il file locale:

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

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

choco --version

I criteri di esecuzione permanenti della macchina non sono stati abbassati. La chiusura della console rimuove il Bypass impostato a livello Process.

Per un'automazione professionale

Non riscaricate silenziosamente la versione corrente di install.ps1 a ogni creazione di server. Dopo la convalida:

  1. archiviate lo script approvato o l'MSI ufficiale nel vostro repository di artefatti;
  2. registratene il SHA-256 e la versione di Chocolatey;
  3. puntate il bootstrap a quella copia interna;
  4. convalidate una nuova versione prima di sostituire la precedente;
  5. rimuovete la sorgente comunitaria dai server di produzione se non serve.

Chocolatey offre anche un MSI dalla versione 2.0.0. La documentazione precisa che quell'MSI serve al bootstrap: installa Chocolatey, ma non ne esegue né l'aggiornamento né la disinstallazione.

6. Controllare l'installazione

Il percorso predefinito è C:\ProgramData\chocolatey. Chocolatey indica che lì i permessi sono irrobustiti per gli amministratori. Se scegliete un'altra posizione con ChocolateyInstall, la documentazione vi chiede di gestire voi stessi le ACL.

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

Verificate almeno:

ControlloRisultato atteso
choco --versionun numero di versione, senza errori
comando risoltobinario nella cartella di Chocolatey
cartella di installazionescrivibile solo dalle identità previste
sorgente comunitariapresente solo se la vostra politica lo consente
logC:\ProgramData\chocolatey\logs\chocolatey.log

Non rendete C:\ProgramData\chocolatey modificabile da un utente standard: potrebbe sostituire uno shim, uno script o un pacchetto poi eseguito con privilegi elevati. La nostra guida per configurare il firewall di Windows Server su un VPS completa questo irrobustimento sul versante rete.

7. Capire chi pubblica i pacchetti comunitari

Il repository community.chocolatey.org contiene pacchetti creati da membri della comunità. Il manutentore del pacchetto non è necessariamente il produttore del software. La FAQ del repository comunitario distingue esplicitamente il supporto del pacchetto, a carico dei suoi manutentori, dal supporto del software, a carico del produttore.

Da ottobre 2014, ogni versione di ogni pacchetto inviato attraversa un processo di moderazione prima della pubblicazione. Secondo la documentazione sulla sicurezza di Chocolatey e la documentazione sulla moderazione, quel processo può comprendere una convalida automatica di qualità, una verifica di installazione e disinstallazione, un'analisi VirusTotal, una revisione umana per i pacchetti privi di stato di fiducia e controlli di provenienza e checksum dei binari.

Un pacchetto «trusted» può essere approvato dopo i controlli automatici senza una nuova revisione umana se nulla viene segnalato. La moderazione riduce il rischio; non trasforma un repository comunitario in una sorgente sotto il vostro controllo.

Chocolatey indica inoltre che il suo scanner di pacchetti prova per impostazione predefinita solo i programmi di installazione en-US. Un pacchetto può funzionare nell'ambiente di verifica e fallire con un'altra lingua, un'altra architettura, un proxy, un riavvio in sospeso o una configurazione di server particolare.

Verificare un pacchetto prima di installarlo

Iniziate dai metadati:

choco info 7zip
choco info git
choco info sysinternals

Sulla pagina del pacchetto controllate l'identità dei manutentori, il collegamento al codice sorgente del pacchetto, lo stato di convalida, verifica e analisi, la cronologia delle versioni, la sezione Files, il file chocolateyInstall.ps1, gli URL scaricati, i checksum dichiarati, le dipendenze e i parametri e argomenti silenziosi.

La FAQ ufficiale spiega che il file .nupkg può essere scaricato, rinominato in .zip ed estratto per l'ispezione. Esaminate il pacchetto esatto, non solo il ramo principale del suo repository sorgente: il ramo può essere cambiato dopo la pubblicazione della versione.

Che cosa VirusTotal non garantisce

Un esito senza rilevamenti non è una prova di innocuità. Non convalida la logica PowerShell, l'intenzione del manutentore, la conformità delle licenze o il comportamento futuro di un URL remoto. La protezione antimalware in esecuzione delle edizioni Pro e Business riguarda i file scaricati da una sorgente esterna durante l'installazione; Chocolatey precisa che i binari incorporati direttamente in un pacchetto non vengono analizzati da quella funzione in quel momento.

8. Installare strumenti senza trasformare il server in una postazione di lavoro

Su un server ogni software aumenta la superficie di manutenzione. Installate solo gli strumenti necessari al ruolo del VPS.

Esempio di installazione esplicita con controllo di ogni risultato:

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

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

    if ($InstallCode -notin @(0, 1641, 3010)) {
        throw "Installazione di $PackageId fallita: codice $InstallCode"
    }

    if ($InstallCode -in @(1641, 3010)) {
        Write-Warning "$PackageId installato; riavvio richiesto."
    }
}

choco list

I codici 1641 e 3010 indicano rispettivamente esito positivo con riavvio avviato ed esito positivo con riavvio richiesto. Chocolatey definisce del resto 0, 1605, 1614, 1641 e 3010 come codici di uscita validi. Uno script che tratti ogni codice diverso da zero come un errore dichiarerebbe quindi erroneamente fallite alcune installazioni.

Non usate --force per impostazione predefinita. La documentazione dei comandi Chocolatey spiega che quell'opzione aggira comportamenti di protezione e la sconsiglia negli script ordinari.

9. Rendere riproducibile l'installazione

Una sequenza di comandi copiata dalla cronologia di PowerShell non è ancora una configurazione riproducibile. Occorre conservare l'identificatore esatto del pacchetto, la versione convalidata, la sorgente autorizzata, i parametri del pacchetto, gli argomenti passati al programma di installazione, il codice di ritorno, la necessità di riavvio e un test funzionale dopo l'installazione.

Esportare lo stato di un VPS di riferimento

Il comando choco export crea un file packages.config. Su una macchina di riferimento già convalidata:

$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

Inserite quel manifesto nel vostro repository di configurazione con una revisione del codice, un numero di modifica, la data di convalida, l'ambiente di prova e la sorgente interna corrispondente.

Non consideratelo un backup completo. Non cattura necessariamente i parametri di ogni installazione, le impostazioni applicative, i segreti, i dati o il software installato al di fuori di Chocolatey.

Riprodurre il manifesto

Su un VPS nuovo:

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

if (-not (Test-Path $ManifestPath)) {
    throw "Manifesto Chocolatey non trovato: $ManifestPath"
}

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

& choco @Arguments
$InstallCode = $LASTEXITCODE

if ($InstallCode -notin @(0, 1641, 3010)) {
    throw "Bootstrap software fallito: codice $InstallCode"
}

Non confondere versioni bloccate e manutenzione

Una versione bloccata rende prevedibile una ricostruzione, ma può anche conservare una vulnerabilità. Il ciclo corretto è:

  1. rilevare una nuova versione;
  2. importare il pacchetto e le sue risorse;
  3. rivedere le modifiche;
  4. provare installazione, aggiornamento e riavvio;
  5. promuovere la versione;
  6. modificare il manifesto;
  7. distribuire a ondate;
  8. conservare la versione precedente durante la finestra di ritorno.

10. Aggiornare il software senza un «upgrade all» alla cieca

Mostrare i pacchetti obsoleti:

choco outdated

Aggiornare un pacchetto specifico dopo la convalida:

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

if ($UpgradeCode -notin @(0, 1641, 3010)) {
    throw "Aggiornamento di Git fallito: codice $UpgradeCode"
}

Aggiornare a una versione approvata:

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

& choco @UpgradeArguments

Il valore VERSIONE_CONVALIDATA è volutamente un segnaposto: sostituitelo con la versione realmente qualificata e disponibile nel vostro repository.

Perché evitare un aggiornamento globale automatico in produzione

Il comando seguente esiste:

choco upgrade all -y

Può essere accettabile su una macchina di prova o una postazione non critica. Su un VPS di produzione può aggiornare contemporaneamente un runtime, uno strumento usato da un servizio, una dipendenza e Chocolatey stesso. In caso di errore, isolare l'origine della regressione diventa più difficile.

Preferite una finestra di manutenzione, uno snapshot precauzionale, un elenco di versioni approvate, aggiornamenti per lotti coerenti, test applicativi, un riavvio controllato e una distribuzione progressiva su più server.

La documentazione di Chocolatey segnala inoltre che un aggiornamento globale può lasciare dipendenze in uno stato incoerente se una parte della catena fallisce. In quel caso iniziate dal pacchetto o dalla dipendenza esplicitamente citata nell'errore.

Bloccare temporaneamente un pacchetto

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

Un pin è una misura temporanea, non una strategia di sicurezza. Associatelo a un motivo, un ticket, un responsabile e una data di riesame.

11. Produrre un rapporto di aggiornamento senza modificare il server

Per un monitoraggio semplice, attivate i codici di uscita estesi:

choco feature enable --name=useEnhancedExitCodes

Con questa funzione, choco outdated restituisce:

CodiceSignificato
0nessun pacchetto obsoleto
2almeno un pacchetto obsoleto
1 o -1si è verificato un errore

Script di audit, senza installazione:

$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 "Nessun aggiornamento Chocolatey rilevato."
    }
    2 {
        Write-Warning "Sono disponibili aggiornamenti: $ReportPath"
    }
    default {
        throw "Audit Chocolatey fallito: codice $ExitCode"
    }
}

Pianificate questo controllo con il vostro strumento di monitoraggio, una GPO, uno scheduler o un'attività di Windows. Non trasformate automaticamente quel rapporto in un upgrade all senza convalida.

12. Perché un'azienda dovrebbe usare un proprio repository

Chocolatey Software scrive esplicitamente che un'organizzazione non dovrebbe usare direttamente il repository comunitario come sorgente di produzione. La sua guida all'internalizzazione automatizzata indica tre ragioni:

  • fiducia: creatori e manutentori esterni non sono sotto il controllo dell'organizzazione;
  • stabilità: pacchetti e download devono restare disponibili durante le operazioni;
  • controllo: test, approvazione e pubblicazione devono appartenere all'organizzazione.

Un repository privato consente inoltre di conservare le versioni realmente distribuite, di non dipendere più da un URL del produttore modificato o rimosso, di ridurre i domini Internet autorizzati dai VPS, di qualificare un binario prima di diffonderlo, di creare i propri pacchetti di configurazione, di operare in una rete isolata, di separare import, test e produzione e di associare ogni promozione a una revisione e a una modifica registrata.

Architettura consigliata

FaseFunzione
repository comunitario o del produttoreorigine esterna, mai consumata direttamente dalla produzione
internalizzazionerecupero del pacchetto e delle sue risorse
repository Gitscript, manifesti, checksum e cronologia delle revisioni
repository Chocolatey di testinstallazione su un server rappresentativo
controlliantivirus, firme, checksum, test funzionali e riavvio
repository Chocolatey di produzionesoltanto versioni approvate
VPSaccesso in lettura al repository di produzione

Per i client usate un'identità di sola lettura. Riservate il diritto di pubblicare alla CI o a un'identità distinta. Non inserite mai un token di pubblicazione nello script di bootstrap di un VPS.

Repository compatibili

La documentazione di Chocolatey cita Inedo ProGet, Sonatype Nexus Repository, JFrog Artifactory, una sorgente NuGet compatibile e, in alcuni casi, una condivisione di file interna.

Il vecchio prodotto Chocolatey.Server è deprecato. Chocolatey raccomanda di migrare verso una soluzione di terze parti e cita ProGet, Nexus o Artifactory. Non avviate quindi un nuovo progetto attorno a Chocolatey.Server.

Open Source o Business per il repository interno?

L'edizione Open Source sa consumare più sorgenti, creare pacchetti e usare un repository privato. Consente anche un'internalizzazione manuale: download del pacchetto, recupero delle risorse, modifica degli script, nuova compilazione e pubblicazione.

Chocolatey for Business automatizza questo lavoro con Package Internalizer: il client scarica il pacchetto e le sue risorse esterne, riscrive i riferimenti e ricompila un pacchetto utilizzabile senza accesso a Internet. La funzione fa risparmiare tempo, ma la decisione di approvare e provare resta vostra.

13. Configurare una sorgente interna

Esempio con una sorgente HTTPS fittizia:

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

& choco @SourceArguments
choco source list

Una priorità numerica più bassa viene valutata prima di una più alta. Verificate sempre il risultato con choco source list.

Dopo aver confermato che il repository interno contiene Chocolatey e tutti i pacchetti necessari, disattivate il repository comunitario:

choco source disable --name=chocolatey
choco source list

Per un ambiente completamente isolato, la documentazione di Chocolatey consiglia di rimuovere la sorgente comunitaria:

choco source remove --name=chocolatey

La disattivazione è più facilmente reversibile; la rimozione evita che una riattivazione non controllata reintroduca la sorgente. Scegliete in base alla vostra gestione della configurazione.

Autenticazione e segreti

Chocolatey supporta l'autenticazione con nome utente e password e i certificati client X.509. Il comando source add cifra la password nel file di configurazione, ma un segreto passato su una riga di comando può risultare visibile ad altri meccanismi di registrazione o inventario.

Buone pratiche: usate sui VPS un account tecnico di sola lettura, preferite un token a breve durata o un certificato client se il repository lo consente, recuperate il segreto da una cassaforte al momento della distribuzione, non inseritelo né in Git, né in packages.config, né nell'immagine modello, separate le identità di lettura e pubblicazione e rinnovate i segreti provandone la revoca.

14. Confrontare le edizioni senza sopravvalutarle

Funzioni e prezzi possono cambiare. La tabella seguente riflette le pagine ufficiali Compare Chocolatey Editions e Pricing consultate il 31 agosto 2026.

EdizioneDestinatariChe cosa porta in questa guidaLimite da conoscere
Open Sourceprivati e organizzazionigestione dei pacchetti, creazione di pacchetti, più sorgenti, repository privato, aggiornamento globaleinternalizzazione e governance avanzata da costruire manualmente
Prouna persona fisica, licenza nominativafunzioni Open Source più cache CDN, protezione antimalware in esecuzione, sincronizzazione e funzioni di comoditàlicenza personale e nominativa; fino a 8 macchine personali
Business (C4B)organizzazioniPackage Internalizer, Central Management, audit, self-service, sincronizzazione completa e funzioni di distribuzionecosto per nodo, infrastruttura e processi da gestire

Prezzi indicati al 31 agosto 2026

  • Open Source: gratuita, senza limite di macchine;
  • Pro: 96 dollari all'anno, licenza personale nominativa, fino a 8 macchine personali;
  • Business: a partire da 18 dollari per licenza all'anno;
  • la pagina dei prezzi indica un abbonamento annuale Business a partire da 1 800 dollari all'anno, corrispondente a un minimo di 100 nodi a 18 dollari per nodo all'anno, con sconti sui volumi oltre i 500 nodi.

Verificate la pagina ufficiale al momento dell'acquisto. Imposte, preventivi, sconti, supporto premium e condizioni contrattuali possono modificare il costo reale.

Una scelta ragionevole in base alle dimensioni

SituazioneScelta spesso sufficiente
uno o pochi VPS, team in grado di mantenere i propri pacchettiOpen Source con repository privato e import manuale
uso strettamente personaleOpen Source o Pro secondo le funzioni desiderate
parco aziendale con import frequente di pacchetti esterniBusiness, da valutare per l'Internalizer e l'audit
necessità di self-service per utenti senza diritti di amministratoreBusiness
necessità di un cruscotto centrale di conformitàBusiness o uno strumento di gestione già presente

Business non rende automaticamente sicuri i pacchetti. Facilita internalizzazione, controllo centrale e audit. Se l'organizzazione dispone già di un repository NuGet, di una CI, di un EDR e di uno strumento di configurazione, l'edizione Open Source può bastare per un perimetro ridotto e ben gestito.

15. Script di bootstrap riproducibile

Lo script seguente non sceglie il software al posto vostro. Richiede un manifesto esistente, una sorgente Chocolatey già configurata, un URL di bootstrap approvato e il checksum SHA-256 atteso dello script di installazione.

In una produzione matura, BootstrapUri deve puntare alla vostra copia interna convalidata.

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 "Manifesto non trovato: $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 "Checksum del bootstrap non valido."
    }

    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 "Sorgente Chocolatey assente: $SourceName"
}

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

& choco @InstallArguments
$InstallCode = $LASTEXITCODE

if ($InstallCode -notin @(0, 1641, 3010)) {
    throw "Installazione del manifesto fallita: codice $InstallCode"
}

& choco list

if ($InstallCode -in @(1641, 3010)) {
    Write-Warning "Bootstrap terminato; riavvio richiesto."
}

Lo script è idempotente per l'installazione del client: non reinstalla Chocolatey se il comando esiste già. La riproducibilità deriva soprattutto dal manifesto versionato, dalla sorgente interna immutabile e dai test successivi all'installazione.

Miglioramenti consigliati per un parco: firma Authenticode del vostro script di bootstrap, esecuzione da un'immagine di riferimento o da uno strumento di configurazione, invio del log a un archivio centrale, identificativo univoco di distribuzione, controllo dello spazio su disco, rilevamento di un riavvio già in sospeso, test applicativo specifico del ruolo del VPS e un blocco che impedisca due distribuzioni simultanee.

16. Proxy, cache e accesso di rete

Con il repository comunitario, il VPS deve raggiungere community.chocolatey.org, l'infrastruttura dei pacchetti di Chocolatey e i domini di ciascun produttore da cui gli script scaricano i binari.

Quest'ultima dipendenza spiega perché autorizzare in un proxy soltanto il dominio di Chocolatey non basta sempre. Un repository interno con risorse internalizzate riduce di molto il numero di destinazioni esterne.

Mostrare la configurazione:

choco config list
choco source list

Configurare un proxy esplicito senza autenticazione:

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

Rimuovere quell'impostazione:

choco config unset --name=proxy

Per un proxy autenticato, non scrivete la password in uno script o in un ticket. Iniettatela da una cassaforte e verificate quali tracce della riga di comando raccoglie il vostro EDR.

Spostare la cache

Chocolatey usa per impostazione predefinita una cartella temporanea per i download. Su un VPS con un disco di sistema piccolo potete definire una cache dedicata:

$CachePath = "D:\ChocolateyCache"

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

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

Se il volume D: non esiste, scegliete un percorso reale. Proteggete quella cartella dalla scrittura da parte di utenti non autorizzati e definite una politica di pulizia. Una cache può contenere programmi di installazione eseguibili; non è una semplice cartella innocua.

17. Log, inventario e prova delle modifiche

Il log principale si trova normalmente qui:

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

Get-Content $ChocolateyLog -Tail 200

Per aggiungere un log specifico di un'operazione:

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

& choco @Arguments

Per ogni modifica in produzione conservate:

ProvaEsempio
stato precedentechoco list e versione del software
richiestaticket o commit del manifesto
sorgenterepository e versione approvata
comandoargomenti senza segreti
risultatocodice di uscita ed estratti utili
riavviorichiesto, effettuato e orario
convalidaservizio avviato, porta o test funzionale
stato successivonuova versione e monitoraggio normale

Non pubblicate un log grezzo senza rileggerlo: possono comparirvi un URL, un nome utente, un token o un percorso sensibile.

18. Disinstallare e tornare indietro

Disinstallare un pacchetto:

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

if ($UninstallCode -notin @(0, 1605, 1614, 1641, 3010)) {
    throw "Disinstallazione fallita: codice $UninstallCode"
}

Chocolatey documenta il codice 1605 per un software assente e 1614 per un prodotto già disinstallato. Il risultato reale dipende dallo script del pacchetto e dal programma di disinstallazione del produttore.

Un ritorno a una versione precedente non è sempre un rollback affidabile: un programma di installazione può rifiutare una versione anteriore, un formato di configurazione o di dati può essere migrato, un servizio può non accettare più il vecchio binario e un pacchetto può non fornire uno script di disinstallazione completo.

Per un VPS critico preparate tre livelli:

  1. reinstallazione del pacchetto precedente dal repository interno;
  2. ripristino di configurazioni e dati compatibili;
  3. ricostruzione del VPS a partire dal manifesto e dai backup.

Lo snapshot precauzionale può ridurre il tempo di ripristino, ma il suo recupero annulla anche le scritture effettuate da quando è stato creato. Definite che cosa va salvato separatamente prima della finestra, come descrive la nostra guida su come salvare il proprio VPS Windows.

19. Risoluzione dei problemi

Il comando choco non viene riconosciuto

Aprite una nuova console o aggiornate il PATH della sessione:

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

Se è stato usato un percorso personalizzato ChocolateyInstall, adattate il valore.

Errore TLS o connessione chiusa

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

Test-NetConnection community.chocolatey.org -Port 443

Verificate anche data e ora, la risoluzione DNS, il proxy, l'ispezione TLS, la catena di certificazione, le regole in uscita e la presenza di .NET Framework 4.8.

Non usate un'opzione che ignori gli errori di certificato. Correggete invece la catena di fiducia o il proxy.

I criteri di esecuzione bloccano il bootstrap

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

Una GPO può avere comunque la precedenza su questa impostazione. In tal caso usate il metodo di distribuzione autorizzato dall'organizzazione, per esempio un MSI approvato o uno script firmato.

Errore di checksum

Non ignorate l'errore per «far passare» l'installazione. Può indicare una nuova versione pubblicata allo stesso URL, un pacchetto non ancora aggiornato, un'intercettazione o una cache intermedia, un download incompleto, oppure una risorsa realmente diversa da quella convalidata.

Confrontate il binario del produttore, lo script del pacchetto, la versione e il checksum. Attendete una versione corretta o internalizzate il binario approvato.

Il pacchetto è installato ma il software no

Con l'edizione Open Source, lo stato del pacchetto può divergere da Programmi e funzionalità se il software è stato modificato al di fuori di Chocolatey.

choco list

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

Verificate poi il servizio, il file eseguibile o la chiave di registro propria del software. Non dichiarate il server conforme solo in base all'output di choco list.

È configurata una sorgente interna ma si usa ancora il repository comunitario

choco source list

Verificate le priorità, la disponibilità del pacchetto interno e gli argomenti --source. Per una produzione chiusa, disattivate o rimuovete esplicitamente la sorgente comunitaria.

Un aggiornamento richiede un riavvio

Non riavviate subito un server di produzione da uno script generico. Segnalate il codice 1641 o 3010, completate i controlli possibili, poi riavviate nella finestra prevista e convalidate i servizi.

Dove leggere l'errore dettagliato?

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

Cercate anzitutto il primo errore significativo e il pacchetto dipendente citato. Gli avvisi successivi possono esserne solo una conseguenza.

20. Buone pratiche su un VPS Windows

  • non installate strumenti non necessari al ruolo del server;
  • usate una console di amministrazione solo durante l'operazione;
  • limitate i criteri Bypass al processo;
  • ispezionate il bootstrap prima della prima esecuzione;
  • ispezionate gli script dei pacchetti nuovi o delicati;
  • usate versioni convalidate e disponibili in un repository interno;
  • separate i repository di test e produzione;
  • disattivate il repository comunitario in produzione;
  • non mettete i segreti del repository in Git;
  • trattate i codici di riavvio come successi ancora da completare;
  • eseguite outdated con regolarità, senza aggiornamenti automatici alla cieca;
  • provate la funzione del software dopo l'installazione;
  • centralizzate log e inventario;
  • rivedete regolarmente i pin;
  • provate una ricostruzione completa del VPS.

Domande frequenti

Chocolatey è gratuito per un'azienda?

Sì. La pagina ufficiale dei prezzi presenta l'edizione Open Source come gratuita, utilizzabile dalle organizzazioni e senza limite di macchine. Le funzioni Business sono a pagamento, ma un repository privato non richiede di per sé l'edizione Business.

Chocolatey Pro può essere distribuito sui VPS di un'azienda?

No, secondo la pagina ufficiale dei prezzi. Pro è presentata come una licenza personale e nominativa, prevista per le macchine proprie dell'utente, fino a otto. Un'organizzazione deve scegliere Open Source o valutare Business.

I pacchetti comunitari sono pubblicati dai produttori?

Non necessariamente. Sono creati da manutentori della comunità, talvolta dal produttore stesso, talvolta da terzi. Verificate la scheda di ogni pacchetto.

La moderazione garantisce che un pacchetto sia sicuro?

No. Aggiunge convalida, verifica, analisi e revisione a seconda dello stato del pacchetto. Riduce il rischio, ma non sostituisce l'approvazione interna, la revisione dello script e il test della versione esatta.

Perché leggere install.ps1 se l'URL è ufficiale?

Perché il comando ufficiale scarica ed esegue PowerShell con privilegi elevati. Chocolatey raccomanda esso stesso questa ispezione. Consente inoltre di conservare il checksum del codice realmente autorizzato.

Bisogna lanciare choco upgrade all ogni notte?

Non su un server di produzione senza test. Usate choco outdated per rilevare, qualificate le versioni e distribuite poi con finestra, test e gestione dei riavvii.

Un packages.config basta per clonare un VPS?

No. Descrive i pacchetti, ma non tutte le configurazioni, i dati, i segreti, i ruoli di Windows, le regole del firewall, i certificati o le attività pianificate. Inseritelo in una procedura di configurazione più ampia.

Quale repository interno scegliere?

Scegliete un prodotto compatibile con NuGet che il vostro team sappia salvare, aggiornare e monitorare. Chocolatey cita ProGet, Nexus e Artifactory. Chocolatey.Server è deprecato.

Chocolatey sostituisce Winget?

I due possono coesistere, ma moltiplicare i gestori aumenta il rischio di stati divergenti. Definite un responsabile per ciascun software ed evitate che lo stesso programma venga aggiornato da Chocolatey, Winget e dal proprio aggiornatore senza una regola chiara.

Checklist operativa

  • Windows Server e .NET Framework sono aggiornati;
  • la console usata è elevata;
  • lo script ufficiale è stato scaricato prima dell'esecuzione;
  • il suo contenuto e il suo SHA-256 sono stati conservati;
  • i criteri di esecuzione sono stati modificati solo a livello Process;
  • il percorso di Chocolatey ha ACL restrittive;
  • ogni pacchetto ha un responsabile e una giustificazione;
  • manutentore, script, URL e checksum sono stati rivisti;
  • le versioni sono registrate in un manifesto;
  • i parametri di installazione sono documentati a parte;
  • la sorgente di produzione è interna;
  • la sorgente comunitaria è disattivata o rimossa in produzione;
  • le identità di lettura e pubblicazione sono separate;
  • i segreti non compaiono negli script;
  • i codici 1641 e 3010 sono gestiti;
  • gli aggiornamenti sono provati prima della distribuzione;
  • un rapporto outdated viene prodotto con regolarità;
  • i log sono conservati;
  • ripristino e ricostruzione sono stati provati.

Per approfondire

Questa guida si integra con i nostri altri articoli Windows: primi passi con il vostro VPS Windows per iniziare, configurare il firewall di Windows Server per i criteri di rete, installare IIS se il VPS ospita un sito, installare Active Directory per un controller di dominio, e salvare il proprio VPS Windows prima di ogni operazione delicata.

Fonti tecniche principali

Installazione e comandi

Pacchetti, fiducia e repository

Edizioni