Symfony у 2026 році: фреймворк, на якому стоїть сучасний PHP

Більшість власників бізнесу ніколи не обирали Symfony, але майже всі ним користуються. На його компонентах стоять Laravel, Drupal, Composer і довгий перелік платформ для торгівлі, товарних каталогів і CRM. Розповідаємо історію Symfony за двадцять років, показуємо цифри, пояснюємо, як його деталі потрапляють усередину інших фреймворків, чому Symfony будують на десятиліття, а Laravel для швидкого складання, і коли ми поставили б нову систему на Symfony.

Що це

Фреймворк і набір деталей

Symfony це PHP-фреймворк, який Фаб'єн Потансьє і його компанія SensioLabs відкрили для всіх у 2005 році. Через двадцять років це дві речі водночас, і для того, хто платить за розробку, різниця важлива.

Перша річ: повноцінний фреймворк. Ви берете Symfony цілком і будуєте на ньому застосунок, з його порядком для контролерів, сервісів, налаштувань, форм, безпеки й шару роботи з базою Doctrine. Друга: бібліотека самостійних компонентів. Кожен розв'язує одне завдання (прочитати HTTP-запит, зіставити адресу з кодом, надіслати лист, виконати команду в терміналі), і його можна використовувати без решти Symfony.

Саме компоненти зробили Symfony всюдисущим. Команді, яка пише свій фреймворк чи CMS, не треба заново вигадувати HTTP-запит або лист. Вона бере готову деталь Symfony, перевірену тисячами проєктів, і будує на ній свої ідеї. Саме так зробив Laravel, а слідом за ним Drupal, Composer і десятки бізнес-платформ.

Історія

Двадцять років у кількох датах

Symfony народився не в університеті й не у великій технологічній компанії, а у вебагенції. SensioLabs була паризькою агенцією, яка робила сайти для клієнтів, і Фаб'єн Потансьє написав фреймворк, щоб перестати розв'язувати ті самі задачі в кожному проєкті. У жовтні 2005 року код відкрили для всіх. Це походження багато що пояснює в характері Symfony: його робили люди, яким доводилося роками підтримувати клієнтські проєкти, а не люди, які хотіли перемогти в тестах швидкості.

Переломним став 2011 рік. Symfony 2 був не оновленням Symfony 1, а новим фреймворком, і головним його рішенням було розрізати все на деталі, здатні жити окремо. Того ж літа молодий розробник зі США випустив Laravel. За два роки Laravel 4 перезібрали на Composer, новому менеджері пакетів PHP, і взяли за основу компоненти Symfony для запиту, маршрутизації й консолі. Відтоді у двох фреймворків спільний фундамент.

Другий перелом стався у 2015 році з виходом Drupal 8. Один із найбільших відкритих CMS-проєктів у світі викинув велику частину власного коду й перейшов на компоненти Symfony. Для Symfony це стало доказом, що його деталі витримують системи значно більші за один застосунок.

Як влаштовані компоненти

Деталі з домовленістю

Компонент це невелика бібліотека з одним завданням, своїми тестами, своєю документацією і своїм номером версії. Увесь Symfony розробляють в одному головному репозиторії, а кожен компонент автоматично копіюється в окремий репозиторій лише для читання і публікується на Packagist, відкритому каталозі PHP-пакетів. Тому проєкт, якому треба тільки надсилати листи, може встановити symfony/mailer і більше нічого.

Збирає все це Composer, менеджер пакетів, яким користується кожен сучасний PHP-проєкт. Проєкт записує, які деталі йому потрібні і які версії він приймає. Laravel 13, наприклад, просить кожен компонент Symfony за правилом «7.4 або 8», а Composer добирає версії, які пасують одна до одної. Коли Symfony випускає виправлення, наступне оновлення його приносить.

Компоненти стикуються, бо домовляються про інтерфейси, а не про код одне одного. Symfony публікує невеликі набори спільних інтерфейсів, їх називають контрактами, для подій, кешу, перекладів і HTTP-клієнтів. Багато компонентів до того ж дотримуються спільних стандартів PHP, які пише PHP-FIG: компонент кешу реалізує PSR-6 і PSR-16, контейнер сервісів PSR-11, логування йде через PSR-3. Проєкт може замінити одну деталь іншою, не переписуючи решту.

