So, last week was quite a big week, really. Both for me personally, more of that in a moment, and for the Drupal project as a whole, I think.
07 Oct 2026
Drupal.org aggregator
Dries Buytaert: State of Drupal presentation (September 2026)
Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.
Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.
Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.
Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.
Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.
If you missed the keynote, you can watch the video below or download my slides (86 MB).
More ways to reach more people
The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.
Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.
React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.
This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.
Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.
With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.
What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.
Opening Drupal's capabilities to other software
The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.
In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.
If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.
That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.
Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.
But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.
That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.
I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.
The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.
And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:
Talk louder about Drupal
In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.
Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.
So I announced the Drupal Advocacy Program, led by the Drupal Association.
Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.
The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.
If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.
Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.
That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.
I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.
It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.
You can learn how to earn Drupal advocacy credit and submit your advocacy work.
My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.
I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.
07 Oct 2026 7:50am GMT
The Drop Times: AI Neuron Connects Drupal AI With PHP Agents and Workflows
Drupal AI can keep control of providers and model settings while Neuron handles agents and workflows. The new bridge also brings Neuron objects into Drupal's plugin system.
07 Oct 2026 7:11am GMT
Gspikes: Drupal Multilingual: Migrating Translations Without Losing Them
One node, many translations: how Drupal's translation model works, why Drupal 7 migrations break it, and the configuration that has to be right afterwards.
07 Oct 2026 7:00am GMT
webchick: The October #DrupalOffTheIsland challenge
During the Driesnote at DrupalCon Rotterdam, one of the closing points was that Drupal has evolved light years beyond its reputation. And that's true. But it's also true that there is a whole world of people out there who've never heard of Drupal, and we need to talk about it differently to them than we do when talking amongst the Drupal-aware.
Enter The October "Off the Drupal Island" challenge.
The gist: During this, the spoooookiest month, go out to a local event (meetup, hackathon, etc.) where Drupal isn't, and no one has ever heard of "Drush" or a render array. ;) And ideally, where their local community presence is larger than ours.
For example:
- AI events
- JavaScript events
- WordPress events
- ...
NOT to pitch Drupal! To learn, quickly, and at scale. Be curious. Talk to people. Find out more about what they're building, where they're struggling, and what they wish was better.
Then, post a mini "field report" about your journey to this issue (there's a handy template there if you like).
We'll circle back on these learnings in a November AI Learners Club meeting, and strategize what kind of demo(s) we think would resonate best with these audiences, reflecting back their words and their use cases and pain points.
Then, we get louder about Drupal to them. ;) #DevRel at global scale.
Note: If you need extra incentive, perhaps because the idea of talking to strangers is slightly terrifying to you ;) note that this community research work qualifies you for credits under the new Drupal Advocacy program. \m/
For discussion, see LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7513498359781826560/
07 Oct 2026 6:58am GMT
06 Oct 2026
Drupal.org aggregator
rachel_norfolk: DrupalCon brings love in every drop
DrupalCon brings love in every drop
- Read more about DrupalCon brings love in every drop
- Log in with GitHub or Google to post comments. Or, if you came across this post via Mastodon, just reply there!
06 Oct 2026 8:19pm GMT
Aten Design Group: Freedom with the form Attribute: More Flexible Drupal Views Exposed Filters
Freedom with the form Attribute: More Flexible Drupal Views Exposed Filters
Drupal Views exposed filters tend to accumulate controls.
A basic search form may start with a keyword field and a few filters. Add sorting and an items-per-page selector, and Drupal naturally renders everything as part of the same exposed form.
That makes sense structurally. It does not always make sense visually.
Sorting often belongs above the results. Items per page may belong next to pagination. Filters might live in a sidebar or drawer.
The HTML form attribute gives us a simple way to separate those concerns.
Form controls do not have to live inside the form
Most of the time, an input belongs to the <form> that contains it.
But HTML allows controls to explicitly reference a form by ID:
<form id="search-form"> <input name="keywords"> <button type="submit">Search</button> </form> <select name="sort" form="search-form"> <option value="date">Date</option> <option value="title">Title</option> </select>
The <select> can live anywhere in the document and will still participate in search-form when it is submitted.
That is particularly useful with Drupal Views exposed filters.
Instead of forcing every exposed control into one visual group, Twig can put them where they make sense:
{{ exposed|without('sort_by', 'items_per_page') }} <div class="results-sort"> {{ exposed.sort_by }} </div> {{ rows }} <div class="results-footer"> {{ pager }} {{ exposed.items_per_page }} </div>
Then a form alter can associate those controls with the original exposed form:
/** * Implements hook_form_views_exposed_form_alter(). */ function example_form_views_exposed_form_alter( array &$form, FormStateInterface $form_state, string $form_id, ): void { foreach (['sort_by', 'items_per_page'] as $key) { if (isset($form[$key])) { $form[$key]['#attributes']['form'] = $form['#id']; } } }
Drupal still owns the form. The browser still understands which controls belong to it. The template gets considerably more freedom.
The same technique can help with controls in sticky toolbars, dialog footers, complex search layouts, or other interfaces where form controls need to appear outside their natural DOM container.
There are a few tradeoffs
Moving controls outside the form changes more than layout.
JavaScript that relies on closest('form') will no longer work. CSS such as form select will not match detached controls. Events from those controls also do not bubble through the form element because the form is no longer their DOM ancestor.
The form ID also becomes part of the implementation contract, which matters when multiple Views or exposed forms appear on the same page.
These are manageable constraints, but they are worth documenting.
The form attribute gives us form ownership, not DOM nesting.
Maybe this should be contrib
There is also a small but interesting Drupal contrib opportunity here.
A module could allow site builders to configure which exposed Views elements should receive a form attribute and which should autosubmit.
The theme would remain responsible for placement. The module would simply provide the form association and optional behavior.
That could eliminate a recurring bit of project-specific PHP and JavaScript while relying primarily on native browser behavior.
For a relatively obscure HTML attribute, form opens up a useful amount of flexibility in Drupal Views. It lets the markup follow the interface instead of forcing the interface to follow the form.
For additional information on the form attribute, checkout the docs.
06 Oct 2026 7:19pm GMT
Droptica: Beyond SEO: what we check in a Drupal AI-readability audit
A buyer asks an AI assistant about your product, but the answer sits behind a click or an outdated page. A Drupal AI-readability audit checks whether intended services can reach your content, whether HTML delivers useful answers, and whether facts stay consistent across outputs.
Maciej Lukianski walks through five layers beyond classic SEO: access, delivered HTML, buyer questions, JSON-LD alignment, and multilingual consistency, plus what actionable findings should look like.
06 Oct 2026 3:48pm GMT
Droptica: Drupal vs Contentful, Sanity, and Storyblok
Choosing a CMS for catalogues, multilingual pages, and integrations means comparing how each platform handles relationships, editorial work, and delivery-not just content types on a slide.
Drupal vs Contentful, Sanity, and Storyblok take different paths: integrated application vs managed headless services, core translation and moderation vs SaaS localization, and visual editing vs configurable Drupal workflows. Maciej Lukianski walks through content models, permissions, JSON:API options, AI boundaries, and what growth costs look like on each stack.
06 Oct 2026 3:14pm GMT
Gábor Hojtsy: Meet Dashi, the 'new' multilingual demo for Drupal CMS
Meet Dashi, the 'new' multilingual demo for Drupal CMS
On September 29, Dries Buytaert showed a multilingual food magazine demo in his DrupalCon Rotterdam Driesnote. That was Dashi, the culmination of our work to give Drupal CMS 2.2 standout multilingual features. Here is what it is, how you can try it and how it came to be.
06 Oct 2026 2:17pm GMT
Jacob Rockowitz: Vibing Drupal: Tale 2 - Using AI to maintain a module, exploring the AI-possible
Introduction
Adopting AI can feel overwhelming, so I am sharing a few tales from my experience creating, maintaining, and assisting with contributed Drupal modules. AI can do a decent job building a "greenfield" Drupal module from scratch, so my first tale is about using AI to build and contribute a module. For my next tale, I want to talk about using AI to maintain an existing "brownfield" Drupal module.
Growing up in NYC, I found brownfields often intimidating, with some so toxic that it can take years for backhoes and dump trucks to remove the contaminated topsoil before construction can begin. With code, a brownfield can contain technical debt, orphaned code, missing tests, etc. Simply put, a brownfield contains unknowns, which means more things can go wrong while working on it. Sometimes a brownfield is so big you need heavy machinery to maintain it, and that is exactly how I felt about using AI on the Schema.org Blueprints module.
Maintaining a large module using AI
Gradually, I have been experimenting with AI to help maintain the Schema.org Blueprints. At first, I would just throw a one-shot prompt at the AI to address a single issue, and it would do a decent job diagnosing and resolving the problem. As I became more confident steering the AI, I started asking it to create issue forks, commits, pushes, and even MRs. As I previously stated in my AGENTS.md I always have "Require me to review all changes before committing and pushing code." and most models respect this rule.
My comfort level reached a point where I am creating {module}-issue-maintenance agent skills that extend my drupalorg-issue-maintenance skills. These maintenance skills have agents to track remote issues in...Read More
06 Oct 2026 9:40am GMT
joshics.in: Drupal 12 and the End of Legacy Debt: A Forced Modernization for Enterprise Engineering
Drupal 12 and the End of Legacy Debt: A Forced Modernization for Enterprise Engineering bhavinhjoshi
Just last month, a prospective client came to Joshi Consultancy Services asking for a cheap cron script to fix a runaway disk usage issue. The reality? They were bleeding money on a deep architectural flaw in their Drupal ingestion pipeline. We see this constantly. For years, the enterprise software industry tolerated a quietly expensive habit: carrying technical debt forward.
Historically, major CMS upgrades were treated as little more than UI refreshes. Agencies seamlessly dragged deprecated code, outdated PHP environments, and fragile database structures from one major version to the next. The result? Senior engineers stuck acting as caretakers for legacy code, while CXOs bled budget on endless maintenance retainers just to keep the lights on.
With the December rollout of Drupal 12, that loophole permanently closes.
The platform is fundamentally altering the rules of engagement. Instead of merely suggesting best practices, Drupal 12 enforces strict architectural modernization right at the server level. Here is why this shift is a massive win for both engineering teams and business leadership.
The Eradication of Deprecated APIs
Spaghetti code. We all hate it. But until now, deprecated code could linger in a system for years, propped up by complex workarounds.
Drupal 12 changes this by aggressively stripping out all deprecated core APIs. The system physically rejects structural laziness. If an agency attempts to stack new logic on top of a legacy foundation, the application simply will not run. You build within clean, modern boundaries from day one. Period.
Enforcing Modern Infrastructure Floors
Previously, organizations delayed server upgrades to save short-term costs, forcing modern applications to run on aging environments.
No longer. Drupal 12 introduces non-negotiable infrastructure floors: a PHP 8.5 minimum runtime alongside raised database requirements (MySQL 8.0 / PostgreSQL 18). This isn't just backend housekeeping. By enforcing these modern tiers, the core framework guarantees a baseline of performance that cannot be compromised by budget-saving shortcuts.
Security as a Structural Guarantee
Enterprise security is too often treated as an expensive, opt-in audit layer applied long after development is complete.
By making Argon2id the default for password hashing, Drupal 12 integrates military-grade resistance against GPU-driven brute-force attacks directly into the core blueprint. For the C-suite, this is an immediate reduction in liability. Security transitions from an ongoing maintenance headache to a baseline structural guarantee.
The Business Outcome: Eliminating the Maintenance Drain
The most profound impact lands directly on the balance sheet.
For CXOs, these forced architectural boundaries solve the most expensive problem in enterprise software: unpredictability. When the core framework refuses to execute legacy PHP and automatically enforces top-tier security standards, the financial drain of technical debt is cut off at the source. Organizations can finally stop paying agency retainers to manage bloated, unmaintainable code.
Drupal 12 is not just a feature upgrade. It is a forced modernization of your engineering culture.
If your organization treats this version bump as a standard IT afterthought, you are actively funding your own future liability. Stop paying for temporary bug fixes. Engineer the blueprint first.
Are your servers, and your budgets, ready for the rollout?
06 Oct 2026 8:32am GMT
DevCollaborative: From Costly Subscriptions to Streamlined Workflow
The National Center for Family Philanthropy worked with DevCollaborative to reimagine their website, CRM, and other communications channels to effectively manage and scale their network of over 500 philanthropic families representing more than 3,000 individuals.
06 Oct 2026 6:53am GMT
Specbee: The tools around Drupal have become simpler, complementing Drupal. Read our take on how Canvas, components, Drupal CMS, and AI are changing Drupal work.
The tools around Drupal have become simpler, complementing Drupal. Read our take on how Canvas, components, Drupal CMS, and AI are changing Drupal work.
06 Oct 2026 5:39am GMT
Peoples Blog: Drupal Already Manages Content. So What Does AI Actually Add?
AI is becoming part of almost every software platform, and content management systems are no exception. Drupal is no different. But there is an important question that often gets lost in the excitement around AI: if Drupal already manages content so well, what exactly does AI add?
06 Oct 2026 2:41am GMT
DDEV Blog: Docker Provider Performance, 2026: Now Measured Every Night
TL;DR
macOS Docker provider performance has improved significantly over the years, and now all the providers seem to be performing about equivalently. So OrbStack, Docker Desktop, Lima, Colima, and Rancher Desktop are fast and working well.
Introduction
Back in November 2023 we published a hand-run comparison of macOS Docker providers. It was a snapshot: one laptop, one afternoon, one set of versions, and a Google Sheet. It answered the question people were asking, and then it started going stale the moment it was published.
That post is gone now, and this one replaces it, because the way we answer the question has changed. DDEV now runs the same benchmark battery every night, unattended, on every platform and Docker provider we support, and publishes the accumulated history.
Table of Contents
Where to see the numbers
The nightly results live at the DDEV performance history dashboard.
The easiest way to find it (and everything else the DDEV GitHub organization publishes) is to start at github.com/ddev/ddev.github.io and follow the "Performance History" link. That repo's README is the index of DDEV's GitHub Pages sites - bookmark it and you don't have to remember any of the other URLs.
The dashboard has two views. Trend over time plots one line per leg so you can see regressions and improvements as they land. Compare environments (latest) gives you a sorted bar chart of each environment's recent median, which is the view that most directly replaces the 2023 post's charts.
Which metric to compare
The harness collects six metrics per run. The one that lines up with the 2023 post is drupal_install_s: Puppeteer drives the Drupal web install wizard end-to-end, in a real browser, through the DDEV router, the web server, and PHP-FPM.
I think it's important that it uses a web-intensive install process for studying web server performance. The interactive installer deliberately breaks each batch step into its own HTTP request and page reload, so every one of those round trips exercises exactly the layer where Docker provider differences show up - bind mount vs. Mutagen, gRPC-FUSE vs. virtiofs, and so on. It's the closest thing in the suite to "what does it feel like to actually use this."
The companion metric drush_install_s runs the same install non-interactively via ddev drush si, which never touches the router or web server at all. If the two track together, filesystem I/O dominates; if they diverge, the gap isolates router/web server overhead. The perf/README.md describes all six metrics and why each one is there.
macOS results
Medians of the nightly runs from 2026-08-31 through 2026-09-30, drupal_install_s in seconds, fastest first. All legs are Apple Silicon (ARM64), all with Mutagen enabled except where noted.
| Docker provider | drupal_install_s |
drush_install_s |
ddev_start_cold_s |
|---|---|---|---|
| Rancher Desktop | 12.0 | 9.8 | 16.5 |
| Lima | 12.1 | 9.9 | 15.8 |
| Podman (rootless) | 12.3 | 9.9 | 46.0 |
| Colima (vz) | 12.6 | 10.0 | 14.4 |
| OrbStack | 13.4 | 10.4 | 12.2 |
| Docker Desktop | 16.7 | 13.4 | 21.0 |
| OrbStack, no Mutagen | 16.8 | 11.2 | 9.2 |
The headline is how boring this table is. Five of the six Mutagen-enabled macOS providers land within 1.4 seconds of each other on the flagship metric, and their drush_install_s numbers are within 0.6 seconds. On macOS with Mutagen, your choice of Docker provider is mostly not a performance decision anymore. Pick based on licensing, maintenance, and how the tool fits your workflow.
That is a significant change from 2023, when OrbStack was clearly ahead and Colima and Rancher Desktop looked sluggish. Those gaps have largely closed (all are now using VZ/VirtioFS).
Compared with the 2023 numbers
The 2023 test did a Drupal 10 web install with Mutagen and got OrbStack 20s, Docker Desktop 22s, Rancher Desktop 22s, Colima QEMU 33s, and Colima VZ 35s. The fastest then (OrbStack, 20s) compares with 12.0s for the fastest now (Rancher Desktop), and with 13.4s for OrbStack. The slowest providers gained the most: Rancher Desktop went from 22s to 12.0s and Colima VZ from 35s to 12.6s. The spread between providers went from 15 seconds to about 1.4 (excluding Docker Desktop).
Treat these as a rough comparison, not a like-for-like benchmark. The 2023 numbers came from one MacBook Air M1 (2020) on a single afternoon, with DDEV v1.22.5, Drupal 10.1.6, and PHP 8.1. The nightly runs use CI runner machines, and newer DDEV, Drupal, and PHP versions. Both tests drive the demo_umami install through Puppeteer. Each Docker provider has also shipped many releases since 2023, and the Colima leg now uses VZ where one of the 2023 legs used QEMU with sshfs. Some of the improvement comes from the hardware, and some from the software.
When DDEV was young, a web install with Docker Desktop took SEVEN MINUTES. You'd just watch it poke along at each section. Now you don't even see those as they flash by. Now it takes 12-17 seconds. That's progress!
Mutagen is still doing the work
The most interesting row is the last one. OrbStack with Mutagen finishes the browser install in 13.4s; the same provider without Mutagen takes 16.8s - about 25% slower. Note that the no-Mutagen leg is faster on ddev_start_cold_s (9.2s vs. 12.2s), because there's no sync session to establish, and closer on drush_install_s (11.2s vs. 10.4s), because Drush never goes through the web server. The penalty concentrates in exactly the browser-driven path, which is what you use all day.
Mutagen is on by default on macOS for this reason, and these numbers say to leave it on.
However, plenty of people are perfectly happy with turning off Mutagen. Some folks don't like the additional complexity and don't want the speed trade-off. ddev config global --performance-mode=none turns it off. (Mutagen has more benefits than just performance though; with Mutagen, the web server in the container is dealing with a Linux filesystem, more like the real deployment environment, instead of a Docker bind-mount, which is more like a network filesystem.)
:::warning[Read the hardware caveat before comparing rows] The Docker Desktop leg runs on older M1 test runner machines that have dedicated hardware. OrbStack, Rancher Desktop, Colima, Lima, and Podman share a pool of newer machines. Some of the Docker Desktop gap in the table above is that hardware difference, not the provider. We didn't normalize it - the dashboard deliberately doesn't either - so treat Docker Desktop's row as "somewhat pessimistic" rather than as a clean like-for-like comparison. :::
The other platforms, and why you shouldn't rank them against macOS
The dashboard also carries Linux, WSL2, and traditional Windows legs. They're useful for spotting regressions within a leg over time, but the cross-platform bar chart is misleading if you read it as a platform ranking:
- The Linux leg runs on ephemeral GitHub-hosted runner VMs. It provisions the Drupal codebase from scratch every night and starts with cold image, Composer, and OS page caches. Every macOS and Windows leg reuses a persistent codebase and warm caches.
- The Windows and WSL2 legs run on entirely different physical hardware from the macOS test runners.
Trends within a leg: meaningful. Bar-chart comparisons across legs: only meaningful when the machines are comparable, which across platforms they aren't.
Getting the raw data
Every chart on the dashboard has a Download CSV button that exports exactly the rows behind whatever is currently displayed - after your leg and metric selections, not the whole dataset. That's the quickest path to your own analysis.
If you want everything, the underlying dataset is one JSON object per line at history.ndjson, with one line per (commit, leg) benchmark run:
curl -sL https://ddev.github.io/ddev/perf/history.ndjson |
jq -r 'select(.os=="darwin") | [.timestamp, .docker_provider, .metrics.drupal_install_s] | @tsv'
Running it on your own machine
The harness that replaced the old ddev-puppeteer script lives in the DDEV repository and runs locally against a standard DDEV Drupal project:
./perf/run-benchmark.sh \
--project-dir ~/workspace/d11 \
--site-url https://d11.ddev.site/ \
> result.json
It needs jq and Node.js on your PATH in addition to the usual DDEV prerequisites. If your numbers look very different from the nightly legs, we'd like to hear about it.
Summary
Three years ago the answer to "which Docker provider is fastest on macOS?" was worth a blog post with charts. Today the simple answer is that, with Mutagen on, they're close enough that the question is mostly settled, and any lingering differences are small next to the hardware you're running on.
What's better than a fresh answer is a standing one. The nightly harness means the next time performance shifts - a provider regression, a Mutagen improvement, a DDEV build-layer mistake - it shows up on the dashboard within a day, instead of waiting for somebody to run the numbers by hand and write another post.
Have questions, or numbers that look different from the dashboard? Join the conversation in our Discord, open an issue, or reach out via email.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
06 Oct 2026 12:00am GMT
05 Oct 2026
Drupal.org aggregator
Freelock Blog: Beyond Bigger Servers: Keeping Websites Online Under Bot Attacks
Beyond Bigger Servers: Keeping Websites Online Under Bot Attacks
How layered caching, verified crawlers, and adaptive Anubis protection kept a WordPress publishing site available for readers and editors.
05 Oct 2026 10:00pm GMT
Add new comment