Alexander Varwijk Proposes Core Redesign to Bring Async and Modern PHP Support to Drupal

Drupal core contributor Alexander Varwijk has proposed a significant restructuring of Drupal’s internal architecture to enable asynchronous processing, background tasks, and compatibility with modern PHP runtimes such as ReactPHP, FrankenPHP, and Swoole. His proposal centers on decoupling Drupal’s bootstrapping logic from the kernel and adopting Symfony’s Runtime component for greater flexibility across environments.

Currently, Drupal’s architecture is bound to a single request-response cycle, which makes it challenging to run tasks like sending notifications, handling websockets, or executing AI jobs in the background. Varwijk argues that by rethinking where and how Drupal’s kernel is initialized, the framework could extend beyond traditional page serving to power long-running, event-driven applications.

Why change is needed

Varwijk notes that DrupalKernel, the core of Drupal’s runtime, carries too many responsibilities: configuring environments, loading settings, managing multisite detection, and handling the request-response flow. This tight coupling limits Drupal’s ability to operate in asynchronous or persistent contexts. Front controllers such as index.php and drush.php are also bottlenecks, since they are controlled by site builders and deliberately kept minimal for upgrade safety.

Symfony Runtime as the solution

The proposal suggests adopting Symfony’s Runtime component, which abstracts environment-specific setup into pluggable runtimes. This would allow Drupal to run seamlessly across different environments — from Apache/PHP-FPM to FrankenPHP, ReactPHP, or CLI tools — without requiring changes to the front-controller. A custom DrupalRuntime class would determine how requests are created, while a DrupalKernelRunner would manage execution logic.

Key architectural ideas

• Introduce an AppContext class to manage configuration, site paths, and application context independently of the request.
• Shift environment setup, request creation, and error handling from DrupalKernel into modular runtimes.
• Enable placement of event loops like Revolt within the request lifecycle, allowing background tasks to run after responses are sent.
• Refactor multisite handling and settings loading to remove kernel-level assumptions and reduce guesswork.
• Clarify service container responsibilities, potentially enabling reuse across multiple requests in persistent applications.

Implications for developers

If adopted, these changes would allow Drupal to function not only as a CMS but also as a broader PHP application framework, capable of powering task queues, streaming APIs, and real-time services. Developers could run Drupal in persistent environments without modifying index.php or other project files, making experimentation and contrib innovation easier.

Next steps

Varwijk emphasizes that the work is still in the proposal stage, with many open issues to address. He intends to begin with Symfony Runtime integration, then proceed step by step through related restructuring efforts. Community feedback, collaboration, and review will be essential to moving these architectural discussions forward.

Developers are invited to share input on Drupal Slack, BlueSky, and the relevant issue queues. The full proposal and referenced issues are available on Alexander Varwijk’s blog.