Symfony in 2026: The Framework Modern PHP Is Built On

Most business owners have never chosen Symfony, and most of them run it anyway. Laravel, Drupal, Composer and a long list of commerce, PIM and CRM platforms stand on its components. Here is the story of Symfony over twenty years, the numbers behind it, how its parts end up inside other frameworks, why it is built to last decades while Laravel is built to assemble fast, and when we would put a new system on Symfony.

What it is

A framework and a box of parts

Symfony is a PHP framework that Fabien Potencier and his company SensioLabs released as open source in 2005. Twenty years later it is two things at once, and the difference matters for anyone paying for software.

The first is a full-stack framework: you take Symfony as a whole and build an application on it, with its structure for controllers, services, configuration, forms, security and the database layer Doctrine. The second is a library of standalone components. Each one solves a single job (reading an HTTP request, matching a URL to code, sending an email, running a command in the terminal) and can be used without the rest of Symfony.

The components are why Symfony is everywhere. A team that writes its own framework or CMS does not need to reinvent the HTTP request or the email message. It takes the Symfony part, which is tested by thousands of projects, and builds its own ideas on top. That is exactly what Laravel did, and what Drupal, Composer and dozens of business platforms did after it.

History

Twenty years in a few dates

Symfony was not born in a university or a big tech company. It came out of a web agency. SensioLabs was a Paris agency that built sites for clients, and Fabien Potencier wrote the framework to stop solving the same problems on every project. In October 2005 they opened the code to everyone. That origin explains a lot about Symfony's character: it was made by people who had to maintain client projects for years, not by people who wanted to win a benchmark.

The turning point was 2011. Symfony 2 was not an update of Symfony 1 but a new framework, and its key decision was to cut everything into pieces that could live separately. In the same summer a young developer in the United States released Laravel. Two years later Laravel 4 was rebuilt on Composer, the new PHP package manager, and took Symfony's request, routing and console components as its base. From that moment the two frameworks have shared a foundation.

The second turning point was Drupal 8 in 2015. One of the largest open source CMS projects in the world threw away a large part of its own code and moved onto Symfony components. For Symfony this was proof that its parts could carry systems far bigger than a single application.

How components work

Parts with a contract

A component is a small library with one job, its own tests, its own documentation and its own version number. All of Symfony is developed in one main repository, and each component is automatically copied into a separate read-only repository and published on Packagist, the public catalogue of PHP packages. So a project that only needs to send email can install symfony/mailer and nothing else.

Composer, the package manager every modern PHP project uses, does the assembling. The project writes down which parts it needs and which versions it accepts. Laravel 13, for example, asks for each Symfony component with the rule "7.4 or 8", and Composer picks versions that fit together. When Symfony releases a fix, the next update brings it in.

Components fit together because they agree on interfaces rather than on each other's code. Symfony publishes small sets of shared interfaces, called contracts, for things like events, caching, translation and HTTP clients. Many components also follow the common PHP standards written by PHP-FIG: the cache component implements PSR-6 and PSR-16, the service container implements PSR-11, logging goes through PSR-3. A project can swap one part for another without rewriting the rest.

Here is what that looks like inside Laravel, in the code on our own server. Laravel's Request class is declared as an extension of Symfony's Request. Laravel's Response extends Symfony's Response. Artisan, Laravel's command line, is a subclass of Symfony's Console application. When you open any page of a Laravel site, the object that carries your browser's request is, at its core, a Symfony object with Laravel's conveniences added on top.

Inside every Laravel request there is a Symfony request.

The numbers

What the downloads say

Packagist counts every installation of every package, including automated builds, so the figures measure reach rather than people. Even with that caveat, the scale is striking. These are the totals on 13 November 2026:

Three things stand out. Symfony's console component has been installed twice as often as Laravel itself, because every Laravel install brings it along, and so do Composer-based tools, Drupal and thousands of libraries: 14,089 public packages on Packagist depend on it directly. The components are installed three to four times more often than the full Symfony framework, which is the clearest measure of how much of PHP rests on Symfony without carrying its name. And symfony/console alone accounts for about 0.6% of all installs on Packagist, a catalogue of more than 480,000 packages.

