PHP 8.6 sur Debian 13 et Ubuntu 26.04 : installer PHP-FPM 8.6 et y basculer vos sites sans coupure

PHP 8.6 n'est fourni par aucune des deux distributions stables du moment : Debian 13 « Trixie » installe PHP 8.4 et Ubuntu 26.04 LTS installe PHP 8.5. Pour faire tourner php8.6-fpm sur un VPS ou un serveur dédié, il faut donc passer par le dépôt de paquets d'Ondřej Surý, qui installe chaque version de PHP à côté des autres. Ce guide montre comment installer PHP 8.6 et PHP-FPM 8.6 sur Debian 13 et Ubuntu 26.04 sans toucher à la version en place, reporter vos pools et votre php.ini, puis basculer vos sites de PHP 8.4 ou 8.5 vers PHP 8.6, un par un, sous Nginx comme sous Apache, avec un retour arrière en une commande. Il détaille aussi les deux pièges de update-alternatives qui font changer de version la commande php et le socket générique /run/php/php-fpm.sock dès l'installation.

Sources : annonces de php.net, instructions du dépôt packages.sury.org, page du PPA ondrej/php, empaquetage Debian de PHP et manuel d'update-alternatives.

PHP 8.6 au 12 novembre 2026 : ce qui est disponible

La dernière préversion publiée par php.net est la RC5 de PHP 8.6.0, sortie le 5 novembre 2026. L'annonce de cette RC5 fixe la version finale, PHP 8.6.0, au 19 novembre 2026. Une release candidate est une version de test : php.net rappelle sur sa page des préversions qu'elle ne doit pas servir en production. Le bon calendrier pour un serveur est donc d'installer PHP 8.6 dès maintenant à côté de la version de production, de tester vos sites dessus, puis de basculer après la sortie de la version finale. Le calendrier complet du cycle et les dépréciations de PHP 8.6 sont détaillés dans notre article PHP 8.6 sort le 19 novembre : préparez vos VPS et vos panels.

Point important pour Ubuntu 26.04 : le PPA ppa:ondrej/php que beaucoup de tutoriels citent ne sert plus que Ubuntu 22.04 et 24.04. Sa page Launchpad indique que, pour Ubuntu Resolute, la source de référence est désormais packages.sury.org/php, le dépôt utilisé pour Debian. Sur Debian 13 comme sur Ubuntu 26.04, la procédure est donc la même. Si votre serveur tourne encore sous Debian 12 ou Ubuntu 24.04, faites d'abord la mise à niveau de la distribution avec nos guides pour migrer de Debian 12 vers Debian 13 ou migrer d'Ubuntu 24.04 vers 26.04 LTS, puis revenez ici.

Comment plusieurs versions de PHP-FPM cohabitent

Sur Debian et Ubuntu, chaque version de PHP vit dans ses propres paquets (php8.4-fpm, php8.5-fpm, php8.6-fpm), ses propres fichiers et son propre service systemd. Installer PHP 8.6 n'écrase donc rien : c'est ce qui permet de basculer un site à la fois et de revenir en arrière instantanément.

Quelques définitions pour suivre la suite :

• PHP-FPM (FastCGI Process Manager) : le service qui exécute le code PHP pour le serveur web. Nginx ou Apache lui transmettent chaque requête .php par le protocole FastCGI ;
• pool : un groupe de processus PHP-FPM avec son utilisateur système, son socket et ses limites. Un fichier par pool dans pool.d/, le pool par défaut s'appelle www ;
• socket Unix : le fichier spécial, dans /run/php/, sur lequel un pool attend les requêtes. Changer la version de PHP d'un site revient à changer le socket vers lequel le serveur web l'envoie ;
• update-alternatives : l'outil de Debian qui choisit vers quelle version pointe un nom générique comme /usr/bin/php. Il intervient deux fois ici, et c'est la source des mauvaises surprises.

Ces deux mécanismes globaux sont les seuls qui peuvent changer de version sans que vous l'ayez demandé :

1. La commande php : chaque paquet phpX.Y-cli enregistre php, phar et phar.phar auprès d'update-alternatives avec une priorité égale à son numéro de version (84 pour 8.4, 86 pour 8.6). En mode automatique, la version la plus récente gagne : dès que php8.6-cli est installé, vos tâches cron, scripts et commandes Composer qui appellent php passent en PHP 8.6.
2. Le socket générique /run/php/php-fpm.sock : au démarrage de chaque service phpX.Y-fpm, l'unité systemd lance un petit script (php-fpm-socket-helper) qui enregistre le socket du pool www comme alternative php-fpm.sock, là encore avec la priorité 84, 85 ou 86. Un site configuré avec fastcgi_pass unix:/run/php/php-fpm.sock passe donc en PHP 8.6 dès le premier démarrage de php8.6-fpm. Ce comportement est le même dans l'empaquetage Debian de PHP 8.4 et dans celui de la branche 8.6 dont sont issus les paquets Sury.

