What Is Symfony? A Beginner’s Guide to the PHP Framework

What is Symfony? Symfony is two things bundled under one name. It is a full-stack PHP web framework you can use to build applications from scratch, and it is a library of standalone, reusable PHP components that other frameworks, content management systems, and applications pull in to solve specific problems. Drupal, Laravel, Magento, API Platform, and Joomla all use Symfony components in production, even though only some of those projects call themselves "Symfony applications."

This post unpacks the framework-versus-components distinction, walks through who actually uses Symfony today, explains the release cadence that makes Symfony plannable, and answers whether a Drupal developer (or a PHP developer more broadly) should invest in learning it. If you’re trying to decide whether Symfony belongs in your stack, or trying to make sense of the Symfony name appearing in projects that are not Symfony applications, start here.

What is Symfony, framework or components?

The most important thing to understand about Symfony is that the name covers two distinct but related things:

• The Symfony framework: a complete, full-stack PHP web application framework. You install it with Composer (composer create-project symfony/skeleton my_app), get a working application skeleton, and build a custom web application on top of its conventions. The framework includes routing, templating (Twig), forms, security, console commands, an ORM (Doctrine), and the application configuration layer that ties them together. This is what people usually mean when they say “I built it in Symfony.”
• The Symfony components: a library of 30+ standalone PHP packages, each solving a specific cross-cutting problem. HttpFoundation provides Request and Response objects. EventDispatcher provides a publish-subscribe pattern. Console provides a framework for command-line applications. Each component is independently installable via Composer and can be used in any PHP project, framework or not.

The two are coupled but separable. The framework is built on top of the components. The components can be (and are) used outside the framework. A project can use Symfony components without using the Symfony framework, which is exactly what Drupal, Laravel, and others do.

This dual-identity pattern is unusual in the PHP world. Most frameworks (Laravel, CodeIgniter, CakePHP) ship a tightly coupled monolithic codebase. Symfony deliberately split itself into reusable pieces, which is part of why the components ended up so widely adopted. The framework users get a full application skeleton; the component users get focused libraries without buying into a whole architecture.

The Symfony component library

The component library is where Symfony’s influence on PHP runs deepest. Each component is a focused, well-tested package on Packagist, with its own version, its own changelog, and its own documentation page on symfony.com. The full list is in the Symfony components catalog; the components Drupal and PHP developers run into most often:

• HttpFoundation: Request and Response object-oriented wrappers around PHP’s superglobals and output. The Request object normalizes headers, query parameters, and request body access; the Response object handles status codes, headers, and content with a clean API.
• HttpKernel: orchestrates the HTTP request lifecycle. Wraps a controller resolution and invocation pattern with events at each lifecycle stage (request, controller, view, response, terminate).
• Routing: maps URLs to controller methods. Supports parameters, requirements, defaults, and various URL generation strategies.
• EventDispatcher: publish-subscribe pattern for application events. Code dispatches events; listeners subscribe to event names. Cleaner than direct callback chains.
• DependencyInjection: the service container. Define services with their constructor arguments and tags; let the container resolve and inject dependencies at runtime.
• Console: framework for command-line applications. Provides argument parsing, command organization, interactive prompts, progress bars, and output styling.
• Yaml: parses and dumps YAML files. The reason YAML is so common in PHP configuration these days.
• Validator: validates object property values against constraints declared in annotations, YAML, or PHP attributes.
• Serializer: converts objects to and from formats (JSON, XML). Used heavily in REST API code.
• Process: runs subprocess commands safely with timeout handling and output capture.

A useful mental model: Symfony components are PHP’s Lego bricks. Pick the bricks you need, snap them together, build whatever you want. The framework is a particular configuration of those bricks; nothing stops you from using a different configuration.

Who actually uses Symfony?

Far more projects use Symfony than the framework’s own user count would suggest, because the component library spreads the footprint:

• Drupal (versions 8 and later): the most prominent downstream consumer. Drupal core includes more than a dozen Symfony components and treats Symfony’s HTTP kernel as the request-handling foundation. Drupal 11 ships on Symfony 7. We cover the integration in depth in How Drupal Is Built on Symfony, and the broader Drupal 11 picture in Drupal 11 Explained.
• Laravel: a full-stack PHP framework in its own right, but uses several Symfony components under the hood (HttpFoundation for request handling, Console for the Artisan CLI, Process for subprocess execution, others). A Laravel developer is unknowingly using Symfony components on every request.
• Magento 2: the e-commerce platform uses several Symfony components, particularly EventDispatcher and Console.
• API Platform: a framework for building hypermedia-driven APIs, built directly on top of the Symfony framework. If you have built a JSON-LD API in PHP recently, you may have used API Platform without knowing it depends on Symfony.
• Joomla 4 and later: the rebuilt Joomla architecture incorporates Symfony components, including DependencyInjection and Console.
• OroCRM and OroCommerce: enterprise CRM and B2B commerce platforms built on the Symfony framework.
• Ibexa DXP (formerly eZ Platform): a digital experience platform built on the Symfony framework.
• PHPUnit: PHP’s standard testing framework uses Symfony components for its console interface.

The pattern is consistent: Symfony components show up wherever a PHP project needs a well-tested, well-maintained solution to a cross-cutting problem like HTTP handling, dependency injection, or command-line interfaces. The framework is one application of those components; the components have their own life beyond it.

Symfony’s release cadence and LTS

Symfony’s release schedule is one of the most predictable in the PHP ecosystem. The pattern:

• Minor releases every six months: in May and November. Each minor brings new features and deprecates the previous minor’s deprecated APIs.
• Major releases every two years: in November of every odd-numbered year. Each major removes the APIs marked for deprecation across the previous major’s minors.
• Long-term support (LTS) releases: the .4 minor of each major is designated LTS, receiving security fixes for three years past its release.

The recent and current versions:

Why this matters: the predictable cadence makes Symfony plannable. If you adopt Symfony today, you know roughly when the next major lands, when the deprecations you avoid become removals, and how long any given LTS will be patched. Few other PHP projects of any size offer that visibility.

The cadence is also what locks Drupal’s release schedule to Symfony’s. Each major Drupal version targets a Symfony LTS as its supported foundation, which is part of why Drupal 10’s December 9, 2026 end of life aligns to the Symfony 6 support window.

Should you learn Symfony as a Drupal developer?

Yes, with one nuance: you should learn Symfony components, not necessarily the Symfony framework itself.

Drupal developers spend most of their time touching Symfony components, even if they never open a Symfony documentation page. Every Drupal controller is a Symfony HttpKernel controller. Every Drupal service is a Symfony DependencyInjection service. Every Drupal route is a Symfony Routing route. Every Drush command is a Symfony Console application. Investing time in the Symfony documentation for HttpFoundation, EventDispatcher, and DependencyInjection is investing time in your Drupal proficiency, even though you may never use the Symfony framework directly.

The Symfony framework itself is worth learning if you also build non-Drupal PHP applications, or if you want to read Drupal core’s request-handling code with full context. For most Drupal developers, the components are the foundational investment; the framework is a useful expansion.

Frequently Asked Questions