Ось як це виглядає всередині Laravel, у коді на нашому власному сервері. Клас Request у Laravel оголошено як розширення класу Request із Symfony. Response у Laravel розширює Response із Symfony. Artisan, командний рядок Laravel, це нащадок консольного застосунку Symfony. Коли ви відкриваєте будь-яку сторінку сайту на Laravel, об'єкт, який несе запит вашого браузера, по суті є об'єктом Symfony, до якого Laravel додав свої зручності.

Усередині кожного запиту до Laravel лежить запит Symfony.

Цифри

Що кажуть встановлення

Packagist рахує кожне встановлення кожного пакета, зокрема автоматичні збірки, тож цифри показують охоплення, а не кількість людей. Навіть із цим застереженням масштаб вражає. Ось підсумки на 13 листопада 2026 року:

Тут впадають в око три речі. Консольний компонент Symfony встановлювали вдвічі частіше, ніж сам Laravel, бо його приносить кожне встановлення Laravel, а ще інструменти на Composer, Drupal і тисячі бібліотек: напряму від нього залежать 14 089 відкритих пакетів на Packagist. Компоненти встановлюють утричі чи вчетверо частіше, ніж повний фреймворк Symfony, і це найнаочніша міра того, скільки PHP тримається на Symfony, не носячи його імені. А сам лише symfony/console дає близько 0,6% усіх встановлень на Packagist, у каталозі з понад 480 тисяч пакетів.

Опитування рахують людей. В опитуванні JetBrains State of PHP 2025 1 720 розробників відповіли, якими фреймворками користуються: Laravel 64%, WordPress 25%, Symfony 23%. Роком раніше було 61%, 23% і 21%: усі троє трохи зросли, порядок не змінився. Пряма частка Symfony менша, але вона зосереджена там, де програми великі й живуть довго, а розробників Laravel і Drupal, які щодня користуються Symfony через компоненти, опитування врахувати не може.

Усередині Laravel

З чого зроблено Laravel

Відкрийте файл, де перелічено залежності Laravel 13, і ви знайдете в обов'язковому списку чотирнадцять компонентів Symfony. Це не доповнення на вибір: крізь них проходить кожен запит до сайту на Laravel.

Ми перевірили власний сайт, він працює на Laravel 13.34. На сервері встановлено 31 пакет Symfony, більшість у версії 8.1. Ось ті, яких Laravel вимагає напряму, і що вони роблять усередині нього:

Згори Laravel додає своє: шар роботи з базою Eloquent, шаблони Blade, черги, контейнер сервісів, зручність, за яку його люблять розробники. Але перший поверх тут Symfony, і великі версії Laravel ідуть за ним. Laravel 9 перейшов на Symfony 6, Laravel 11 на Symfony 7, а Laravel 13 приймає Symfony 7.4 або 8.

Для власника бізнесу в цього є практичний бік. Коли Symfony випускає виправлення безпеки в HttpFoundation, кожен сайт на Laravel отримує його з наступним оновленням залежностей. А сайт на старій версії Laravel заразом сидить на старому Symfony, який цих виправлень уже не отримує. Що це означає для оновлення, ми розібрали у статті Оновлення старого сайту на Laravel або PHP у 2026 році.

Хто ще

Drupal, Composer і платформи

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

• Drupal: CMS, на якій працює чимало сайтів держустанов, університетів і медіа, стоїть на компонентах Symfony з часів Drupal 8. Drupal 11 працює на Symfony 7, у версії 11.3 він перейшов на 7.4 LTS, а Drupal 12 будують уже на Symfony 8.
• Composer: інструмент, яким кожен сучасний PHP-проєкт встановлює свої бібліотеки, сам зібраний на компонентах Console, Finder і Process.
• Торгівля: Sylius, Shopware 6 і OroCommerce, платформи інтернет-магазинів, побудовані на Symfony.
• Товарні дані й клієнти: Akeneo PIM, Pimcore і OroCRM, системи, у яких компанії ведуть каталоги товарів, контент і базу клієнтів, це застосунки на Symfony.

Наша власна робота з Symfony поки йшла з боку Drupal: ми робили модулі для адмінки сайту на Drupal однієї великої американської компанії (назвати її не можемо). Писати модуль для Drupal сьогодні означає працювати з контейнером сервісів, подіями й маршрутизацією Symfony, тож по суті це робота з Symfony у формі Drupal.

На десятиліття

Правила, яких Symfony не порушує

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