Faire l'inventaire avant d'installer

Avant d'ajouter le moindre dépôt, notez l'état actuel du serveur. Ces commandes ne modifient rien :

php -v
update-alternatives --display php
update-alternatives --display php-fpm.sock
ls -l /run/php/
systemctl list-units 'php*-fpm.service'
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'

Repérez ensuite quel socket chaque site utilise, pour savoir lesquels sont branchés sur le socket générique :

sudo grep -rn "fastcgi_pass" /etc/nginx/ 2>/dev/null
sudo grep -rn "SetHandler" /etc/apache2/ 2>/dev/null
ls /etc/apache2/mods-enabled/ 2>/dev/null | grep -E "php|mpm"

Enfin, sauvegardez la configuration. Une archive de /etc/php, /etc/nginx ou /etc/apache2 suffit pour revenir à l'état de départ en cas de fausse manœuvre :

sudo tar czf /root/config-avant-php86-$(date +%F).tar.gz /etc/php /etc/nginx /etc/apache2 2>/dev/null

Pour une sauvegarde complète hors du serveur, notre guide pour sauvegarder un VPS avec rsync vers un serveur distant donne la méthode, et celui sur les sauvegardes MySQL avec mysqldump couvre la base de données de vos sites.

Ajouter le dépôt Sury sur Debian 13 et Ubuntu 26.04

Les commandes sont celles publiées par le mainteneur dans le README.txt du dépôt. Elles fonctionnent à l'identique sur les deux distributions : lsb_release -sc renvoie trixie sur Debian 13 et resolute sur Ubuntu 26.04, deux noms pour lesquels le dépôt publie bien une distribution. À lancer en root ou avec sudo :

sudo apt-get update
sudo apt-get -y install lsb-release ca-certificates curl
sudo curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt-get update

Sur Ubuntu 26.04, si un ancien fichier du PPA ondrej/php traîne dans /etc/apt/sources.list.d/ après une mise à niveau, supprimez-le : le PPA ne publie rien pour Resolute et ne ferait que générer des erreurs à chaque apt update.

À savoir avant d'aller plus loin : le dépôt Sury ne contient pas seulement PHP 8.6. Il publie aussi les branches déjà fournies par votre distribution, dans des versions plus récentes. Sur Debian 13, au 12 novembre 2026, le paquet officiel php8.4-fpm est en 8.4.24-1~deb13u1, celui de Sury en 8.4.27-2+0~deb.sury.org.1+debian13. Le prochain apt upgrade remplacera donc vos paquets PHP 8.4 Debian par ceux de Sury. Vérifiez ce qui va changer avant de lancer la mise à jour :

apt-cache policy php8.4-fpm
apt list --upgradable 2>/dev/null | grep -i php

