1 26/05/2026 9 min

Installare Node.js su Ubuntu 20.04 senza sporcare il sistema

Su Ubuntu 20.04 hai tre strade sensate: usare i pacchetti della distribuzione, aggiungere il repository ufficiale di NodeSource oppure gestire le versioni con un version manager come nvm. Se l’obiettivo è avere un’installazione pulita, ripetibile e adatta a un server o a una macchina di test condivisa, il repository ufficiale è in genere la scelta più lineare. Se invece devi cambiare spesso versione tra progetti, nvm è più comodo. Qui parto dal caso più comune: installazione di Node.js su Ubuntu 20.04 con pacchetti affidabili e aggiornabili.

Nota pratica: Ubuntu 20.04 include una versione di Node.js nei repository standard, ma spesso non è quella che vuoi davvero in produzione o per uno sviluppo moderno. Se ti serve una release più recente e prevedibile, conviene separare il ciclo di aggiornamento di Node da quello del sistema operativo.

Scelta del metodo: repository ufficiale o nvm

Prima di installare, conviene decidere il modello operativo. Il repository ufficiale di NodeSource installa Node.js a livello di sistema, quindi è ideale per server, CI runner, container base o ambienti dove vuoi un binario unico e controllato da apt. nvm, invece, installa Node per utente e ti permette di avere più versioni in parallelo senza toccare i pacchetti di sistema.

In un server web classico, dove l’accesso è limitato e vuoi evitare conflitti con altri servizi, il repository ufficiale è quasi sempre la scelta più semplice. In un laptop di sviluppo o su una workstation, nvm offre più flessibilità. Se non hai un requisito esplicito, l’installazione via apt da repository esterno è quella che spiega meglio cosa trovi sul sistema con un semplice dpkg -l.

Aggiornare il sistema prima dell’installazione

Parti sempre da un sistema aggiornato. Non è una formalità: riduce il rischio di dipendenze rotte e ti fa vedere subito se il nodo ha problemi di repository o di rete.

Comandi base:

sudo apt update
sudo apt upgrade -y

Se apt update fallisce, il problema non è Node.js ma l’accesso ai repository o la configurazione DNS/proxy. Prima di andare avanti verifica che la macchina risolva i nomi e raggiunga Internet:

resolvectl status
curl -I https://deb.nodesource.com

Se il secondo comando non risponde con un codice HTTP valido, fermati lì: installare pacchetti da repository esterni senza connettività stabile ti lascia solo un mezzo stato e un troubleshooting più lungo.

Installazione di Node.js con il repository ufficiale

Il metodo più usato su Ubuntu 20.04 è aggiungere il repository di NodeSource. In questo modo ottieni un pacchetto nodejs mantenuto fuori dal ciclo standard di Ubuntu, con versioni più recenti e aggiornamenti coerenti.

Procedura consigliata per una release LTS corrente:

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs

Dopo l’esecuzione dello script di setup, viene aggiunto il repository e importata la chiave necessaria per firmare i pacchetti. Poi apt installa Node.js e, nella maggior parte dei casi, anche npm.

Se vuoi una major specifica, sostituisci setup_lts.x con la linea della versione desiderata, ad esempio setup_20.x o setup_18.x. La scelta dipende dalla compatibilità dell’applicazione, non dalla moda del momento. Per applicazioni già in esercizio, la regola è semplice: allinea la major alla matrice di supporto del progetto e non fare upgrade “a sentimento”.

Verifiche dopo l’installazione

Dopo l’installazione controlla subito binario, versione e percorso. È il modo più rapido per capire se stai usando il Node di sistema, un eventuale wrapper o un’installazione precedente rimasta in /usr/local.

node -v
npm -v
which node
which npm

Atteso: una versione coerente con il repository installato e un percorso tipo /usr/bin/node. Se which node punta a /usr/local/bin/node, probabilmente hai una vecchia installazione manuale che precede quella di apt nel PATH. In quel caso puoi trovarti davanti a versioni diverse tra shell, servizi systemd e script schedulati.

Per vedere i dettagli del pacchetto installato:

dpkg -l | grep -E '^ii\s+nodejs'
apt-cache policy nodejs

Il primo comando ti dice se il pacchetto è presente; il secondo mostra da quale repository arriva e quale versione è candidata all’upgrade.

Node.js e npm: cosa arriva davvero

Su Ubuntu, molti si aspettano che nodejs e npm siano sempre separati. Con NodeSource, in genere npm viene installato insieme a Node.js, ma non dare per scontata la presenza di tutto il toolchain. Se ti serve compilare moduli nativi, aggiungi anche gli strumenti base di build.

sudo apt install -y build-essential

Questo pacchetto è utile quando installi dipendenze che compilano estensioni C/C++ durante npm install. Senza i tool di compilazione, il problema emerge tardi, spesso in fase di deploy o in una pipeline CI, quando hai già un errore poco leggibile legato a node-gyp.

Esempio rapido: eseguire un file JavaScript di test

Per validare l’installazione, crea un file minimale e lancialo con Node. Non serve nulla di elaborato: basta verificare runtime, output e accesso al modulo standard.