Перше правило: обіцянка зворотної сумісності. Мінорний випуск (7.1, 7.2, 7.3) ніколи не ламає код, який працював на попередньому. Якщо команда хоче змінити, як щось влаштовано, старий спосіб і далі працює і позначається як застарілий: у ваших логах з'являється попередження, яке називає рядок, що потребує правки. Старий код зникає лише в наступній мажорній версії.

Друге правило: остання мінорна версія і наступна мажорна це близнята. Symfony 7.4 і 8.0 вийшли в один день з однаковими можливостями. Різниця лише в тому, що 8.0 прибирає все, що 7.4 позначила як застаріле. Тому проєкт, який працює на 7.4 без попереджень про застарілий код, переходить на 8.0 майже механічно. Оновлення перестає бути переписуванням і перетворюється на список справ, який ваші ж логи писали два роки.

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

Laravel живе за іншою домовленістю. Нова мажорна версія виходить щороку, приблизно в першому кварталі. Кожна отримує 18 місяців виправлень помилок і два роки виправлень безпеки, а версій із довгою підтримкою немає з часів Laravel 6 у 2019 році. Laravel 13, що вийшов у березні 2026 року, отримує виправлення безпеки до березня 2028 року. Оновлення Laravel зазвичай невеликі (свій сайт ми перевели з сьомої версії на тринадцяту за три дні, історія у статті Шість версій Laravel за три дні), але робити їх доводиться раз на рік чи два. Жодна з домовленостей не краща за іншу. Одну написано на десятиліття, іншу заради швидкості.

Symfony пишуть для десятого року, Laravel для першого.

Версії

Які версії ще живі

У таблиці стан Symfony на листопад 2026 року. Перед плануванням звіртеся з офіційною сторінкою релізів: строки зсуваються, коли спонсор подовжує підтримку.

Звідси три висновки. Symfony 6.4 перестає отримувати виправлення помилок наприкінці цього місяця, а його підтримка безпеки закінчується за рік. Symfony 5.4 отримав незвичне подовження виправлень безпеки до лютого 2029 року, його оплатила компанія Ibexa, тож проєкт на 5.4 захищений краще, ніж можна подумати з його віку. А все, що старше за 5.4, чи версії без LTS на кшталт 4.3 і 6.2 не отримують нічого.

Для нового проєкту вибір зазвичай такий: 7.4 LTS (потрібен PHP 8.2 або новіший, спокійне життя до 2029 року) або лінія 8.x (потрібен PHP 8.4, нові можливості, але оновлення раз на пів року, доки не вийде 8.4 LTS).

Як Python

Laravel створено для швидкого складання

Євген, наш засновник, каже так: Laravel для PHP те саме, що Python для серверної розробки загалом. Зібрати виходить швидше. Python посів своє місце тим, що на ньому швидко писати й легко читати, а фреймворки на кшталт Django приносять із собою майже все, що потрібно звичайному застосункові. Laravel пройшов той самий шлях усередині PHP.

Новий проєкт на Laravel уже вміє працювати з базою (Eloquent і міграції), надсилати листи й сповіщення, виконувати фонові задачі й задачі за розкладом, зберігати файли на сервері чи в хмарі, впускати користувачів і все це тестувати. Artisan створює заготовку моделі, контролера чи задачі однією командою. Домовленості сильні: для кожного шматка коду зазвичай є одне очевидне місце, і розробник, який прийшов у проєкт, освоюється за день. Фасади й помічники роблять код коротким, і бізнес-правило займає кілька читабельних рядків.

У результаті перша робоча версія з'являється раніше, а шлях до неї дешевший. У нас година senior-розробника коштує 75 доларів, middle від 45 до 50, і на Laravel більшу частину роботи можна віддати middle без втрати якості. Наш власний календар запису для The Structure, з Google Calendar, Meet і погодженням заявок, запрацював за тиждень, історія у статті Власний календар запису на Laravel.

Одне завдання

Одне завдання на Laravel і на Symfony

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

Спершу саме замовлення. У Laravel модель займає чотири рядки: Eloquent дізнається колонки з таблиці в базі, а таблицю створює окрема міграція.

// app/Models/Order.php
class Order extends Model
{
    protected $fillable = ['customer_email', 'total_cents'];
}

У Symfony сутність це звичайний PHP-клас, який сам описує свої колонки атрибутами. Doctrine читає клас і генерує міграцію з нього, тож джерело правди тут код, а не таблиця.