Surveys count people instead. In JetBrains' State of PHP 2025, 1,720 developers answered which frameworks they use: 64% Laravel, 25% WordPress, 23% Symfony. A year earlier it was 61%, 23% and 21%, so all three grew a little and the order stayed. Symfony's direct share is smaller, but it is concentrated where software is big and long-lived, and the survey cannot count the Laravel and Drupal developers who use Symfony every day through its components.

Inside Laravel

What Laravel is made of

Open the file that describes the dependencies of Laravel 13 and you will find fourteen Symfony components in its required list. They are not optional extras: every Laravel request passes through them.

We checked our own site, which runs on Laravel 13.34. Its server has 31 Symfony packages installed, most of them on Symfony 8.1. Here are the ones Laravel asks for directly, and what they do inside it:

What Laravel adds on top is its own: the Eloquent database layer, the Blade templates, queues, the service container, the developer comfort it is known for. But the ground floor is Symfony, and Laravel's major versions follow it. Laravel 9 moved to Symfony 6, Laravel 11 to Symfony 7, and Laravel 13 accepts Symfony 7.4 or 8.

For a business owner this has a practical side. When Symfony ships a security fix in HttpFoundation, every Laravel site receives it with the next dependency update. And a site on an old Laravel version is also sitting on an old Symfony that no longer gets those fixes. We described what that means for an upgrade in Upgrading an Old Laravel or PHP Site in 2026.

Who else

Drupal, Composer and the platforms

Laravel is the best known tenant, but not the only one. Symfony keeps a public list of projects built on its components, and the names on it explain why the framework matters far beyond its own users.

• Drupal: the CMS behind many government, university and media sites has run on Symfony components since Drupal 8. Drupal 11 sits on Symfony 7, its 11.3 release moved to 7.4 LTS, and Drupal 12 is being built on Symfony 8.
• Composer: the tool every modern PHP project uses to install its libraries is itself built with Symfony's Console, Finder and Process components.
• Commerce: Sylius, Shopware 6 and OroCommerce are online store platforms built on Symfony.
• Product data and customers: Akeneo PIM, Pimcore and OroCRM, the systems companies use to manage product catalogues, content and customer records, are Symfony applications.

Our own Symfony work so far has been on the Drupal side: we built modules for the admin panel of a Drupal site of a large American company (we cannot name it). Writing a Drupal module today means working with Symfony's service container, events and routing, so it is Symfony work in a Drupal shape.

Built for decades

The rules Symfony never breaks

People who work with Symfony sometimes call it dogmatic, and they mean it both ways. Symfony has a short list of rules it has kept for more than a decade, and those rules are the reason companies trust it with systems they plan to run for ten years or more.

The first rule is the backward compatibility promise. A minor release (7.1, 7.2, 7.3) never breaks code that worked on the previous one. If the team wants to change how something works, the old way keeps working and is marked as deprecated: your logs start showing a warning that names the line to change. The old code disappears only in the next major version.

The second rule is that the last minor version and the next major are twins. Symfony 7.4 and 8.0 came out on the same day with the same features. The only difference is that 8.0 drops everything 7.4 marked as deprecated. So a project that runs on 7.4 without deprecation warnings can move to 8.0 almost mechanically. Upgrading stops being a rewrite and becomes a to-do list your own logs have been writing for two years.

The third rule is the calendar. A minor version every May and November, a major every two years, and long-term support on the last minor of each major: three years of bug fixes and four years of security fixes. A company can put the date of its next upgrade into a budget years ahead, and show an auditor exactly until when its framework is supported.

Laravel lives by a different contract. A new major version comes out every year, around the first quarter. Each version gets 18 months of bug fixes and two years of security fixes, and there has been no long-term support version since Laravel 6 in 2019. Laravel 13, released in March 2026, gets security fixes until March 2028. Laravel upgrades are usually small (we took our own site from version 7 to 13 in three days, the story is in Six Laravel Versions in Three Days), but they have to happen every year or two. Neither contract is better. One is written for decades, the other for speed.

Symfony is written for the tenth year, Laravel for the first.

Versions

Which versions are still alive

The table shows the state of Symfony as of November 2026. Check the official release page before planning, since dates move when a sponsor extends support.

Three things follow from it. Symfony 6.4 stops receiving bug fixes at the end of this month, and its security support ends a year later. Symfony 5.4 got an unusual extension of security fixes to February 2029, paid for by the company Ibexa, so a 5.4 project is safer than its age suggests. And anything older than 5.4, or a non-LTS version like 4.3 or 6.2, gets nothing at all.