cat > test.js <<'EOF'
console.log('Node OK:', process.version)
console.log('Platform:', process.platform)
EOF
node test.js

Se vedi una versione valida e la piattaforma corretta, il runtime funziona. Se invece il comando fallisce con command not found, il problema è nel PATH o nell’installazione del pacchetto. Se restituisce una versione inattesa, molto probabilmente hai più installazioni di Node sullo stesso host.

Installare una versione specifica di Node.js

In molti ambienti non basta “installare Node.js”: bisogna installare una versione precisa. Il motivo è semplice: un progetto può dipendere da feature di sintassi, API o behavior di runtime disponibili solo da una certa major in poi. Prima di cambiare versione, controlla sempre la compatibilità delle dipendenze del progetto.

Con NodeSource puoi puntare a una major specifica. Per esempio, per la serie 20:

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Questo approccio è utile quando vuoi standardizzare un parco macchine. Se gestisci più ambienti, annota la major in modo esplicito nella documentazione operativa, così eviti che un upgrade del sistema operativo o un reinstall faccia slittare la versione senza accorgertene.

Gestire più versioni con nvm quando il server non è il posto giusto per apt

nvm non sostituisce il repository di sistema: risolve un altro problema. Ti permette di installare più versioni di Node nella home dell’utente e cambiare contesto rapidamente. È comodo per sviluppo, test di compatibilità e ambienti dove non vuoi toccare i pacchetti globali.

Installazione tipica:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts
nvm use --lts

Il vantaggio è immediato: puoi passare da una major all’altra senza disinstallare nulla. Lo svantaggio è altrettanto chiaro: i servizi systemd, i cron e gli script non interattivi non erediteranno automaticamente l’ambiente della tua shell. Se usi nvm in un contesto server, devi progettare bene il modo in cui il servizio trova Node.

Problemi tipici dopo l’installazione

Il primo errore frequente è avere due installazioni attive. Succede quando prima hai usato il pacchetto Ubuntu, poi NodeSource, poi magari un binario manuale in /usr/local. Il risultato è confusione su versione e percorso eseguito. Per capire cosa sta davvero usando la shell:

type -a node
type -a npm

Il secondo problema è lo sfasamento tra utente e servizio. Un comando funziona nella tua shell, ma fallisce sotto systemd perché il servizio usa un PATH diverso. In quel caso, non correggere “a mano” l’applicazione: definisci il percorso completo del binario o imposta esplicitamente l’ambiente del servizio.

Un esempio di servizio che richiama il binario in modo esplicito:

[Service]
ExecStart=/usr/bin/node /opt/app/server.js
WorkingDirectory=/opt/app

Se il binario non è in /usr/bin/node, correggi il percorso dopo aver verificato con which node. Non dare per scontato che il servizio veda la stessa installazione della tua sessione SSH.

Aggiornare Node.js senza rompere i progetti

L’aggiornamento va trattato come un change controllato, non come un semplice apt upgrade. Prima verifica la release attuale e la compatibilità dei package. Poi fai un test in staging o in una shell isolata, soprattutto se il progetto usa dipendenze native o framework che hanno vincoli di versione.

node -v
npm ls --depth=0

Dopo l’upgrade, rilancia i test dell’applicazione e controlla i log. Se il progetto ha una pipeline CI, la verifica migliore è far passare lì l’aggiornamento prima di toccare il server. Su un host di produzione, il rollback ideale è reinstallare la major precedente o ripuntare al repository della versione precedente, sempre con una finestra di manutenzione chiara.

Quando conviene non installare nulla sul sistema

Ci sono casi in cui la risposta corretta non è “installo Node.js su Ubuntu 20.04”, ma “isolo Node dentro container o pipeline”. Se distribuisci più servizi con requisiti diversi, un runtime installato globalmente può diventare un punto di fragilità. In questi scenari, Docker o Podman riducono l’effetto collaterale di un upgrade e rendono più chiaro il legame tra app e runtime.

Se però gestisci un singolo servizio o un host applicativo classico, il pacchetto di sistema resta la soluzione più leggibile. La regola pratica è questa: meno versioni parallele hai bisogno di mantenere, più conviene usare apt; più variabilità devi assorbire, più conviene un gestore per utente o un container.

Checklist operativa finale

Prima di considerare chiusa l’installazione, verifica questi punti:

  • Versione corretta: node -v mostra la major prevista dal progetto.
  • Path coerente: which node e type -a node non mostrano binari inattesi.
  • npm disponibile: npm -v risponde e installa pacchetti senza errori.
  • Build tools presenti: build-essential è installato se servono moduli nativi.
  • Servizi allineati: i file systemd o gli script usano il percorso giusto del binario.

Se vuoi una macchina prevedibile, documenta anche la sorgente del pacchetto: repository usato, major installata e motivo della scelta. È un dettaglio che sembra banale finché non devi riprodurre un ambiente sei mesi dopo.

Assunzione operativa: su Ubuntu 20.04 non esistono vincoli particolari di hardening o proxy che impediscano l’accesso ai repository esterni; se presenti, vanno verificati prima connettività, DNS e policy di rete.