How Drupal Is Built on Symfony: A Look Under the Hood

Drupal moved from a homegrown PHP application stack to a Symfony foundation in 2015 with Drupal 8, and never looked back. Today’s Drupal 11 (which we cover in our pillar overview) sits on top of Symfony 7. For developers and architects making technology decisions, the Drupal Symfony relationship is not a footnote: it shapes how Drupal handles HTTP, how modules register services, how the request lifecycle runs, and ultimately when each major Drupal version ships and reaches end of life.

This post explains which Symfony components Drupal uses, how the integration actually works at the code level, and why Drupal’s release cadence now tracks Symfony’s long-term support schedule. If you’re considering Drupal for a new project, leading a Drupal upgrade, or trying to understand why a Drupal 10 module needs to think about Symfony 6 services, this is the architecture under your feet.

A short history: when Drupal adopted Symfony

In 2011, the Drupal core developers faced an architectural choice. Drupal 7 had been built on a custom PHP foundation that was uniquely Drupal: its own request handling, its own dependency loading, its own routing. That uniqueness was also Drupal’s growing burden. Every architectural problem Drupal needed to solve had to be solved by Drupal contributors alone. The broader PHP community, which was rapidly modernizing around standards like PSR autoloading and HTTP-driven application design, was moving past Drupal’s idiomatic patterns.

Drupal 8, released November 19, 2015, made the call to rebuild on Symfony. The official announcement from the Symfony team at the time (Symfony2 meets Drupal 8) described the integration as adopting Symfony as Drupal’s HTTP kernel while keeping Drupal’s own opinions about content, theming, and configuration.

The shift was substantial. Drupal 8 incorporated more than a dozen Symfony components into core. The hook system that defined Drupal 7’s module API was supplemented (not yet replaced) by Symfony’s event dispatcher pattern. The custom routing system was replaced by Symfony Routing. Dependency loading moved from module_load_include to PSR-4 autoloading. The release was, by Drupal community consensus, the biggest architectural shift in Drupal’s history.

Three Drupal majors later, the Symfony foundation is now part of Drupal’s DNA. Every major Drupal version since 8 has upgraded to a newer Symfony major, and the cadence patterns the two projects share now structure how both communities plan releases.

Drupal Symfony components in core

Drupal core depends on roughly a dozen Symfony components. The ones you’ll encounter most directly:

• HttpFoundation: provides the Request and Response objects that Drupal uses internally to represent incoming HTTP requests and outgoing responses. Any Drupal controller signature with Request $request is using HttpFoundation.
• HttpKernel: orchestrates the request-to-response lifecycle. Drupal’s DrupalKernel extends Symfony’s HttpKernel, hooking into its events to insert Drupal-specific behavior (authentication, language negotiation, breadcrumbs).
• Routing: maps URLs to controller methods. Drupal module routing.yml files use the same syntax as Symfony route configuration, with Drupal-specific extensions for access checks and route options.
• EventDispatcher: provides the publish-subscribe pattern that Drupal uses for server-side events. Event subscribers are the modern replacement pattern for many legacy hook_X implementations.
• DependencyInjection: provides the service container that Drupal modules use to declare services in YAML. At runtime the container knows about every service in core and every contributed module.
• ClassLoader: PSR-4 autoloading. Drupal stopped maintaining its own loader in favor of Symfony’s, which integrates cleanly with Composer’s autoloader.
• Yaml: parses the YAML files Drupal uses for routing, services, configuration, schema, and more. Drupal’s heavy YAML dependency stems directly from the Symfony adoption.
• Console: underpins Drush and the historical Drupal Console. The command-line tools you use to manage Drupal sites are Symfony Console applications under the hood.
• Process: provides safe subprocess execution. Modules that shell out to other commands use Process to do it portably.
• Serializer: handles object-to-format and format-to-object transformations. The REST and JSON:API modules in Drupal core rely on it.

Several more components ship transitively (DomCrawler, BrowserKit, and CssSelector for testing; Filesystem and Finder for file operations). The Symfony components catalog is the canonical list; the ones above are the components Drupal developers encounter most often in day-to-day module work.

HttpKernel and the Drupal request lifecycle

The HttpKernel component is where the integration runs deepest. Every Drupal request flows through Symfony’s HttpKernel events. Understanding that flow is what separates Drupal developers who write modules that work in any context from developers who write modules that mysteriously fail outside the admin form they were tested against.

The lifecycle, in order:

1. kernel.request: the request has been parsed but no routing has happened yet. Drupal subscribes here for authentication, language negotiation, and maintenance-mode redirects.
2. Routing: the URL is matched to a route. The matched route knows which controller will handle the request.
3. kernel.controller: the controller has been resolved but not yet invoked. Last chance to swap controllers or modify arguments.
4. Controller execution: the controller method runs and returns a value (a Response, or something convertible to one).
5. kernel.view: fires when the controller did not return a Response. Drupal subscribes here to render Drupal-specific return types (render arrays) into proper Responses.
6. kernel.response: the response is built but not yet sent. Drupal subscribes here for content-type negotiation, cache headers, and the page cache.
7. Response sent: the response is dispatched to the client.
8. kernel.terminate: fires after the response is sent. Long-running cleanup happens here without blocking the user (cache warming, logging, queue processing).

For module developers, the practical implication is that anything you want to do during a request has a designated lifecycle stage. Want to modify the response before it ships? Subscribe to kernel.response. Need to authenticate every request before routing? Subscribe to kernel.request at high priority. Want to do expensive work that should not delay the user? Subscribe to kernel.terminate.

