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