Install modules from the admin UI — the catch nobody puts on the slide
Drupal's Project Browser hit its first stable release, and the headline is the one site builders have wanted for fifteen years: browse modules in the admin UI, click "Add and Install," done. No Composer, no command line. It's genuinely lovely. It also comes with a catch that the demos skate past, and the catch is the most interesting part, because it's a security decision wearing the disguise of a limitation.
What shipped
Project Browser reached stable (the 2.0.0 release in October 2025; 11.4 support landed in the 2.1.x line, and it's covered by the security advisory policy). You get an in-admin catalogue of contrib modules with search, filtering, and — the marquee feature — an "Add and Install" button. Behind that button, it drives core's Package Manager, the framework spun out of the Automatic Updates initiative, which runs Composer for you: it makes a temporary copy of your site, runs composer require there, and syncs the result back. Real Composer, real dependency resolution, no terminal.
The catch nobody puts on the slide
For "Add and Install" to work, the web server user needs write access to your codebase — core, modules, themes, and the vendor directory. And the project's own documentation is explicit that this is intended for local development, e.g. DDEV, not production. That's not an oversight or an unfinished feature. It's the whole security model.
Think about what a writable codebase means. Package Manager itself spells it out: a Drupal application whose own code and vendor directory are writable by the web process is a much larger attack surface, because a compromised PHP process could rewrite the very code it's executing. That's precisely the property that managed hosts like Acquia and Pantheon deliberately forbid — production codebases there are read-only on purpose. So the one-click install can't run in those environments, and shouldn't, and that's by design.
The reason you can't one-click-install modules on production isn't that the feature is unfinished. It's that the thing which makes one-click possible — a web-writable codebase — is exactly the thing you don't want on production.
So what's it actually for?
This is where I landed after the initial "oh, it's crippled" reaction: it's not crippled, it's scoped honestly. The discovery half — browse, search, compare, find the module you didn't know existed — is valuable everywhere and works everywhere. The install half is a local-dev accelerant: spin up a feature branch in DDEV, click through a few modules, then commit the resulting composer.json and composer.lock and push them through your normal pipeline to production, where Composer runs in CI against a read-only runtime. The dream of "install modules from the UI on prod" collides with a security principle that's more important than the convenience, and the project correctly chose the principle.
(One thing I'd flag as not-fully-confirmed: it's widely reported that when the codebase isn't writable, Project Browser hands you a copy-paste composer require command instead. That's the sensible behaviour and matches how people describe it, but I couldn't pin it to a primary source, so treat it as "probably" rather than "definitely.")
Why I find the catch reassuring
It would have been easy to ship a version that shells out to Composer as the web user on production and calls it a feature. Plenty of PHP apps have done exactly that and become case studies in how sites get owned. Drupal instead built the convenient path and then fenced it into the one environment where a writable codebase is acceptable. The "limitation" is the project refusing to trade your production security for a nicer click-path. As someone who deploys this blog from a read-only container image on purpose, that's the trade-off I'd want it to make — and it's a small, quiet example of Drupal's security culture choosing correctly when it would've been easy not to.