EventDispatcher: hooks evolving into events

Drupal’s legacy hook_X system is still in core. Modules can still implement hook_form_alter, hook_node_view, hook_user_login, and hundreds of other hooks. The hook system works the way it always did: Drupal’s invocation code iterates every module’s implementations and calls them in turn.

What changed in Drupal 8 is the addition of event subscribers as a parallel pattern. Where a hook implementation is a magic function name in a .module file, an event subscriber is a service class with declared dependencies, typed arguments, and an explicit subscription declaration.

A minimal event subscriber:

namespace DrupalexampleEventSubscriber;

use SymfonyComponentEventDispatcherEventSubscriberInterface;
use SymfonyComponentHttpKernelEventResponseEvent;
use SymfonyComponentHttpKernelKernelEvents;

class ExampleResponseSubscriber implements EventSubscriberInterface {

  public function onResponse(ResponseEvent $event): void {
    $response = $event->getResponse();
    $response->headers->set('X-Powered-By', 'Drupal');
  }

  public static function getSubscribedEvents(): array {
    return [
      KernelEvents::RESPONSE => 'onResponse',
    ];
  }
}

Register that class as a service in example.services.yml, tag it as event_subscriber, and the container does the rest. The same logic implemented as a hook would require a magic function name, would not be typed, would not be testable in isolation, and would not declare its event dependency anywhere a developer could grep for.

Drupal core’s direction is clear: new functionality lands as event subscribers; the hook system is maintained but not extended. The pragmatic guidance for module developers in 2026 is to use event subscribers for new code and to keep hook implementations for backwards-compatible integration with older modules. The full transition will take many more release cycles; the direction is set.

DependencyInjection and the YAML service container

Every Drupal service (a class that does work for other code) is registered with the container. The container knows how to construct each service, what dependencies to inject, and how to share or rebuild instances.

A service registration in example.services.yml:

services:
  example.report_generator:
    class: DrupalexampleServiceReportGenerator
    arguments:
      - '@entity_type.manager'
      - '@logger.factory'
      - '@config.factory'
    tags:
      - { name: backend_overridable }

This declares a service named example.report_generator, of class ReportGenerator, constructed with three dependencies injected from the container: the entity type manager, the logger factory, and the configuration factory. Drupal core knows how to provide those because they themselves are services registered in core.services.yml.

When module code needs the report generator, it asks the container:

$generator = Drupal::service('example.report_generator');

In a class that itself is a container service, dependencies are injected through the constructor automatically. The container resolves the chain of dependencies and returns a fully-constructed instance ready to use.

This is a meaningful architectural shift from Drupal 7’s pattern of calling global functions. With dependency injection, services are testable in isolation (mock the dependencies), swappable at runtime (override a service definition to substitute a custom class), and explicit about what they need (the constructor signature documents everything). Modern Drupal development is, in large part, the practice of organizing functionality into services and wiring them through the container.

Why Drupal’s release cadence tracks Symfony’s LTS

This is where the integration story affects operators, not just developers.

Symfony’s release pattern: a new major every two years, with the .4 minor of each major designated as long-term support (LTS) for an additional three years. The recent cadence:

Drupal’s release pattern aligns to these LTS anchors. Each Drupal major adopts a Symfony major that has reached LTS (or is about to), so that Drupal’s three-to-four-year support window for each major can be backstopped by Symfony’s stable, security-patched components.

The mapping in practice:

• Drupal 8 (2015, EOL November 2021): shipped initially on Symfony 2.x; moved through Symfony 3 and 4 over the branch’s lifetime.
• Drupal 9 (June 2020, EOL November 2023): shipped on Symfony 4.4 LTS.
• Drupal 10 (December 2022, EOL December 9, 2026): shipped on Symfony 6.
• Drupal 11 (August 2024): ships on Symfony 7.
• Drupal 12 (planned 2026): expected to track Symfony 7.4 LTS as its supported foundation.

The implication for operators is concrete. Drupal 10’s EOL on December 9, 2026 (covered in detail in our companion piece on the deadline) is not arbitrary. It tracks the moment when Symfony 6 leaves active support and only the LTS branch of Symfony 6.4 remains, and Drupal core no longer wants to backport security work to a non-LTS Symfony.

This is also why the Drupal 10 to 11 migration involves more than just an ^11 constraint in Composer. A site moving to Drupal 11 is also moving its underlying framework from Symfony 6 to Symfony 7, with all the deprecation cleanups that implies for any custom code touching Symfony classes directly.

What this means for Drupal developers in 2026

If you are coming to Drupal as a developer in 2026, the practical guidance:

• Symfony knowledge transfers: time spent learning Symfony components is time spent learning Drupal internals. The investment compounds across both ecosystems.
• The hook system is legacy code: still functional, still used, but the active direction is event subscribers and services. Lean into the modern pattern for new work.
• The YAML service container is non-negotiable: every module of any complexity registers services. Understanding how to declare, inject, and consume services is foundational, not advanced.
• The Symfony ecosystem is your toolkit: Composer-installed Symfony components, Symfony documentation, Symfony Slack and forum communities, and Symfony’s broader contributor base are all resources Drupal developers can lean on directly.

The Drupal Symfony relationship is no longer an architectural curiosity. It is the architecture. A Drupal developer who understands Symfony deeply has a significantly easier time reading core code, writing performant modules, and reasoning about why Drupal does the things it does.

Frequently Asked Questions