// src/Entity/Order.php
#[ORM\Entity]
#[ORM\Table(name: 'orders')]
class Order
{
    #[ORM\Id, ORM\GeneratedValue, ORM\Column]
    private ?int $id = null;

    public function __construct(
        #[ORM\Column(length: 180)]
        private string $customerEmail,
        #[ORM\Column]
        private int $totalCents,
    ) {}

    public function getId(): ?int { return $this->id; }
    public function getCustomerEmail(): string { return $this->customerEmail; }
}

Тепер замовлення надходить. У Laravel маршрут, перевірка, збереження і лист уміщаються в один короткий метод. OrderPlaced це клас листа, який Artisan створює однією командою, make:mail.

// routes/web.php
Route::post('/orders', [OrderController::class, 'store']);

// app/Http/Controllers/OrderController.php
class OrderController extends Controller
{
    public function store(Request $request)
    {
        $data = $request->validate([
            'customer_email' => 'required|email',
            'total_cents'    => 'required|integer|min:0',
        ]);

        $order = Order::create($data);
        Mail::to($order->customer_email)->send(new OrderPlaced($order));

        return response()->json(['id' => $order->id], 201);
    }
}

У Symfony вхідні дані отримують свій невеликий клас із правилами, записаними просто на полях. Атрибут MapRequestPayload перетворює запит на цей клас і перевіряє його ще до початку методу; якщо дані хибні, клієнт отримує помилку з причинами. Усе, що потрібно контролеру, менеджер бази даних і поштовий сервіс, перелічено в його конструкторі.

// src/Dto/OrderInput.php
final class OrderInput
{
    public function __construct(
        #[Assert\NotBlank, Assert\Email]
        public string $customerEmail,
        #[Assert\PositiveOrZero]
        public int $totalCents,
    ) {}
}

// src/Controller/OrderController.php
final class OrderController extends AbstractController
{
    public function __construct(
        private EntityManagerInterface $em,
        private MailerInterface $mailer,
    ) {}