Ce remplacement n'a rien d'anormal (les paquets Sury sont construits à partir du même empaquetage que ceux de Debian, maintenu par l'équipe PHP de Debian), mais il redémarre PHP-FPM : faites-le dans un créneau calme plutôt qu'en pleine soirée de forte affluence.

Installer php8.6-fpm et les extensions de vos sites

Le plus fiable est de reprendre exactement les extensions installées pour votre version actuelle. Cette commande liste les paquets php8.4-* installés et les traduit en php8.6-* dans un fichier que vous pouvez relire (remplacez 8.4 par 8.5 sur Ubuntu 26.04) :

dpkg -l 'php8.4-*' | awk '/^ii/ {print $2}' | sed -e 's/:.*//' -e 's/^php8\.4-/php8.6-/' > /root/paquets-php86.txt
cat /root/paquets-php86.txt
sudo xargs -a /root/paquets-php86.txt apt-get install

Si apt signale un paquet introuvable, c'est en général une extension PECL (Redis, Imagick, APCu, igbinary) : ces extensions sont construites à partir de paquets sources séparés et peuvent arriver plus tard que PHP lui-même pour une nouvelle version. Vérifiez sa disponibilité avec apt-cache policy php8.6-redis, retirez la ligne du fichier et relancez. Sur un serveur neuf, ou pour une application web classique (WordPress, Laravel, phpMyAdmin), voici la liste de base, entièrement disponible en RC5 pour Debian 13 et Ubuntu 26.04 :

sudo apt-get install php8.6-cli php8.6-fpm php8.6-common php8.6-mysql php8.6-mbstring \
  php8.6-xml php8.6-curl php8.6-zip php8.6-gd php8.6-intl php8.6-bcmath
php8.6 -v
systemctl status php8.6-fpm --no-pager

Juste après l'installation, remettez la version de production par défaut. D'abord la commande php (et phar), pour que cron, Composer et vos scripts restent sur PHP 8.4 :

sudo update-alternatives --set php /usr/bin/php8.4
sudo update-alternatives --set phar /usr/bin/phar8.4
sudo update-alternatives --set phar.phar /usr/bin/phar.phar8.4
php -v

Ensuite le socket générique, si l'inventaire a montré qu'un site l'utilise :

update-alternatives --display php-fpm.sock
sudo update-alternatives --set php-fpm.sock /run/php/php8.4-fpm.sock
ls -l /run/php/php-fpm.sock

Avec --set, le groupe passe en mode manuel : d'après le manuel d'update-alternatives, l'outil conserve alors le choix de l'administrateur au lieu de suivre la priorité la plus haute, sauf si le lien est cassé (par exemple si le service php8.4-fpm est arrêté). La solution durable reste de ne jamais utiliser /run/php/php-fpm.sock dans vos configurations et d'écrire le socket versionné de chaque site. Si vous avez installé php8.6-dev pour compiler une extension, faites de même pour phpize et php-config, enregistrés de la même manière.

Côté serveur web, rien n'a encore changé : sur une machine où Apache est installé, le script d'installation de php8.6-fpm n'active rien et se contente d'afficher les commandes à lancer ; sous Nginx, aucun site n'envoie de requête au nouveau socket /run/php/php8.6-fpm.sock tant que vous ne l'avez pas écrit dans sa configuration.

Reporter vos pools et vos réglages php.ini

Le php.ini de PHP 8.6 part de la configuration de production par défaut. Pour retrouver les réglages que vous aviez modifiés en 8.4 (memory_limit, upload_max_filesize, post_max_size, max_execution_time, date.timezone, disable_functions...), comparez votre fichier au modèle livré avec le paquet :

diff /usr/lib/php/8.4/php.ini-production /etc/php/8.4/fpm/php.ini
find /etc/php/8.4/fpm/conf.d/ -type f

La première commande affiche uniquement vos modifications ; la seconde liste vos fichiers .ini ajoutés à la main (ceux des extensions sont des liens symboliques vers /etc/php/8.4/mods-available/, ils n'apparaissent pas) ; reportez-les ligne par ligne dans /etc/php/8.6/fpm/php.ini plutôt que de copier le fichier entier, car le php.ini d'une nouvelle version peut contenir de nouvelles directives ou des valeurs par défaut différentes. Mieux encore, placez vos réglages dans un fichier à vous, par exemple /etc/php/8.6/fpm/conf.d/99-monsite.ini : il survit aux mises à jour du paquet et se recopie facilement d'une version à l'autre.

Pour les pools, copiez chaque fichier personnalisé de /etc/php/8.4/fpm/pool.d/ vers /etc/php/8.6/fpm/pool.d/, puis changez le nom du pool et le chemin du socket. Deux services PHP-FPM ne peuvent pas écouter sur le même socket : si votre pool 8.4 utilise listen = /run/php/monsite.sock et que vous le recopiez tel quel, le premier service démarré prend le socket et le second échoue.

sudo cp /etc/php/8.4/fpm/pool.d/monsite.conf /etc/php/8.6/fpm/pool.d/monsite.conf
sudo nano /etc/php/8.6/fpm/pool.d/monsite.conf

[monsite-86]
user = monsite
group = monsite
listen = /run/php/php8.6-monsite.sock
listen.owner = www-data
listen.group = www-data
pm = ondemand
pm.max_children = 10

Testez la configuration avant de redémarrer le service, puis vérifiez que le nouveau socket existe :

sudo php-fpm8.6 -t
sudo systemctl restart php8.6-fpm
ls -l /run/php/

Gardez le même utilisateur système (user, group) que le pool 8.4 : les fichiers du site lui appartiennent déjà, et les deux versions pourront servir le même dossier pendant la période de test. Pour le durcissement du pool (utilisateur dédié par site, open_basedir, disable_functions), suivez notre guide installer PHP-FPM sécurisé sur un VPS Linux : les réglages sont identiques en 8.6, seuls les chemins changent.

Basculer un site Nginx vers PHP-FPM 8.6

Sous Nginx, la version de PHP d'un site tient en une ligne : la directive fastcgi_pass de son bloc server. Le changement se fait par un simple rechargement, sans coupure : Nginx termine les requêtes en cours avec l'ancien socket et envoie les suivantes au nouveau.

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

Pour un site qui utilisait le pool www de PHP 8.4, une substitution suffit, suivie du test de configuration :

sudo sed -i 's#/run/php/php8.4-fpm.sock#/run/php/php8.6-fpm.sock#' /etc/nginx/sites-available/monsite.conf
sudo nginx -t && sudo systemctl reload nginx

Pour un pool dédié, remplacez le socket par celui que vous avez défini plus haut (/run/php/php8.6-monsite.sock). Commencez par un sous-domaine de préproduction qui sert une copie du site : c'est la méthode la plus sûre tant que PHP 8.6 est en RC. Si vous débutez avec la structure des blocs server, notre guide Nginx en reverse proxy sur un VPS Linux l'explique, et celui sur Certbot et Let's Encrypt couvre le certificat HTTPS du sous-domaine.

Basculer un site Apache vers PHP-FPM 8.6

Sous Apache, trois situations se présentent.

1. Apache utilise déjà PHP-FPM pour tous les sites (configuration php8.4-fpm activée). Le paquet php8.6-fpm fournit un fichier /etc/apache2/conf-available/php8.6-fpm.conf qui envoie les fichiers .php, .phtml et .phar au socket /run/php/php8.6-fpm.sock. On désactive l'ancien, on active le nouveau :

sudo a2disconf php8.4-fpm
sudo a2enconf php8.6-fpm
sudo apachectl configtest && sudo systemctl reload apache2

2. Vous voulez basculer un seul site. Ajoutez un bloc FilesMatch dans le VirtualHost concerné. La documentation d'Apache précise que les sections placées dans un VirtualHost s'appliquent après celles de la configuration principale : ce réglage l'emporte donc sur la configuration globale, et les autres sites restent en 8.4.

<VirtualHost *:443>
    ServerName preprod.monsite.fr
    DocumentRoot /var/www/monsite
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php8.6-fpm.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

3. Apache tourne encore avec mod_php (paquet libapache2-mod-php8.4). Les fichiers de configuration FPM livrés par Debian ne s'appliquent que si mod_php n'est pas chargé : il faut donc d'abord quitter mod_php, ce qui impose aussi de changer de MPM, mod_php exigeant mpm_prefork :

sudo a2dismod php8.4 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.6-fpm
sudo apachectl configtest && sudo systemctl restart apache2

Ici, c'est un restart et non un reload, car le changement de MPM l'exige. Prévoyez quelques secondes d'interruption, et faites ce passage à PHP-FPM d'abord avec la version 8.4 si vous voulez séparer les deux changements : a2enconf php8.4-fpm à la place de la dernière commande.

Ligne de commande, cron et Composer

Le serveur web n'est pas le seul à exécuter du PHP. Les tâches planifiées (wp-cron appelé par la crontab, artisan schedule:run de Laravel, scripts de maintenance), les workers lancés par systemd et Composer utilisent la commande php, donc l'alternative réglée plus haut. Deux approches :

• Figer chaque tâche sur sa version : écrivez le chemin complet (/usr/bin/php8.4 ou /usr/bin/php8.6) dans la crontab et dans la ligne ExecStart des unités systemd, puis sudo systemctl daemon-reload. C'est la méthode recommandée sur un serveur qui héberge plusieurs applications ;
• Basculer la commande php pour tout le serveur, une fois tous les sites passés en 8.6 : sudo update-alternatives --set php /usr/bin/php8.6, ou sudo update-alternatives --auto php pour revenir au mode automatique (version la plus récente).

Pour Composer, lancez-le avec la version du site visé, ce qui vérifie au passage que les dépendances acceptent PHP 8.6 :

cd /var/www/monsite
php8.6 /usr/local/bin/composer install --no-dev --dry-run
php8.6 /usr/local/bin/composer check-platform-reqs

Le cas des panels de serveurs de jeu mérite une attention particulière : ni Pterodactyl ni Pelican ne documentent encore PHP 8.6. Laissez leur pool, leur crontab et leur worker de file d'attente (pteroq pour Pterodactyl) sur une version documentée, avec le chemin complet du binaire, même si le reste du serveur passe en 8.6. Le détail est dans notre guide pour installer Pterodactyl ; pour la syntaxe des tâches planifiées, voir planifier des tâches avec cron et les timers systemd.

Vérifier que le site tourne bien en PHP 8.6

Ne vous fiez pas à php -v : il indique la version de la ligne de commande, pas celle du site. Pour savoir quelle version de PHP-FPM sert réellement une page, déposez un fichier de test temporaire qui affiche la version et la SAPI :

echo '<?php echo PHP_VERSION, " ", PHP_SAPI, "\n";' | sudo tee /var/www/monsite/version-php.php
curl -s https://preprod.monsite.fr/version-php.php
sudo rm /var/www/monsite/version-php.php

La réponse attendue tant que PHP 8.6 est en préversion est 8.6.0RC5 fpm-fcgi. Supprimez le fichier tout de suite : exposer la version exacte de PHP n'aide que les attaquants. Surveillez ensuite les journaux de PHP-FPM 8.6 et du serveur web pendant que vous parcourez le site :

sudo journalctl -u php8.6-fpm -f
sudo tail -f /var/log/php8.6-fpm.log
sudo tail -f /var/log/nginx/error.log

Pour relever les dépréciations propres à PHP 8.6, qui n'apparaissent pas avec le error_reporting par défaut de production, la méthode (journal dédié, error_reporting = E_ALL sur l'instance de test) est décrite dans notre article sur la sortie de PHP 8.6.

Revenir en arrière, puis retirer l'ancienne version

Tant que php8.4-fpm reste installé et démarré, le retour arrière est immédiat : remettez l'ancien socket dans la configuration du site et rechargez le serveur web.

sudo sed -i 's#/run/php/php8.6-fpm.sock#/run/php/php8.4-fpm.sock#' /etc/nginx/sites-available/monsite.conf
sudo nginx -t && sudo systemctl reload nginx

Sous Apache, l'opération inverse est a2disconf php8.6-fpm puis a2enconf php8.4-fpm, ou la suppression du bloc FilesMatch ajouté au VirtualHost. Ne désinstallez donc pas l'ancienne version dans la foulée. Quand tous les sites, tâches cron et workers tournent en 8.6 depuis plusieurs jours sans erreur, vérifiez qu'aucun processus n'utilise plus PHP 8.4, puis arrêtez son service :

sudo grep -rn "php8.4" /etc/nginx/ /etc/apache2/ /etc/cron* /etc/systemd/system/ 2>/dev/null
sudo crontab -l -u www-data 2>/dev/null | grep php
sudo systemctl disable --now php8.4-fpm

La désinstallation (sudo apt-get purge 'php8.4-*') peut attendre : PHP 8.4 reçoit des correctifs de sécurité de php.net jusqu'au 31 décembre 2028, rien ne presse. Le jour où vous la lancez, relisez la liste des paquets qu'apt propose de supprimer avant de valider. Gardez aussi en tête que les correctifs de PHP 8.6 viendront du dépôt Sury et non de la distribution : la configuration par défaut d'unattended-upgrades, décrite dans notre guide pour automatiser les mises à jour de sécurité, ne les installera pas. Pour l'ajouter, créez un fichier à part avec l'origine déclarée dans le fichier Release du dépôt (deb.sury.org), puis contrôlez le résultat à blanc :

echo 'Unattended-Upgrade::Origins-Pattern { "origin=deb.sury.org"; };' | sudo tee /etc/apt/apt.conf.d/51sury-php
sudo unattended-upgrade --dry-run --debug 2>&1 | grep -i sury

Le dépôt Sury ne distingue pas les mises à jour de sécurité des autres : cette ligne installe automatiquement toutes ses nouvelles versions, PHP 8.4 compris. Sur un serveur où une régression coûterait cher, préférez une vérification hebdomadaire avec apt list --upgradable.

Récapitulatif : les commandes de la bascule

Sur Ubuntu 26.04, remplacez simplement 8.4 par 8.5 dans chaque commande. Et une fois PHP 8.6.0 sortie le 19 novembre, il suffira d'un sudo apt-get update && sudo apt-get upgrade, dès que le dépôt Sury aura publié les paquets de la version finale, pour passer de la RC à la version stable, suivi d'un systemctl restart php8.6-fpm si apt ne l'a pas fait. Pour tester PHP 8.6 sans risque à côté de vos serveurs de production, un VPS Linux de préproduction suffit ; pour plusieurs sites, une base de données et un panel sur la même machine, un serveur dédié laisse de la marge.