Чому я вирішила перейти на PHP 8.5
Раніше я вже стикалася із ситуацією, коли серверний провайдер не пропонував навіть PHP 8.4, пояснюючи це тим, що версія ще недостатньо стабільна.
Але доступність версії в панелі хостингу та офіційний статус PHP - це різні речі. Провайдер може довше тестувати власні образи, модулі, панель керування або процес оновлення серверів. Це не робить офіційний стабільний реліз нестабільним.
Якщо хостинг ще не пропонує нову версію PHP, це може бути обмеженням його інфраструктури, а не самої мови.
PHP 8.5 стала стабільною 20 листопада 2025 року. На момент мого оновлення це вже не preview і не release candidate, а підтримувана стабільна гілка, яка встигла отримати кілька patch-релізів.
Я використовую власний VPS, тому надалі зможу сама встановити потрібну версію PHP та керувати PHP-FPM. Але серверне оновлення буде окремим етапом.
Спочатку я вирішила підготувати локальне середовище та перевірити власний Laravel-пакет. Це дозволяє знайти проблеми до змін на сервері.
Що саме я оновлювала
У межах цього етапу я:
встановила PHP 8.5 локально;
оновила Composer;
оновила Laradock;
зберегла PHP 8.3 як основну версію;
додала окремі контейнери для PHP 8.4 і PHP 8.5;
перенесла локальні extra hosts;
оновила конфігурацію Xdebug;
перевірила Nginx upstream для різних версій PHP;
підняла мінімальну версію власного Laravel-пакета з PHP 8.4 до PHP 8.5;
запустила повний набір автоматизованих перевірок.
Встановлення PHP 8.5 локально
На моїй Ubuntu-системі PHP 8.4 уже була основною CLI-версією, а пакети PHP 8.5 були доступні через підключений репозиторій.
Я встановила PHP 8.5 разом із розширеннями, необхідними для Composer, Laravel і тестів, не видаляючи попередні версії.
sudo apt install \ php8.5-cli \ php8.5-common \ php8.5-curl \ php8.5-mbstring \ php8.5-xml \ php8.5-zip \ php8.5-intlСпочатку PHP 8.5 залишалася окремою командою php8.5. Після перевірки я перемкнула системну CLI-версію через update-alternatives.
sudo update-alternatives --config php php -vPHP 8.5.9 (cli)Оновлення Composer
Composer був установлений глобально і працював із PHP 8.4 та PHP 8.5, але сама версія Composer була застарілою. Я оновила її до стабільної версії перед зміною package requirements.
sudo -H php8.5 "$(command -v composer)" self-update --stable composer --versionComposer version 2.10.2PHP version 8.5.9Кілька версій PHP у Laradock
До оновлення основний Laradock працював на PHP 8.3. Для PHP 8.4 я раніше додала окремий php-fpm service вручну.
Я не хотіла змінювати основну версію для всіх проєктів. Частина застосунків усе ще використовує PHP 8.3, частина - PHP 8.4, а новий пакет має працювати на PHP 8.5.
Тому я оновила Laradock до актуальнішої версії з підтримкою паралельних PHP services і налаштувала три незалежні середовища.
php-fpm → PHP 8.3workspace → PHP 8.3 php-fpm-84 → PHP 8.4workspace-84 → PHP 8.4 php-fpm-85 → PHP 8.5workspace-85 → PHP 8.5Multi-PHP overlay
Основна версія залишилася в Laradock .env:
PHP_VERSION=8.3COMPOSE_FILE=docker-compose.yml:docker-compose.multi-php.yml:docker-compose.local.ymlДодатковий Compose-файл визначає окремі workspace та php-fpm services для PHP 8.4 і PHP 8.5. Вони успадковують основну конфігурацію Laradock, але збираються з іншою версією PHP.
services: php-fpm-85: extends: file: ../php-fpm/compose.yml service: php-fpm build: context: ../php-fpm args: - LARADOCK_PHP_VERSION=8.5 workspace-85: extends: file: ../workspace/compose.yml service: workspace build: context: ../workspace args: - LARADOCK_PHP_VERSION=8.5Збереження локальної конфігурації
Оновити Laradock було недостатньо. У старій конфігурації вже були локальні домени, Nginx sites, Xdebug та окремі налаштування MySQL.
Я не переносила всі старі файли поверх нових. Спочатку порівняла зміни, залишила актуальні upstream-конфігурації та винесла власні налаштування в окремий локальний Compose overlay.
Extra hosts для всіх PHP-контейнерів
Мої локальні проєкти використовують домени з .test. Вони мають резолвитися не лише в основному workspace, а й у PHP 8.4, PHP 8.5, PHP-FPM і Nginx.
Тому однаковий список extra_hosts був доданий до всіх потрібних services через docker-compose.local.yml.
services: workspace: extra_hosts: *local-extra-hosts workspace-84: extra_hosts: *local-extra-hosts workspace-85: extra_hosts: *local-extra-hosts php-fpm: extra_hosts: *local-extra-hosts php-fpm-84: extra_hosts: *local-extra-hosts php-fpm-85: extra_hosts: *local-extra-hosts nginx: extra_hosts: *local-extra-hostsПеревірка всередині контейнерів підтвердила, що локальний домен доступний і з PHP 8.4, і з PHP 8.5.
docker compose run --rm workspace-84 sh -lc \ 'php -v | head -n 1 && getent hosts icanup.test' docker compose run --rm workspace-85 sh -lc \ 'php -v | head -n 1 && getent hosts icanup.test'PHP 8.4.24172.17.0.1 icanup.test PHP 8.5.9172.17.0.1 icanup.testNginx і PHP-FPM upstream
Після перейменування services старі Nginx-конфігурації все ще посилалися на php-fpm-8.4. Я оновила їх на нову назву php-fpm-84.
Основний upstream залишився на PHP 8.3, а проєкти на PHP 8.4 використовують окремий service.
fastcgi_pass php-fpm:9000;fastcgi_pass php-fpm-84:9000;PHP 8.5 service уже підготовлений, але конкретний проєкт буде переведено на нього лише після оновлення та перевірки самого застосунку.
Оновлення Xdebug
Під час перенесення конфігурації я помітила, що новий файл містив старі параметри Xdebug 2. Я залишила актуальні налаштування Xdebug 3 із портом 9003 та запуском лише за тригером.
xdebug.mode=debugxdebug.start_with_request=trigger xdebug.client_host=host.docker.internalxdebug.client_port=9003xdebug.discover_client_host=0 xdebug.idekey=PHPSTORMОновлення baseline Laravel-пакета
Після підготовки середовища я повернулася до власного Laravel-пакета локалізації.
Пакет ще не має стабільного публічного релізу. Тому зараз кращий момент для підняття мінімальної версії PHP, ніж після того, як інші проєкти почнуть залежати від уже опублікованого контракту.
"require": { "php": "^8.4"}"require": { "php": "^8.5"}Важливо, що вимога ^8.4 уже дозволяла запуск пакета на PHP 8.5. Зміна на ^8.5 означає інше: PHP 8.5 тепер є мінімальною офіційно підтримуваною версією пакета.
Разом із composer.json я оновила:
README з актуальними requirements;
CHANGELOG із новим мінімальним baseline;
локальне середовище розробки;
Composer platform verification.
Чи довелося переписувати код
Ні. Спочатку я запустила пакет на PHP 8.5 без змін у composer.json. Це була контрольна перевірка фактичної сумісності.
Після успішного результату я підняла мінімальну вимогу до ^8.5 і повторила всі перевірки.
composer validate --strictcomposer check-platform-reqscomposer checkPHP 8.5.9Composer 2.10.2Laravel Pint PASSPHPStan No errorsPHPUnit 116 tests, 189 assertionsЦе не означає, що будь-який PHP-проєкт можна оновлювати лише зміною version constraint.
Офіційна документація PHP рекомендує перевіряти backward incompatible changes і deprecated features перед переходом. У моєму випадку тестове покриття показало, що пакет не використовує проблемні конструкції та зберігає поточну поведінку.
Що в результаті
Після оновлення:
системний PHP CLI працює на PHP 8.5;
Composer працює через PHP 8.5;
основні Laradock-проєкти можуть залишатися на PHP 8.3;
окремі проєкти можуть використовувати PHP 8.4;
PHP 8.5 готова як окремий workspace і PHP-FPM service;
локальні домени доступні в усіх контейнерах;
Nginx бачить усі три PHP-FPM services;
власний Laravel-пакет вимагає PHP 8.5;
повний набір тестів проходить без змін у коді.
Оновлення runtime не завжди означає переписування застосунку. Часто головна робота - це підготувати середовище, зберегти сумісність інших проєктів і підтвердити результат тестами.
Висновок
Я не переходила на PHP 8.5 у день її релізу. Але й не хотіла чекати, доки кожен хостинг або готовий серверний образ додасть її до своєї панелі.
Для мене правильним моментом стало поєднання трьох умов: стабільна підтримувана версія PHP, власний пакет до першого публічного релізу та можливість перевірити все локально без впливу на інші проєкти.
У результаті PHP 8.5 стала новим baseline пакета, а Laradock тепер підтримує PHP 8.3, 8.4 і 8.5 паралельно.
Наступний окремий етап - оновлення самого Laravel-застосунку та встановлення PHP 8.5 на VPS. До сервера я перейду вже з готовим і перевіреним локальним середовищем.
