PHP 8.1 уже за пределами upstream-поддержки: что это значит для VPS
PHP 8.1 все еще встречается на Ubuntu 22.04 серверах, но upstream-поддержка ветки уже закончилась. Разбираемся, как планировать апгрейд без паники.
На VPS до сих пор часто можно встретить PHP 8.1. Это нормально: Ubuntu 22.04 вышла с PHP 8.1, многие панели и старые проекты на нем живут, а небольшие сайты вообще редко трогают runtime, пока все работает.
Но в 2026 году на PHP 8.1 уже нельзя смотреть как на “свежую” ветку. По upstream-календарю PHP эта версия дошла до конца жизненного цикла. Это не значит, что сайт завтра упадет. Но это значит, что апгрейд стоит занести в план, а не откладывать до момента, когда зависимость или пакетный репозиторий сломает деплой.
Важная оговорка про дистрибутивы
Есть нюанс: если PHP установлен из пакетов дистрибутива, например Ubuntu, то безопасность может поддерживаться через backport-патчи самого дистрибутива. Это не то же самое, что upstream-поддержка php.net.
Поэтому правильный вопрос звучит не “все ли срочно удалять?”, а так:
- откуда установлен PHP;
- кто поставляет security updates;
- есть ли сторонний PPA;
- какие версии поддерживают приложения;
- можно ли отдельно обновить CLI/FPM без миграции всей ОС.
Что проверить первым делом
На сервере:
php -v
apt-cache policy php8.1-fpm php8.2-fpm php8.3-fpm php8.4-fpm
systemctl status php8.1-fpmЕсли используется nginx, еще полезно найти привязку FastCGI:
grep -R "php8.1-fpm" -n /etc/nginxЭто покажет, какие сайты реально завязаны на конкретный сокет PHP-FPM.
Как обновляться без героизма
Для маленьких сайтов я бы не обновлял PHP “в пятницу вечером одной командой”. Нормальный план спокойнее:
- Снять список сайтов и PHP-зависимостей.
- Проверить, какие расширения реально нужны:
mbstring,curl,gd,xml,zip,mysql. - Поднять новую версию PHP-FPM параллельно.
- Переключить один тестовый vhost.
- Проверить логи nginx и PHP-FPM.
- Только потом переводить остальные сайты.
На nginx это обычно сводится к замене socket в fastcgi_pass, но именно “обычно”. Старые CMS, панели и самописные скрипты могут использовать несовместимые функции или строгие предупреждения.
Почему не стоит ждать EOL годами
Чем дольше сервер живет на старом runtime, тем дороже становится переход. Пакеты уходят из поддержки, библиотеки перестают тестироваться, документация новых версий становится все дальше от фактического состояния проекта.
Для личной VPS это особенно заметно: вроде бы всего пара сайтов, но рядом крутятся боты, API, phpMyAdmin, старые скрипты, cron-задачи. В итоге простой апгрейд превращается в археологию.
Практичный вывод
Если сайт маленький и PHP используется только для админки или пары скриптов, переход лучше планировать заранее. Не обязательно делать его сегодня ночью. Но стоит завести задачу: проверить совместимость с PHP 8.3 или 8.4, список расширений и vhost-конфиги.
Технический долг приятен только пока о нем не вспоминаешь. Runtime — как раз та часть, о которой лучше вспомнить до аварии.