For a new project the usual choice is between 7.4 LTS (needs PHP 8.2 or newer, quiet until 2029) and the 8.x line (needs PHP 8.4, newer features, but an upgrade every six months until 8.4 LTS arrives).

Like Python

Laravel is built to assemble fast

Yevhen, our founder, puts it this way: Laravel is to PHP what Python is to back-end development in general. You assemble faster. Python won its place by being quick to write and easy to read, with frameworks like Django that come with most of what a typical application needs. Laravel took the same road inside PHP.

A new Laravel project already knows how to talk to the database (Eloquent and migrations), send mail and notifications, run background jobs and scheduled tasks, store files locally or in the cloud, log users in, and test all of that. Artisan generates the skeleton of a model, a controller or a job in one command. The conventions are strong: there is usually one obvious place for each piece of code, so a developer who joins the project finds their way in a day. Facades and helpers keep the code short, so a business rule takes a few readable lines.

The result is a first working version sooner and a cheaper path to it. With us a senior developer hour costs $75 and a middle developer $45 to $50, and on Laravel a large part of the work can go to a middle developer without losing quality. Our own booking calendar for The Structure, with Google Calendar, Meet and approvals, was working within a week; the story is in How to Build Your Own Booking Calendar in Laravel.

Same task

One task in Laravel and in Symfony

To make the difference concrete, here is the same small task written both ways. A customer sends an order (an email address and a total in cents), the system checks the data, saves the order, sends a confirmation email and answers with the new order's number. Both versions follow the style each framework's own documentation recommends in 2026, and both leave out the import lines at the top of the files.

First, the order itself. In Laravel the model takes four lines: Eloquent learns the columns from the database table, which a separate migration creates.

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

In Symfony the entity is an ordinary PHP class that describes its own columns with attributes. Doctrine reads the class and generates the migration from it, so the code, not the table, is the source of truth.

// 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; }
}

Now the order arrives. In Laravel the route, the validation, the saving and the email fit into one short method. OrderPlaced is a mail class that Artisan creates with one command, 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);
    }
}

In Symfony the incoming data gets its own small class with the rules written on its fields. The attribute MapRequestPayload turns the request into that class and checks it before the method even starts; if the data is wrong, the customer gets an error with the reasons. Everything the controller needs, the database manager and the mailer, is listed in its constructor.

// 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);
    }
}

The Laravel version is about half as long, and that is the point of Laravel: Order::create, the Mail facade and the validation rules written as short strings are simply there, with no wiring. The Symfony version is longer because nothing in it is hidden. You can see from the constructor what the controller depends on, a test can hand it a fake mailer without any tricks, the order is a plain object that knows nothing about the database, and the rules for the incoming data live in one class that other parts of the system can reuse. On one form the difference is a few dozen lines. On a system with three hundred such operations and twenty developers, it decides how easy the code is to change in year eight.

Where Laravel stops

Why Laravel does not fit everywhere

The same things that make Laravel fast become costs as a system grows past a certain size. None of them is a defect, they are the price of speed, and on most business projects the price is worth paying. On some it is not.

The database layer. Eloquent follows the Active Record pattern: a model is a row of a table, and it knows how to save itself. That is wonderfully quick for orders, users and articles. In a large domain (production planning, pricing with hundreds of rules, accounting) business logic starts to stick to tables, and changing the database means touching the rules. Symfony's usual partner Doctrine follows the Data Mapper pattern: business objects are plain code, and a separate layer decides how they are stored. It is slower to start and much easier to change in year eight.

The magic. Facades, global helpers and relationships named in strings keep Laravel code short, but they hide where things come from. For a team of three that is comfort. For thirty developers in several teams, explicit dependencies, which Symfony insists on, make it easier to see what breaks when something changes, and they let code analysis tools work without extra plugins.

The calendar. Two years of security fixes per version means an upgrade at least every two years, forever. A bank, a manufacturer or a company inside a large group often needs four years of support on paper and an upgrade date known in advance. Symfony's LTS gives them exactly that.

The platform. If the system extends Drupal, Akeneo, Pimcore, Sylius, Shopware or OroCRM, Laravel is not on the table at all: the extension has to speak the platform's own Symfony language.

When we choose it

When we would build on Symfony