    #[Route('/orders', methods: ['POST'])]
    public function store(#[MapRequestPayload] OrderInput $input): JsonResponse
    {
        $order = new Order($input->customerEmail, $input->totalCents);
        $this->em->persist($order);
        $this->em->flush();

        $this->mailer->send((new TemplatedEmail())
            ->to($order->getCustomerEmail())
            ->subject('Order received')
            ->htmlTemplate('emails/order_placed.html.twig')
            ->context(['order' => $order]));

        return $this->json(['id' => $order->getId()], 201);
    }
}

Версія на Laravel приблизно вдвічі коротша, і в цьому весь сенс Laravel: Order::create, фасад Mail і правила перевірки, записані короткими рядками, просто є, без жодної обв'язки. Версія на Symfony довша, бо в ній нічого не сховано. З конструктора видно, від чого залежить контролер, тест може підставити йому підробний поштовий сервіс без жодних хитрощів, замовлення це звичайний об'єкт, який нічого не знає про базу, а правила для вхідних даних живуть в одному класі, який можуть повторно використовувати інші частини системи. На одній формі різниця в кілька десятків рядків. У системі з трьома сотнями таких операцій і двадцятьма розробниками вона вирішує, наскільки легко змінювати код на восьмий рік.

Де Laravel упирається

Чому Laravel підходить не всюди

Те, що робить Laravel швидким, стає витратами, коли система виростає за певний розмір. Це не вади, це ціна швидкості, і в більшості бізнес-проєктів її варто платити. У деяких не варто.

Шар роботи з базою. Eloquent дотримується шаблону Active Record: модель це рядок таблиці, і вона вміє сама себе зберігати. Для замовлень, користувачів і статей це чудово швидко. У великій предметній області (планування виробництва, ціноутворення із сотнями правил, облік) бізнес-логіка починає прилипати до таблиць, і зміна бази зачіпає правила. Звичайний напарник Symfony, Doctrine, дотримується шаблону Data Mapper: бізнес-об'єкти лишаються звичайним кодом, а окремий шар вирішує, як їх зберігати. Починати на ньому повільніше, а змінювати на восьмий рік значно легше.

Магія. Фасади, глобальні помічники і зв'язки, задані рядками, роблять код Laravel коротким, але ховають, звідки що береться. Для команди з трьох людей це зручність. Для тридцяти розробників у кількох командах явні залежності, на яких наполягає Symfony, допомагають побачити, що зламається під час зміни, і дають інструментам аналізу коду працювати без додаткових плагінів.

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

Платформа. Якщо система розширює Drupal, Akeneo, Pimcore, Sylius, Shopware чи OroCRM, Laravel узагалі не розглядається: розширення має говорити мовою платформи, а це Symfony.

Коли ми його обираємо

Коли ми будували б на Symfony

Symfony вимагає більше вкладень на старті. Налаштування явні, структура сувора, а шар роботи з базою тримає бізнес-об'єкти окремо від того, як вони зберігаються. У невеликому проєкті це зайве навантаження. У великому саме це зберігає систему зрозумілою, коли вона переходить до третьої за ліком команди. Ось ситуації, у яких ми поставили б нову систему на Symfony:

• система розширює платформу, яка вже стоїть на Symfony: сайт на Drupal, магазин на Sylius чи Shopware, каталог на Akeneo чи Pimcore;
• предметна область велика й складна (виробництво, логістика, фінанси), із сотнями правил, які треба тримати окремо від бази даних;
• над системою багато років працюватимуть кілька команд, і суворі домовленості важливіші за швидкість першого релізу;
• компанії потрібен опублікований календар підтримки, який можна показати аудиторам чи материнській компанії.

Тому так багато ERP, PIM і CRM-платформ побудовано на Symfony. Це продукти з глибокою моделлю даних, безліччю інтеграцій і клієнтами, які тримають їх по десять років, і суворість Symfony там окупається. Якщо ви обираєте таку систему, почніть із бізнесового боку: чим CRM відрізняється від ERP і будувати свою чи купувати готову.

Обрати Laravel не означає піти від Symfony. Оскільки Laravel стоїть на компонентах Symfony, команда Laravel читає код на Symfony без перекладача: запит, консоль, пошта, події там ті самі. Тому ми спокійно працюємо з проєктами на Symfony і приймаємо код на Symfony та Drupal від інших команд через прийом проєкту. Ширший вибір між двома фреймворками ми розібрали в есеї Laravel чи Symfony.

Суворість у малому проєкті навантаження, у великому страховка.

Чому Laravel у нас

Чому ми частіше будуємо на Laravel

Усе, що вище, це чесна картина обох фреймворків. Наш власний вибір у поточних проєктах частіше Laravel, а якщо робота про дані й ШІ, то Python. Ми працюємо з Laravel понад вісім років і зробили на ньому майже три десятки проєктів, і цей вибір іде від того, хто наші клієнти, а не від смаку.

Нашим клієнтам потрібна система, побудована довкола їхнього бізнесу. Здебільшого це малі й середні компанії зі своїм способом продавати, виробляти й обслуговувати, під який не пасує жоден готовий продукт. Для них перша робоча версія і вартість наступних п'яти років важливіші за календар підтримки для аудиторів. Laravel дає найкоротшу дорогу від їхньої логіки до програми, що працює.

На ньому швидше будувати, і він трохи простіший. Приклад із замовленням вище типовий: та сама функція займає менше рядків, менше файлів і менше рішень. У реальному проєкті це тижні, заощаджені до запуску, і менший рахунок за той самий результат.

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

Його оновлення невеликі. Нова версія Laravel щороку звучить як тягар, але кроки короткі. Свій сайт ми провели через шість версій за три дні, і цей досвід тепер частина того, як ми тримаємо системи клієнтів актуальними.

Більшості бізнес-завдань потрібен простіший інструмент. Євген, наш засновник, формулює це так: бізнес-рішенням частіше потрібен простіший і поширеніший Laravel, який власникові до того ж дешевше обслуговувати. Symfony має сенс, коли система дуже важка й складна, наприклад ERP, і то залежно від того, яка це ERP і яке навантаження їй доведеться тримати.

Ми ведемо на ньому власний бізнес. Цей сайт, клієнтський портал із CRM усередині і The Structure з її календарем запису працюють на Laravel, тож кожне завдання, яке ми розв'язуємо для себе, стає досвідом для клієнтів. Як Laravel виглядає поряд із Node.js і Python, розібрано в окремій статті, а скільки коштує проєкт на Laravel, у статті Скільки коштує розробка на Laravel у 2026 році.

Коли проєктові потрібен Symfony (один із випадків із розділу вище), ми так і кажемо і працюємо на Symfony. Коли потрібен Python, беремо Python. Laravel наш вибір за замовчуванням, але не єдина відповідь.

Якщо він у вас є

Стара система на Symfony чи Drupal

Найчастіше питання про Symfony, яке ми чуємо, стосується не нового проєкту, а старого. В одного з наших клієнтів старіє сайт на Drupal, який хотіли переписати на чомусь новому, і рішення досі зважують. Така пауза нормальна: переписування коштує дорого, а оновлення схоже на оплату чогось невидимого.

Чесних варіантів три, і вибір залежить від коду більше, ніж від смаку:

1. Оновити на місці: крок за кроком перевести систему на Symfony 7.4 LTS або Drupal 11. Підходить, коли бізнес-логіка здорова і головна біда у віці. Попередження Symfony про застарілий код перетворюють цю роботу на список конкретних правок.
2. Переписати: збудувати систему заново, часто на Laravel, і перенести дані. Підходить, коли код перетворився на лабіринт, якого ніхто не наважується торкатися, або бізнес змінився так, що стара структура заважає.
3. Залишити й ізолювати: старе ядро працює далі, його слабкі місця закривають, а нові частини будують поруч із чіткою межею. Підходить, коли система працює, а бюджет цього року потрібніший деінде.

Щоб обрати, подивіться на три речі: яка версія Symfony чи Drupal працює зараз і коли в неї закінчується підтримка безпеки (таблиця вище), яку частину коду написано під вас, а яка стандартна, і чи є тести. Наша робота з модернізації сайту починається саме з такого аудиту, а перелік ознак акуратної збірки зібрано у статті Що відрізняє преміальну збірку на Laravel або Symfony.

Питання

Питання про Symfony

Чи актуальний Symfony у 2026 році?

Так, і не лише для власних користувачів. Symfony 7.4 LTS і 8.1 активно підтримуються, версію 8.4 LTS заплановано на листопад 2027 року, а Laravel, Drupal і Composer залежать від його компонентів. Сам лише його консольний компонент встановили понад 1,2 млрд разів.

Laravel побудований на Symfony?

Частково: Laravel 13 вимагає чотирнадцять компонентів Symfony, серед них HttpFoundation, HttpKernel, Routing, Console, Mailer і Process. Класи Request, Response і Artisan у Laravel успадковують класи Symfony. Власні частини Laravel, як-от Eloquent, Blade і черги, стоять поверх.

Чому Symfony вважають складнішим за Laravel?

Бо він просить усе писати явно. Сервіси, налаштування і зв'язок із базою прописують, а не вгадують за домовленостями, і Doctrine відокремлює бізнес-об'єкти від таблиць. На старті це довше, а окупається у великих системах, які живуть багато років.

Яку версію Symfony брати для нового проєкту?

Symfony 7.4 LTS, якщо потрібна стабільність до 2029 року і у вас PHP 8.2 або новіший. Лінію 8.x, якщо команда готова оновлюватися раз на пів року, доки в листопаді 2027 року не вийде 8.4 LTS. Починати на 6.4 не варто: виправлення помилок для неї закінчуються в листопаді 2026 року.

Symfony чи Laravel для ERP або CRM?

Якщо система розширює платформу на Symfony, наприклад Akeneo, Pimcore, OroCRM або сайт на Drupal, чи предметна область дуже велика й над нею працюють кілька команд, то Symfony. Для більшості бізнес-систем малих і середніх компаній ми обираємо Laravel: швидше збудувати й дешевше підтримувати. Навіть для ERP відповідь залежить від її розміру і навантаження, яке їй доведеться тримати.

Чи зможе команда Laravel підтримувати проєкт на Symfony?

Так, і без довгого перенавчання. Laravel побудований на компонентах Symfony, тому запит, консоль, пошта й події там ті самі. Головні відмінності: Doctrine замість Eloquent і явніші налаштування, а досвідчений розробник Laravel опановує їх швидко.

Скільки ще підтримується Symfony 6.4?

Виправлення помилок закінчуються 30 листопада 2026 року, виправлення безпеки в листопаді 2027 року. Проєктові на 6.4 варто запланувати перехід на 7.4 LTS протягом 2027 року.

Джерела

• Symfony Releases
• Our Backward Compatibility Promise, Symfony
• Laravel 13 Release Notes and Support Policy
• The State of PHP 2025, JetBrains
• Packagist Statistics