Homebrew è un package manager per macOS che consente di installare, aggiornare e rimuovere software da Terminale con un sistema coerente. È particolarmente utile per utility da riga di comando, runtime, librerie, server locali e applicazioni tecniche, ma può gestire anche normali app Mac attraverso i cask.
Nel 2026 la parte importante non è copiare il comando di installazione. Prima conviene verificare quale Mac stai usando e quale versione di macOS è installata, perché Apple Silicon e Intel non hanno più lo stesso livello di supporto.
La serie 7, pubblicata a settembre 2026, ha spostato i Mac Intel in Tier 3, ha terminato il supporto per macOS Catalina e precedenti e ha introdotto novità come controlli sulle vulnerabilità e BrewUI. La release corrente al 1° ottobre 2026 è la 7.0.7. Puoi verificare sia l’annuncio della versione 7 sia le release correnti su GitHub.
In questa guida vediamo come installare il package manager correttamente, configurare la shell, usare i comandi essenziali e diagnosticare gli errori più comuni senza affidarsi a procedure ormai superate.
Cos’è Homebrew e perché usare un package manager su macOS
Un package manager macOS centralizza operazioni che altrimenti dovresti gestire software per software: download, dipendenze, installazione, aggiornamenti e rimozione.
Se stai cercando un package manager macOS per un ambiente tecnico, il vantaggio principale non è soltanto digitare meno comandi: è avere un sistema comune con cui amministrare strumenti che altrimenti seguirebbero procedure differenti.
Con un’installazione manuale il percorso è spesso:
trova il sito → scarica il file → installa → ricorda come aggiornarlo
Con brew diventa più uniforme:
cerca → controlla le informazioni → installa → aggiorna
Il vantaggio è soprattutto gestionale. Se lavori con più strumenti tecnici, avere un unico sistema riduce il numero di procedure diverse da ricordare. Homebrew diventa quindi particolarmente utile quando la tua workstation comprende molti componenti che evolvono con frequenza diversa.
Cosa fa il package manager quando esegui brew install
Prendiamo un comando semplice:
brew install wget
Il gestore non scarica soltanto un file. Legge la definizione del pacchetto, verifica dipendenze e compatibilità, sceglie quando possibile un binario precompilato e registra ciò che viene installato per poterlo aggiornare o rimuovere in seguito.
Per questo è particolarmente utile in ambienti di sviluppo. Runtime, database, server e utility CLI possono avere dipendenze che diventano scomode da amministrare a mano.
Non significa che ogni applicazione debba essere installata così. Mac App Store, installer del produttore e updater integrati restano la scelta corretta quando sono il canale previsto dal software.
Formula, cask, bottle e tap: le differenze che servono davvero
Quattro termini compaiono spesso nella documentazione:
| Termine | Cosa indica | Perché ti interessa |
|---|---|---|
| Formula | definizione di un pacchetto gestito da brew | comune per CLI, librerie, runtime e servizi |
| Cask | definizione per software precompilato, spesso applicazioni macOS | permette di gestire app e binari distribuiti dall’upstream |
| Bottle | build già compilata di una formula | evita la compilazione locale quando esiste per la tua piattaforma |
| Tap | repository aggiuntivo di formula, cask o comandi | estende le sorgenti disponibili oltre a quelle ufficiali |
La distinzione più utile è tra formula e bottle. La formula descrive il pacchetto; la bottle è una build precompilata. Se per il tuo sistema non esiste una bottle, può essere necessaria una compilazione dai sorgenti e diventano importanti anche gli strumenti di sviluppo.
Il progetto funziona anche su Linux e WSL
Il gestore può essere usato anche su Linux e Windows attraverso WSL. Su Linux il prefix predefinito è /home/linuxbrew/.linuxbrew, mentre sui Mac Apple Silicon è normalmente /opt/homebrew. La differenza è documentata nella guida ufficiale all’installazione.
Questo non significa che debba sostituire apt, dnf, pacman o gli altri package manager della distribuzione. Può essere utile quando vuoi un tool non presente nei repository di sistema o desideri un workflow simile fra più ambienti.
Per capire meglio la differenza tra distribuzioni, repository e gestori di pacchetti puoi partire dalla nostra guida a Linux.
Prima dell’installazione: controlla processore, macOS e supporto
Prima di installare, esegui:
uname -m sw_vers -productVersion
Il primo comando mostra l’architettura. Su Apple Silicon vedrai normalmente arm64; su Intel x86_64.
Il secondo restituisce la versione di macOS.
Sono due informazioni decisive perché il livello di supporto cambia in modo sostanziale.
| Configurazione | Stato corrente | Indicazione pratica |
|---|---|---|
| Apple Silicon + macOS 15, 26 o 27 | Tier 1 | configurazione pienamente supportata |
| Apple Silicon + macOS 11–14 | Tier 3 | può funzionare, ma non è il percorso normalmente supportato |
| Intel + macOS 11–26 | Tier 3 | ambiente legacy da valutare con attenzione |
| macOS 10.15 o precedente | non supportato | non è più un percorso compatibile con la serie 7 |
La matrice corrente è descritta nei Support Tiers ufficiali.
Apple Silicon: quali versioni sono pienamente supportate
A settembre 2026 la configurazione Tier 1 su Mac comprende Apple Silicon con macOS Sequoia 15, Tahoe 26 o Golden Gate 27, nelle condizioni indicate dalla documentazione.
Le versioni da Big Sur 11 a Sonoma 14 rientrano invece nel Tier 3. Possono ancora funzionare, ma non ricevono lo stesso livello di CI, bottle e supporto.
Su Apple Silicon il prefix standard è:
/opt/homebrew
Questa informazione è utile soprattutto quando devi verificare il PATH o capire se sulla macchina è rimasta una vecchia installazione Intel.
Mac Intel: cosa significa Tier 3
I Mac Intel non vanno più trattati come un percorso equivalente.
Il progetto ha smesso di costruire nuove bottle per Intel e indica che la possibilità di eseguire il gestore su questa architettura verrà rimossa in o dopo settembre 2027. Le installazioni esistenti possono ancora funzionare, ma dipendono maggiormente da pacchetti precedenti o compilazioni locali.
Se utilizzi un Intel per lavoro, la domanda utile non è “funziona ancora oggi?”, ma “questo ambiente è sostenibile per il software che dovrò aggiornare nei prossimi mesi?”.
Servono Xcode o le Command Line Tools?
Non sempre.
Su Apple Silicon i cask e le bottle precompilate possono essere installati senza Xcode o Command Line Tools. Gli strumenti di sviluppo diventano necessari quando una formula deve essere compilata dai sorgenti.
Per installare le CLT:
xcode-select --install
Le Command Line Tools non coincidono con l’intero IDE. Se ti serve capire cosa comprende l’ambiente Apple completo, simulatori, SDK e strumenti di compilazione inclusi, trovi il quadro nella nostra guida a Xcode.
Quando valutare MacPorts
Su un Apple Silicon supportato brew è normalmente un percorso naturale. Su Intel il ragionamento cambia.
La documentazione dei Support Tiers cita MacPorts come alternativa in diversi scenari non più coperti dalle bottle correnti. Se devi costruire oggi un ambiente destinato a restare a lungo su Intel, vale quindi la pena confrontare il supporto dei pacchetti che usi davvero prima di scegliere.
Non serve migrare per principio un sistema che funziona. Serve evitare di creare nuove dipendenze senza considerare che il supporto Intel ha già una scadenza dichiarata.
Installazione su Mac
Se devi installare Homebrew su una macchina Apple Silicon supportata, conviene seguire sempre la procedura ufficiale corrente, perché installer, requisiti e note post-installazione possono cambiare.
Il flusso corretto è:
- controllare CPU e versione di macOS;
- usare l’installer ufficiale;
- leggere ciò che lo script intende modificare;
- completare i passaggi
shellenv; - verificare il comando dalla shell.
Installazione ufficiale da Terminale
L’installer standard viene eseguito con /bin/bash. Prima puoi ricontrollare l’ambiente:
uname -m sw_vers -productVersion
Poi usa il comando mostrato sul sito ufficiale o nel repository dell’installer.
Lo script spiega cosa farà prima di procedere e usa il prefix previsto per la piattaforma. Su Apple Silicon il percorso standard è /opt/homebrew.
Installer .pkg: quando ha senso
Esiste anche un installer .pkg, ma la documentazione corrente specifica che supporta soltanto Apple Silicon e utilizza lo stesso prefix standard.
È soprattutto utile in contesti amministrati, per esempio quando devi distribuire il package attraverso MDM o preparare più Mac in modo controllato.
Per una singola macchina personale, Terminale e .pkg non rappresentano due ecosistemi diversi: cambiano soprattutto modalità di deployment.
Configurare il PATH con brew shellenv
Uno dei problemi più frequenti compare dopo un’installazione apparentemente riuscita: il comando non viene trovato.
L’installer stampa una sezione Next steps proprio per configurare la shell. Su un Apple Silicon standard, per la sessione corrente puoi usare:
eval "$(/opt/homebrew/bin/brew shellenv)"
Per rendere la configurazione persistente devi aggiungere l’inizializzazione al file utilizzato dalla tua shell, ad esempio ~/.zshrc o ~/.bashrc secondo il contesto.
Non scegliere il file a caso: segui i passaggi mostrati dall’installer o la sezione post-installazione della documentazione.
Verificare che tutto funzioni
Dopo il setup esegui:
brew --version command -v brew brew --prefix brew config brew doctor
Su un Apple Silicon installato nel percorso standard, brew --prefix dovrebbe restituire:
/opt/homebrew
brew doctor è uno strumento diagnostico, non un punteggio. I warning vanno interpretati in relazione al problema che stai risolvendo.
Primi comandi: cercare, installare e capire un pacchetto
Dopo l’installazione non serve imparare decine di istruzioni. La sequenza più utile è:
search → info → install → list
Cercare prima di installare
Per cercare una formula o un cask:
brew search wget
Per vedere le informazioni disponibili:
brew info wget
brew info aiuta a controllare versione, dipendenze e caveat prima di modificare l’ambiente.
Installare una formula
Per una normale formula:
brew install wget
Poi puoi verificare:
brew info wget brew list wget
Se il pacchetto richiede dipendenze, il gestore le installa insieme alla formula.
Installare un’app tramite cask
Per un’applicazione distribuita come cask:
brew install --cask nome-app
Un esempio concreto è Claude Code, che su macOS può essere installato con:
brew install --cask claude-code
Lo stesso modello vale per Codex:
brew install --cask codex
Il vantaggio è che strumenti differenti possono essere amministrati attraverso lo stesso workflow, senza confondere però il package manager con il software installato.
Vedere cosa è già installato
Per ottenere l’elenco generale:
brew list
Per separare formula e cask:
brew list --formula brew list --cask
Per mostrare anche le versioni:
brew list --versions
Per esplorare le dipendenze:
brew deps --installed
Questo controllo è utile prima di rimuovere componenti che potrebbero essere necessari ad altri pacchetti.
Aggiornamenti e manutenzione
Una confusione frequente riguarda update e upgrade: non sono sinonimi.
Homebrew usa i due comandi per operazioni diverse, quindi distinguerli evita di aggiornare pacchetti quando volevi soltanto aggiornare le informazioni disponibili.
brew update e brew upgrade fanno cose diverse
brew update aggiorna il package manager e le informazioni sulle formule e sui cask disponibili:
brew update
Per vedere cosa è diventato obsoleto:
brew outdated
Per aggiornare i pacchetti installati:
brew upgrade
Oppure un solo elemento:
brew upgrade nome-formula
Il modello è quindi:
update → aggiorna le informazioni
outdated → mostra cosa può essere aggiornato
upgrade → aggiorna ciò che hai installato
Controllare i pacchetti obsoleti prima di aggiornare
Su una workstation usata per lavoro può essere sensato controllare prima:
brew outdated
e aggiornare singolarmente ciò che vuoi modificare.
Questo rende più semplice capire quale cambiamento ha eventualmente introdotto un problema, invece di aggiornare tutto in un unico passaggio.
Pulizia con brew cleanup
Per vedere cosa verrebbe rimosso:
brew cleanup --dry-run
Poi:
brew cleanup
Non considerarlo un cleaner generale di macOS. Serve a gestire cache e versioni che il package manager non deve più mantenere.
Gestire i servizi in background
Alcune formule installano servizi come database o web server. Per vedere quelli registrati:
brew services list
Per avviare un servizio:
brew services start httpd
Per fermarlo:
brew services stop httpd
Se vuoi capire il caso concreto del web server, nella nostra guida ad Apache trovi anche l’installazione con brew nel contesto della configurazione su macOS.
Brewfile, tap e BrewUI
Quando il numero di pacchetti aumenta, entrano in gioco strumenti utili per rendere l’ambiente più riproducibile e controllabile.
Salvare l’ambiente con Brewfile
Puoi creare uno snapshot:
brew bundle dump --file="$HOME/Brewfile" --force
Controllare se le dipendenze dichiarate sono soddisfatte:
brew bundle check --file="$HOME/Brewfile"
e installarle su un’altra macchina:
brew bundle --file="$HOME/Brewfile"
La documentazione Brew Bundle chiarisce però un limite importante: Brewfile non è un lockfile pensato per congelare indefinitamente ogni versione. È soprattutto una dichiarazione di ciò che vuoi presente nell’ambiente.
Tap di terze parti e trust
Un tap aggiunge repository esterni di formula, cask o comandi. Questo significa che non va trattato come semplice metadata.
Le versioni recenti hanno introdotto un modello di trust esplicito per i tap non ufficiali. La documentazione Tap Trust spiega come circoscrivere la fiducia invece di autorizzare automaticamente un intero repository.
Un esempio concreto sul sito è WPScan, installabile tramite il tap del progetto:
brew install wpscanteam/tap/wpscan
Il nome completo rende evidente da quale repository proviene la formula e aiuta a ragionare sulla provenienza prima di eseguire il software.
BrewUI: l’interfaccia grafica ufficiale
Con la serie 7 è arrivata anche BrewUI, l’app macOS ufficiale del progetto.
La GUI permette di cercare, installare e aggiornare pacchetti senza nascondere il modello sottostante. Requisiti e stato corrente sono indicati nel repository ufficiale di BrewUI.
Puoi installarla come cask:
brew install --cask homebrew-app
È un’interfaccia per lo stesso ecosistema, non un sostituto concettuale di brew: conoscere almeno i comandi principali resta utile per diagnosi e automazione.
Sicurezza: tap, vulnerabilità e limiti del sandbox
Un package manager rende più coerente la gestione del software, ma non può garantire che qualsiasi programma installato sia affidabile.
Controllare la provenienza
Prima di aggiungere un tap esterno o installare un pacchetto poco noto, verifica chi mantiene il repository, quale software distribuisce e se ti serve davvero concedere fiducia all’intera fonte.
Il modello di trust delle versioni recenti riduce il rischio di autorizzazioni troppo ampie, ma non sostituisce la valutazione del software.
Controllare vulnerabilità note
La serie 7 ha introdotto controlli integrati sulle vulnerabilità.
Per le formule puoi usare:
brew vulns
oppure:
brew vulns nome-formula
La manpage ufficiale documenta i comandi disponibili.
L’assenza di un advisory non significa “software certamente sicuro”. Significa soltanto che il controllo non ha trovato una vulnerabilità nota nei dati utilizzati.
Il sandbox non rende sicuro qualsiasi pacchetto
Le versioni recenti hanno rafforzato il sandboxing di diverse fasi di gestione dei pacchetti.
Il sandbox limita ciò che alcuni processi possono fare durante quelle operazioni; non cambia i privilegi che avrà in seguito un’applicazione che decidi volontariamente di eseguire.
Quindi:
sandbox più forte ≠ software automaticamente affidabile
nessun advisory ≠ nessuna vulnerabilità possibile
package manager ≠ sostituto della valutazione della fonte
Troubleshooting: gli errori più comuni
Quando qualcosa non funziona, conviene partire dal sintomo invece di applicare comandi di chmod, chown o cancellazioni recuperati da vecchie discussioni.
La procedura ufficiale di troubleshooting resta il riferimento da controllare quando il comportamento cambia tra una release e l’altra.
zsh: command not found: brew
Controlla prima se l’eseguibile è raggiungibile:
command -v brew
Su Apple Silicon puoi verificare il percorso standard:
ls -l /opt/homebrew/bin/brew
Se il file esiste, prova nella sessione corrente:
eval "$(/opt/homebrew/bin/brew shellenv)"
Poi:
command -v brew brew --prefix
Se ora funziona, il problema è quasi certamente nella configurazione persistente della shell.
brew doctor segnala PATH o developer tools
Quando la configurazione non si comporta come previsto, brew doctor è uno dei controlli più utili da eseguire prima di modificare permessi, symlink o directory.
Durante una diagnosi usa:
brew update brew doctor
Poi leggi gli avvisi pertinenti.
Se una formula deve essere compilata e mancano gli strumenti Apple:
xcode-select --install
Su Apple Silicon, invece, non interpretare automaticamente la mancanza delle CLT come problema se stai installando una bottle o un cask e la documentazione indica che non sono necessarie.
Non esiste una bottle compatibile
Controlla:
brew info nome-formula brew config
Se non esiste una bottle per il tuo ambiente, può essere necessaria una compilazione locale.
Su Intel questo scenario è sempre più rilevante perché non vengono prodotte nuove bottle. Quando un pacchetto è importante per il tuo lavoro, valuta anche un package manager ancora orientato al supporto Intel invece di forzare un ambiente Tier 3.
Il pacchetto è installato ma il comando non viene trovato
Alcune formula sono keg-only: vengono installate ma non collegate automaticamente nel normale prefix, spesso per evitare conflitti.
Controlla:
brew info nome-formula brew --prefix nome-formula
e leggi i Caveats.
Non usare automaticamente:
brew link --force nome-formula
Se il pacchetto richiede un PATH dedicato, è preferibile applicarlo soltanto nel contesto in cui serve.
Disinstallazione
Prima di rimuovere l’ambiente, se pensi di volerlo ricostruire, salva l’inventario:
brew bundle dump --file="$HOME/Brewfile" --force
Poi usa l’uninstaller indicato nelle FAQ ufficiali, invece di cancellare directory a mano.
Cosa controllare dopo la rimozione
Verifica:
command -v brew
Se non rimane alcuna installazione, controlla anche il file di configurazione della shell ed elimina soltanto la riga shellenv relativa al prefix rimosso.
Non cancellare in blocco /usr/local: può contenere file che non appartengono al package manager.
Su un Apple Silicon migrato da Intel è possibile avere tracce di un vecchio ambiente sotto /usr/local e quello corrente sotto /opt/homebrew. Prima inventaria, poi rimuovi.
Conclusione
Homebrew è utile soprattutto quando vuoi gestire con un metodo coerente strumenti da Terminale, runtime, librerie, server locali e applicazioni tecniche.
Su Apple Silicon con una versione di macOS supportata il percorso è lineare: installer ufficiale, configurazione shellenv, verifica e primi comandi. Su Intel conviene invece considerare il Tier 3 e la futura rimozione del supporto prima di creare nuove dipendenze.
La sequenza corretta è semplice: controlla il Mac, scegli il percorso compatibile, installa, verifica e solo dopo inizia ad aggiungere pacchetti.
È un approccio più affidabile di partire dalla one-liner e cercare di capire in seguito perché qualcosa non funziona.