Symfony asks for more up front. Configuration is explicit, the structure is strict, and the database layer keeps business objects separate from how they are stored. On a small project that is overhead. On a large one it is what keeps the system readable when the third team inherits it. These are the situations where we would put a new system on Symfony:

• the system extends a platform that is already Symfony: a Drupal site, a Sylius or Shopware store, an Akeneo or Pimcore catalogue;
• the business domain is large and complicated (production, logistics, finance), with hundreds of rules that must stay separate from the database;
• several teams will work on it for many years, and strict conventions matter more than speed of the first release;
• the company needs a published support calendar to show auditors or a parent company.

This is why so many ERP, PIM and CRM platforms are built on Symfony. They are products with deep data models, many integrations and customers who keep them for a decade, and Symfony's strictness pays off there. If you are choosing such a system, start from the business side: what separates a CRM from an ERP and whether to build your own or buy a ready one.

Choosing Laravel does not mean leaving Symfony behind. Because Laravel stands on Symfony components, a Laravel team reads Symfony code without a translator: the request, the console, the mailer, the events are the same parts. That is why we work with Symfony projects without any trouble, and why we take on Symfony and Drupal code from other teams through project takeover. The broader trade-off between the two frameworks is in our essay Laravel vs Symfony.

Strictness is overhead on a small project and insurance on a large one.

Why Laravel for us

Why we usually build on Laravel

Everything above is the honest picture of both frameworks. Our own choice on the projects we have now is more often Laravel, or Python when the work is about data and AI. We have worked with Laravel for more than eight years and built nearly thirty projects on it, and the choice comes from who our clients are, not from taste.

Our clients need a system built around their business. They are mostly small and medium companies with their own way of selling, producing and serving, which no ready-made product fits. For them the first working version and the cost of the next five years matter more than a support calendar for auditors. Laravel gives the fastest road from their logic to working software.

It is faster to build and a little simpler. The order example above is typical: the same feature takes fewer lines, fewer files and fewer decisions. On a real project that means weeks saved before launch and a lower invoice for the same result.

It is cheaper to own. More developers in the world know Laravel than any other PHP framework, so the owner is never locked to one team, us included. A large share of the work can go to a middle developer, and a new developer finds their way in the code in days.

Its upgrades are small. A new Laravel version every year sounds like a burden, but the steps are short. We took our own site through six versions in three days, and that experience is now part of how we keep client systems current.

Most business problems need the simpler tool. Yevhen, our founder, sums it up this way: a business solution more often needs the simpler and more widespread Laravel, which is also cheaper for the owner to maintain. Symfony makes sense when the system is very heavy and complex, an ERP for example, and even then it depends on which ERP it is and what load it has to carry.

We run our own business on it. This website, the client portal with the CRM inside it, and The Structure with its booking calendar all run on Laravel, so every problem we solve for ourselves becomes experience for clients. How Laravel compares with Node.js and Python is in a separate guide, and what a Laravel project costs is in How Much Does Laravel Development Cost in 2026?

When a project calls for Symfony (one of the cases in the chapter above), we say so and work in Symfony. When it calls for Python, we use Python. Laravel is our default, not our only answer.

If you have one

An old Symfony or Drupal system

The most common Symfony question we hear is not about a new project. It is about an old one. One of our clients has an aging Drupal site that they wanted to rewrite on something new, and they are still weighing it. That pause is normal: a rewrite is expensive, and an upgrade feels like paying for nothing visible.

There are three honest options, and the choice depends on the code more than on taste:

1. Upgrade in place: move the system to Symfony 7.4 LTS or Drupal 11 step by step. It fits when the business logic is sound and the main problem is age. Symfony's deprecation warnings turn this into a list of concrete changes.
2. Rewrite: build the system again, often on Laravel, and move the data. It fits when the code has become a maze that nobody dares to touch, or when the business has changed so much that the old structure is in the way.
3. Keep and isolate: leave the old core running, close its weak spots, and build new parts beside it with a clear boundary. It fits when the system works and the budget is needed elsewhere this year.

To choose, look at three things: which Symfony or Drupal version runs now and when its security support ends (the table above), how much of the code is custom rather than standard, and whether there are tests. Our website modernization work starts with exactly this audit, and the checklist for a careful build is in What Separates a Premium Laravel or Symfony Build.

FAQ

Sources

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