Drupal shipped a native CLI called dr — and the Drush maintainers built it
I've typed drush so many times over the years my fingers do it without me. So the line in the Drupal 11.4.0 release notes stopped me: there's now a native command-line tool in core, called dr, and it was built by a team that includes the Drush maintainers. When the people who make the tool you rely on help build its replacement, that's not a footnote. That's a succession plan.
What actually shipped
Drupal 11.4.0 landed on 1 July 2026 with an experimental, extensible CLI you invoke as ./vendor/bin/dr. "Experimental" and @internal are the operative words — this is a first step, not a finished product. One naming note if you go reading older posts: during development the binary was called drupal (Moshe Weitzman's own write-up from February still uses that name), but it was renamed to dr before release. The shipped command is dr.
Under the hood it's built on the Symfony Console component — the same foundation as Drush — and it's genuinely extensible: a module drops a class in src/Command/ with a #[AsCommand] attribute and it's auto-discovered, no services.yml wiring. That attribute-first approach will feel familiar if you've been converting hooks to #[Hook].
What it can and can't do today
The honest state of it: dr can rebuild caches, run cron, do a site install and quick-start, run recipes, and hand you a one-time login link. That's a real, useful early set. What it can't do yet is most of what I actually reach for Drush for day to day — database updates, installing and uninstalling modules, config import/export, running SQL. So this is not a drop-in Drush replacement in July 2026, and anyone telling you to rip Drush out of your scripts is jumping the gun. (I've seen "the rest arrives in Drupal 12" floating around, but I couldn't find that on an official roadmap, so treat it as rumour.)
So is Drush dying?
The maintainers are refreshingly blunt about the direction. The release notes say plainly that "a transitional period starts as Drush is gradually replaced with the core dr CLI over time." And Weitzman — a Drush maintainer — wrote back in February, in a post literally titled about Drush's final act: "My end goal here is the death of Drush. It has served an incredibly long and useful life." He also stressed the off-ramp is long: "it is trivial to run Drush commands along with Drupal commands. Sites will have years to convert their scripts."
When the tool's own maintainers say the goal is its death, that's not abandonment — it's a maintainer choosing to build the successor themselves rather than let one get bolted on badly.
I find that reassuring, actually. The failure mode for a project like Drush isn't a planned sunset with a multi-year transition and the original authors steering it. The failure mode is a maintainer burning out and the thing rotting quietly (more on that in a moment — it's a theme in Drupal-land this month). This is the good version of the story.
What I'm doing on this blog
Nothing yet, and that's the correct answer. My deploy still runs drush deploy on every container start, and it'll keep doing that because dr can't do updb + cim + cr in one shot yet. What I did do is ./vendor/bin/dr list on a local checkout to see the shape of it, rebuild a cache with it, and note where it falls short. That's the right level of engagement for an experimental core feature: kick the tyres, understand the trajectory, don't bet a production pipeline on it.
The reason to care now, before it's finished, is that greenfield habits calcify. If you're starting a fresh project, it's worth writing new tooling scripts so they're easy to point at dr later — thin wrappers, not a thousand hard-coded drush calls. The transition will be years, but "years" has a way of arriving while your muscle memory is still typing the old command.