1 19/10/2026 10 min

Su Debian 9 e Debian 10 PHP 8 non arriva dai repository ufficiali standard, quindi il punto non è “installare un pacchetto”, ma scegliere una sorgente affidabile e mantenere il sistema coerente. La strada più lineare, per un server LAMP o LEMP, è usare il repository di packages.sury.org, che offre PHP 8.x per le release Debian ancora supportate da quel ramo. Prima di toccare i pacchetti, conviene verificare la versione del sistema, capire se il web server usa mod_php o FPM e fare una copia della configurazione attuale: così il cambio resta reversibile.

La differenza pratica tra Debian 9 e 10 non è enorme, ma cambia il livello di rischio. Debian 10 gestisce meglio il salto a PHP 8 perché ha librerie più recenti; su Debian 9 è più facile incrociare dipendenze vecchie o estensioni non più compatibili. In entrambi i casi, se il sito è in produzione, la regola corretta è installare PHP 8 in parallelo alla versione esistente, testare il pool FPM o la configurazione Apache in staging o su un vhost dedicato, e solo dopo spostare il traffico.

Verifica iniziale: Debian, web server e PHP in uso

Il primo controllo serve a evitare un upgrade cieco. Devi sapere che release Debian stai usando, quale versione di PHP è attiva e se il sito passa da Apache, Nginx o entrambi. Se il comando restituisce già PHP 8, il lavoro potrebbe essere solo di allineamento dei moduli e dei pool FPM.

Controlla subito questi elementi:

cat /etc/debian_version
php -v
apache2 -v 2>/dev/null || true
nginx -v 2>&1 || true
systemctl status php7.3-fpm php7.4-fpm php8.0-fpm 2>/dev/null | sed -n '1,12p'

Se il server risponde con Debian 9 o 10 e hai una versione di PHP diversa da 8.x, il percorso è chiaro: repository esterno, installazione della nuova versione, verifica moduli, switch del runtime, test applicativo. Se invece il comando php -v mostra già una build 8.x, il problema potrebbe essere nel web server che punta ancora a un socket vecchio o in un path CLI diverso da quello del web.

Aggiungere il repository PHP senza sporcare il sistema

Su Debian 9 e 10 la procedura più comune è importare la chiave del repository e aggiungere la sorgente apt. Oggi è preferibile usare una chiave in formato dearmored in /usr/share/keyrings/, non il vecchio metodo con apt-key, che è deprecato. Questo riduce il rischio di confondere le chiavi di trust e rende più leggibile la configurazione.

Esegui questi passi in ordine:

  1. Installa i prerequisiti per HTTPS e gestione chiavi.
  2. Importa la chiave del repository in un keyring dedicato.
  3. Aggiungi la sorgente apt con firma esplicita.
  4. Aggiorna l’indice pacchetti e verifica che il repo sia visibile.
apt update
apt install -y apt-transport-https ca-certificates lsb-release wget gnupg2
wget -qO - https://packages.sury.org/php/apt.gpg | gpg --dearmor | tee /usr/share/keyrings/sury-php.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/sury-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/sury-php.list
apt update
apt-cache policy php8.0 php8.1 php8.2

Il comando apt-cache policy deve mostrare candidate versioni provenienti dal repository appena aggiunto. Se non compare nulla, il problema di solito è uno tra questi: distribuzione non supportata dal repo, repository scritto male nel file .list, errore TLS, oppure chiave non importata correttamente. Prima di andare avanti, conviene leggere l’errore di apt update e non “forzare” l’installazione.

Installare PHP 8 e i moduli davvero utili

Installare solo php8.0 o php8.1 spesso non basta. In pratica servono quasi sempre FPM, CLI e le estensioni che l’applicazione usa davvero: database, XML, mbstring, curl, zip, gd, intl, opcache. Il consiglio operativo è installare il minimo necessario, poi aggiungere i moduli in base ai log applicativi e ai requisiti del CMS o del framework.

Un set iniziale ragionevole è questo:

apt install -y php8.0-cli php8.0-fpm php8.0-common php8.0-opcache \ php8.0-mysql php8.0-xml php8.0-mbstring php8.0-curl php8.0-zip php8.0-gd php8.0-intl

