Календар оновлень Laravel: чому проєкт дорожчає без жодної нової фічі

Коротка відповідь: у Laravel немає LTS-версій. За офіційною політикою кожна мажорна версія отримує 18 місяців виправлення помилок і 24 місяці виправлень безпеки, а нова мажорна виходить приблизно раз на рік. Тобто ваш проєкт має жорсткий календар оновлень, який настане незалежно від того, чи додаєте ви щось нове. Нижче конкретні дати, приклад на живих версіях і те, як це рахувати в бюджеті.

Я займаюсь інфраструктурою й регулярно чую від замовників одну й ту саму фразу: «сайт працює, навіщо його чіпати». Резонно. Проблема лише в тому, що фреймворк і мова під ним живуть за власним розкладом, і цей розклад ви не контролюєте. Найдорожчі оновлення це ті, які відкладали три роки.

Правило, яке варто знати до старту проєкту

Офіційна політика Laravel коротка й однакова для всіх версій: виправлення помилок 18 місяців, виправлення безпеки 24 місяці від дати релізу мажорної версії.

І тут головне, чого не знає більшість замовників: окремих LTS-версій у Laravel більше немає. Колись довша підтримка існувала, зараз усі мажорні версії живуть за одним вікном. Тобто стратегія «візьмемо версію з довгою підтримкою й забудемо на пʼять років» тут не працює в принципі.

Мажорні версії виходять приблизно раз на рік, зазвичай на початку весни. Порахуйте самі: якщо реліз щороку, а безпека тримається два роки, ви можете відставати максимум на одну версію. Далі ви залишаєтесь без виправлень безпеки.

Як це виглядає на живих датах

Щоб не було абстракції, ось реальні дати з офіційної документації, актуальні на серпень 2026.

Подивіться на другий рядок. Laravel 12 вийшов у лютому 2025, а виправлення помилок для нього закінчились 13 серпня 2026. Це сталося щойно. Якщо ваш проєкт на дванадцятій версії, з цього моменту ви отримуєте тільки латки безпеки, а звичайні баги вже ніхто не полагодить.

Тепер перший рядок. Laravel 11 повністю вийшов з підтримки в березні 2026. Проєкт на ньому не отримує вже нічого. Включно з безпекою.

Друга шестерня: PHP під фреймворком

Про це забувають ще частіше, хоча ризик той самий. Сама мова теж має розклад: кожна гілка PHP отримує два роки активної підтримки плюс ще рік лише виправлень безпеки, разом три роки.

Тобто календарів два. І вони не збігаються. Нова версія Laravel вимагає свіжих версій PHP, а стара версія PHP рано чи пізно перестає отримувати латки. Класична ситуація: команда хоче оновити фреймворк, але на сервері стоїть PHP, який фреймворк уже не підтримує, і оновлення перетворюється на два проєкти замість одного.

Чому відкладене оновлення дорожчає нелінійно

Тут працює просте правило, яке варто пояснити бухгалтерії. Оновлення на одну мажорну версію це керована робота. Читаєте перелік змін, правите несумісне, ганяєте тести.

Оновлення через три версії це вже не сума трьох робіт. Це переписування, бо за три роки змінюються не лише сам фреймворк, а й пакети, від яких ви залежите. Кожен сторонній пакет має власний розклад сумісності, і чим далі ви відстали, тим більша ймовірність, що потрібного пакета під нову версію просто немає й доведеться шукати заміну або писати своє.

Дешева стратегія це щорічні маленькі кроки. Дорога стратегія звучить як «оновимо, коли зламається», і платити за неї доводиться одразу всім накопиченим боргом.

Що з цим робити на практиці

Кілька речей, які варто закласти ще на етапі договору.

Знайте свою дату. Зафіксуйте, на якій версії Laravel і PHP ви живете й коли для них закінчуються вікна. Це п'ять хвилин роботи, а ясності дає більше, ніж будь-який аудит.

Закладіть оновлення в річний бюджет окремим рядком. Не як ризик, а як планову роботу, бо дата настане в календарі незалежно від вашого бажання.

Тримайте залежності свіжими. Більшість болю при оновленні дає не сам фреймворк, а сторонні пакети. Дешевше оновлювати їх регулярно, ніж розгрібати десятки конфліктів одночасно.

Майте тести хоча б на критичні сценарії. Без них кожне оновлення це ручна перевірка всього сайту, і саме тому команди бояться оновлюватись.

Питайте підрядника про план оновлень до підпису. Якщо на питання «як ви оновлюєте версії й що це коштує» відповідають розпливчасто, це сигнал.

Часті питання

Чи можна просто не оновлюватись? Можна, поки не закінчилось вікно безпеки. Після цього ви лишаєтесь з відомими вразливостями, які вже ніхто не закриє, а це питання не зручності, а ризику.

Скільки часу займає оновлення на одну версію? Залежить від розміру проєкту й кількості сторонніх пакетів, але це планова робота. Головне, що вона в рази дешевша, ніж стрибок через кілька версій.

Чи є у Laravel версія з довгою підтримкою? Ні. Окремих LTS-версій більше немає, усі мажорні версії живуть за однаковим вікном: 18 місяців на помилки й 24 місяці на безпеку.

Чому оновлення PHP окреме питання? Бо це інший розклад: два роки активної підтримки плюс рік безпеки. Версія фреймворку й версія мови мають бути сумісними, і саме на цьому стику найчастіше застрягають.

Підсумок

Проєкт на Laravel має календар, який не залежить від того, чи розвиваєте ви продукт: 18 місяців на виправлення помилок і 24 місяці на безпеку для кожної мажорної версії, нова мажорна раз на рік, LTS немає. Під фреймворком працює другий розклад, у PHP, з вікном у три роки. Відкладене оновлення дорожчає нелінійно, бо разом із фреймворком старіють усі сторонні пакети. Тому оновлення планують щорічно окремим рядком бюджету, а не тоді, коли щось зламалось. У Chyzh Agency ці підходи застосовуємо в проєктах з веброзробки.

Автор: Євген Павленко, DevOps, Chyzh Agency.