Drupal 11.4 quietly shipped something the community has wanted for years: a command-line tool built into core itself. The new dr command is not a plugin, not a contributed module, and not a third-party dependency. It comes with Drupal. That is a bigger deal than the version bump suggests, and it has real consequences for how agencies structure deployments, CI pipelines, and project onboarding.
What shipped
For as long as most Drupal developers can remember, Drush has been the de facto CLI for Drupal. It handles cache rebuilds, database updates, configuration imports, cron runs, and deployment scripting. It is so ubiquitous that Drush commands show up in platform documentation (Pantheon, Acquia, Platform.sh) as if they were core features. The catch: Drush is a separate dependency. You install it via Composer, you pin a version, you maintain compatibility between your Drupal version and your Drush version, and you absorb any breakage when the two fall out of sync.
Drupal 11.4 changes that baseline by introducing dr, a native CLI that core maintains and ships. The initial scope is focused on the commands that matter most in automated contexts: cache rebuild, database updates, configuration import and export, cron execution, and status checks. The command syntax is deliberately familiar to anyone who has used Drush. Running php core/scripts/dr cache:rebuild or php core/scripts/dr updatedb will feel immediately recognizable.
The implementation uses PHP's built-in CLI capabilities rather than requiring any additional runtime. There is no Node.js dependency, no separate binary to install, and no version pinning outside of Drupal itself. When you composer update drupal/core, the CLI updates with it. That is the core value proposition: one fewer moving part in a stack that often has too many.
The Metadrop writeup does a thorough job explaining the years of discussion that preceded this, including the technical reasons it took this long (bootstrapping complexity, Symfony Console integration, scope debates) and how the team finally landed on an approach that was narrow enough to ship but useful enough to matter.
Our take
This is one of those changes that sounds incremental but reshapes how we think about a project's dependency surface. Here is what we are actually taking away from it.
Drush is not going anywhere, and that is fine. Drush has a 15-plus year head start and a massive surface area: site aliases, remote execution, generate commands, contrib-specific integrations, the works. Core's dr command is not trying to replace all of that. Think of it as the zero-dependency floor. Every Drupal site now has a reliable baseline CLI available without any additional setup. Drush remains the power tool for complex workflows. We are not recommending anyone rip Drush out of their projects.
The onboarding and scaffolding win is real. When we set up a new Drupal project, getting a junior developer or a client's in-house team to a working local environment involves explaining Drupal, Composer, and Drush simultaneously. With dr in core, the critical commands (cache rebuild, config import, database updates) are available the moment Drupal is installed. That trims the "what do I run after pulling the repo" question down to one tool instead of two.
CI pipelines get simpler for straightforward sites. Our standard Drupal CI pipeline runs roughly: composer install, drush updatedb, drush config:import, drush cache:rebuild. With 11.4, the Drush steps in that sequence can be replaced with dr equivalents for sites that do not need Drush's extended feature set. That removes a dependency from the pipeline and eliminates one version compatibility variable. For greenfield projects starting on 11.4, we will default to dr for those steps and only pull Drush in when we actually need something it uniquely provides.
Platform documentation will be the bottleneck. Pantheon, Acquia, and WP Engine's Drupal offering all have Drush assumptions baked deep into their platform tooling. SSH commands, terminus wrappers, and one-click update flows all reach for drush. That will not change overnight. For managed hosting clients, we will continue using Drush for platform-facing operations until hosting providers update their documentation and tooling to recognize dr.
The version coverage question matters. If you have Drupal sites below 11.4, and most agencies do, dr is not available on those. Keeping Drush in the toolkit for the foreseeable future is not optional; it is just reality. This is an 11.4-forward improvement, and the practical payoff builds as your portfolio migrates forward.
The honest summary: dr in core does not change what is possible. It changes what is required. That is a different kind of improvement, quieter but more durable.
Practical recommendations
- Greenfield Drupal projects starting on 11.4: default to
drfor cache, config, and update operations in CI. Add Drush only when you hit a gap. - Existing projects: no urgency to swap out Drush. Note the change, add
drto your team's mental model, revisit at the next planned dependency audit. - Managed hosting clients: continue using Drush for all platform-mediated operations until your hosting provider's documentation explicitly supports
dr. - Junior developer onboarding docs: worth adding a note that 11.4-plus sites have a native CLI. It reduces the "I forgot to install Drush" support ticket.
- Evaluate your Drush version pins: if you are running Drush 12 or 13 on older Drupal 11.x projects, the 11.4 upgrade path is a natural moment to audit compatibility and simplify where possible.
Originally referenced: Drupal CLI in core finally landed in 11.4, how and why we got here on Metadrop.
If you are managing a portfolio of Drupal sites and want help thinking through your 11.4 upgrade path, CI pipeline simplification, or dependency audits, get in touch.