Se l’applicazione usa PostgreSQL o SOAP, aggiungi i pacchetti corrispondenti. Se usi Redis o Imagick, installali solo se servono davvero: meno estensioni significa meno superficie di errore e meno manutenzione. Dopo l’installazione, verifica subito il binario e i moduli caricati.

php8.0 -v
php8.0 -m | sort
systemctl status php8.0-fpm --no-pager

Se il servizio FPM non parte, il primo controllo è il journal di systemd. Su Debian il file di configurazione di FPM è in genere sotto /etc/php/8.0/fpm/, e gli errori più comuni sono socket già occupato, permessi errati su pool o estensioni che causano crash all’avvio.

Apache: passare a PHP 8 con FPM o mod_php

Con Apache hai due strade: mod_php oppure PHP-FPM. Oggi, per quasi tutti i casi, FPM è la scelta migliore: separa il runtime dal processo web, gestisce meglio il carico e rende più semplice cambiare versione PHP senza toccare troppo Apache. Se stai aggiornando un server legacy, però, puoi trovarti con mod_php attivo e conviene pianificare il passaggio con cautela.

Per un’installazione pulita con FPM, abilita i moduli necessari e disattiva eventuale integrazione precedente se stai cambiando versione:

a2enmod proxy_fcgi setenvif
systemctl restart apache2

Poi collega il VirtualHost al socket di PHP 8.0. Un esempio essenziale:

<FilesMatch \.php$> SetHandler "proxy:unix:/run/php/php8.0-fpm.sock|fcgi://localhost/"
</FilesMatch>

Dopo la modifica, ricarica Apache e verifica che il socket esista davvero:

ls -l /run/php/php8.0-fpm.sock
apachectl configtest
systemctl reload apache2

Se usi ancora mod_php, il cambio di versione è meno elegante: devi installare il modulo corrispondente e disabilitare quello vecchio, mantenendo coerenza tra apache2 e la CLI. Su server con più versioni è facile creare confusione tra php, php8.0 e il modulo Apache caricato. In questi casi, il controllo decisivo è phpinfo() servito dal vhost giusto, non solo il comando da shell.

Nginx: PHP 8 con socket FPM e controllo del pool

Con Nginx il modello corretto è quasi sempre FPM. Il server web non esegue PHP direttamente: inoltra i file .php al socket del pool. Qui l’errore classico è puntare a un socket vecchio o dimenticare di aggiornare il blocco fastcgi_pass dopo il cambio versione.

Un blocco minimo, da adattare al tuo vhost, è questo:

location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.0-fpm.sock;
}

Il file di pool è in /etc/php/8.0/fpm/pool.d/www.conf o in un pool dedicato, se ne usi più di uno. In ambienti con più siti conviene creare pool separati per utente o per applicazione, così limiti il blast radius di un processo mal configurato. In più, puoi tarare per singolo sito parametri come pm.max_children, pm.max_requests e timeout.

Controlla sempre la sintassi e il servizio prima di riaprire il traffico:

nginx -t
systemctl restart php8.0-fpm
systemctl reload nginx

Se la pagina PHP restituisce download del file o 403, il problema non è PHP 8 in sé ma la catena Nginx-FPM: blocco location incompleto, fastcgi_param mancante, permessi del socket o root del sito errato. In questi casi il log di Nginx e quello di FPM danno quasi sempre la risposta nel giro di pochi minuti.

Compatibilità applicativa: cosa rompe davvero il salto a PHP 8

Il salto a PHP 8 non si misura solo sull’avvio del servizio. Il punto critico è la compatibilità del codice. Molte applicazioni funzionano bene appena installi il runtime, ma poi falliscono su funzioni deprecate, tipi più rigidi, errori di parsing o librerie esterne vecchie. Il rischio maggiore è nei CMS con plugin datati e nei framework legacy con codice scritto per PHP 7.2 o 7.3.

Prima del taglio definitivo, conviene eseguire un controllo a livello applicativo. Se hai Composer, lancia i test o almeno un autoload check. Se il progetto è WordPress, Joomla, Drupal o PrestaShop, verifica i requisiti ufficiali del core e dei moduli installati. Se non hai una pipeline, almeno controlla i log PHP e quelli del web server dopo il switch.

journalctl -u php8.0-fpm -n 50 --no-pager
tail -n 50 /var/log/nginx/error.log 2>/dev/null || true
tail -n 50 /var/log/apache2/error.log 2>/dev/null || true

Se compaiono errori di tipo undefined function, class not found o deprecated, il problema è quasi sempre una combinazione tra codice vecchio e librerie non aggiornate. Non conviene “curarlo” installando pacchetti a caso: prima individua il file o il plugin che genera l’errore, poi decidi se aggiornare, sostituire o disattivare il componente.

Impostazioni consigliate per un passaggio pulito

Una volta installato PHP 8, ci sono alcune impostazioni che vale la pena rivedere subito. Non è tuning fine, è igiene operativa. La prima è memory_limit: se è troppo bassa, l’applicazione fallisce in modo intermittente; se è troppo alta e hai molti worker, saturi la RAM. La seconda è upload_max_filesize e post_max_size, che spesso vengono dimenticate durante l’upgrade. La terza è date.timezone, perché un ambiente con timezone incoerente crea bug difficili da leggere nei log.

Puoi intervenire nel file di configurazione di PHP o in un file dedicato in /etc/php/8.0/fpm/conf.d/. Un approccio ordinato è creare una piccola configurazione locale invece di modificare il file principale, così il rollback è immediato.

; /etc/php/8.0/fpm/conf.d/99-local.ini
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
date.timezone = Europe/Rome

Dopo ogni modifica, riavvia solo il servizio interessato e non tutto il sistema. Il controllo minimo è questo:

systemctl restart php8.0-fpm
systemctl reload nginx || systemctl reload apache2
php8.0 -i | grep -E 'memory_limit|upload_max_filesize|post_max_size|date.timezone'

Strategia di rollback se qualcosa non torna

Il rollback deve essere banale. Se il sito non risponde, non devi ripensare l’architettura: devi tornare al runtime precedente o ripristinare il vecchio socket. Per questo è utile non rimuovere subito la versione precedente di PHP, almeno finché non hai validato i flussi critici. Il rollback tipico è puntare di nuovo Apache o Nginx al pool vecchio e riavviare il servizio web.

Prima di cambiare il riferimento, conserva una copia dei file toccati:

cp -a /etc/nginx/sites-available/example.conf /root/example.conf.bak.$(date +%F-%H%M)
cp -a /etc/php/8.0/fpm/pool.d/www.conf /root/www.conf.bak.$(date +%F-%H%M)

Se devi tornare indietro, ripristina il socket precedente nel vhost o nel blocco Apache, riavvia il servizio FPM corretto e verifica il codice HTTP della homepage e di una pagina PHP di test. Il controllo più semplice resta una pagina con phpinfo() o un endpoint interno che mostri la versione attiva, ma va rimossa subito dopo il test perché espone dettagli del sistema.

Verifica finale: versione, socket e risposta HTTP

Il test finale non è solo php -v. Devi verificare che la CLI, il web server e il pool FPM parlino della stessa versione. In altre parole: la shell deve vedere PHP 8, il processo web deve usare il socket di PHP 8 e il sito deve rispondere senza errori. Se uno dei tre elementi è scollegato, il sistema è ancora da considerare incompleto.

Checklist finale minima:

  1. php -v mostra una versione 8.x.
  2. systemctl status php8.0-fpm è attivo e senza restart loop.
  3. Il socket /run/php/php8.0-fpm.sock esiste ed è leggibile dal web server.
  4. curl -I http://localhost/ restituisce un 200 o il codice atteso dal sito.
  5. I log non mostrano errori PHP ripetuti dopo il traffico di test.
php -v
systemctl status php8.0-fpm --no-pager
ls -l /run/php/php8.0-fpm.sock
curl -I http://127.0.0.1/

Se tutto è coerente, puoi decidere se rimuovere la vecchia versione di PHP. Io lo faccio solo quando ho già verificato che nessun sito, cron o script CLI dipende più da quella release. Su server multi-sito, soprattutto con applicazioni diverse, è più prudente mantenere le versioni legacy finché non c’è una finestra di manutenzione dedicata. Assunzione: il server usa Debian 9 o 10, il repository esterno è consentito dalla policy interna e il passaggio a PHP 8 avviene con FPM su Apache o Nginx.