Retired infrastructure changes the conversation
A lot of Drupal teams treated older Automatic Updates setups as harmless legacy: not ideal, but still working. That is harder to justify after the 2026 shutdown of the old Drupal.org Automatic Updates API. On February 10, 2026, Drupal.org announced that the discontinuation was being moved up immediately from the original May 4 date. The same announcement said the API used by Automatic Updates 7.x-1.x and 8.x-1.x was being retired, that in-place update packages would no longer be generated, and that the release-content hash files would expire on May 12, 2026.
That shifts this from deferred housekeeping into a support problem. When the next security release lands, you do not want to find out that the fragile part of your update process is the update channel itself.
Automatic Updates was never only about convenience. Drupal's documentation describes it as a way to simplify updates, increase confidence that an update will apply cleanly, and reduce the time and cost of updates. The broader initiative goes further: safe, secure automatic updates for Drupal sites, better security in the wild, and lower total cost of ownership. If a site is still tied to the first-generation API, it is now outside that supported direction.
The requirement set has moved
Cleanup work gets underestimated because teams often think Automatic Updates still means one familiar module with one familiar setup. It does not. The Drupal wiki page for the contributed module documents an older baseline where Automatic Updates requires Composer 2.3.5 or later. The current project page raises that to Composer 2.6 or later for the module it recommends installing with Composer.
The branch picture has moved as well. The release list on the same project page shows a newer 4.x line for Drupal 11.2, and the 4.0.0 release explicitly says it relies on Drupal core's Package Manager module. At the same time, the stable 3.1.7 release is listed for Drupal 10.1 and 11. So a site that once had Automatic Updates working may now be on the wrong branch, the wrong Composer baseline, or the wrong operating model.
That is why this is usually an assessment and cleanup exercise, not a quick module bump. You need to confirm the site's Drupal core version, whether it is properly Composer-managed, which Automatic Updates branch it can support, and whether the deployment workflow matches the assumptions behind that branch. If those pieces are out of sync, the gap tends to show up under security-release pressure.
Where problems usually show up first
Drupal's readiness-check documentation is useful because it focuses on the practical issues that derail updates in real environments. The automated checks exist because not every site can update safely at every moment. The documentation calls out blockers such as pending database updates, read-only file systems, and insufficient disk space for in-place updates. It also says plainly that if a public service announcement is released while your site is failing readiness checks, you need to fix the underlying readiness problems quickly so the site can actually be updated.
In practice, this is where teams get caught. The update path worked months ago, so everyone assumes it is still fine. Meanwhile the environment has drifted just enough to make the next update harder than expected.
Hosting model matters more than preference
Hosting and deployment design are usually the next fault line. Both the Drupal docs and the current project page say the browser-driven workflow requires Drupal to be able to change its own code base. The project page is explicit that this is likely incompatible with many Acquia-, Pantheon-, or similar-style setups.
For those environments, the answer is not to force browser-based updates into production anyway. The documented guidance is to use Automatic Updates in local development and then push the resulting changes through the normal hosting workflow. The 3.x branch also includes a Symfony console script that can run updates even when the web server cannot update the codebase directly, provided you schedule it under a more privileged server user.
The business implication is straightforward. If your platform is built around immutable deploys, your supported update process needs to respect that. Assuming writable production code when it does not exist just stores up friction for the next advisory window.
Package Manager raises the bar again
If a site is moving toward the current 4.x direction, the requirements get stricter because 4.0.0 relies on Drupal core's Package Manager module. Drupal's Package Manager documentation lays out concrete prerequisites. The codebase has to be writable, including Drupal core, contributed code, themes, and the vendor directory. A Composer executable at version 2.7 or greater is required. PHP must be allowed to run Composer, and composer.json has to validate cleanly. Composer also needs to be configured for secure downloads, with TLS and secure HTTP left enabled.
There are lower-level prerequisites that older estates often miss. PHP's proc_open() function must be available. If Drupal cannot find the Composer executable automatically, its path may need to be configured in settings.php. Package Manager also requires PHP-TUF and its Composer integration plugin, and the documentation says the Drupal package repository must be protected with TUF. Unsupported Composer plugins can be risky enough to break a site, and even familiar tooling such as cweagans/composer-patches comes with caveats.
That is why this is not only about updating the updater. It is also about checking whether the Composer stack underneath it is supportable, secure, and compatible with the path Drupal is taking.
What a supported process should look like now
For most organizations, the practical response is an audit followed by a narrower, supported update design. In practice, that usually means:
- Mapping the site to the correct Automatic Updates branch and compatible Drupal core version.
- Confirming the site is Composer-managed and that the Composer version matches the supported path you want to use.
- Testing readiness assumptions early: writable code, writable
vendor, enough disk space, and no pending database updates. - Deciding whether the update should run in-browser, from a privileged console job, or inside local, staging, or CI workflows before code is deployed.
- Validating Composer security and Package Manager prerequisites, including TUF-related setup where that path applies.
That last point matters because Drupal's broader initiative is clear about scope. The minimum core implementation is aimed at Drupal core patch and security releases, not every kind of change. The initiative page says minor and major core upgrades are not in scope for the minimum implementation, and contributed project updates are not either. It also says automatic updates are generally intended for small-to-medium site owners, while organizations with more advanced deployment workflows may prefer staging-based or API-driven integration into custom pipelines.
So the goal is not zero-touch everything. The goal is a repeatable, supported way to handle security and patch releases without surprises.
Why this is worth fixing before the next advisory
After February 10, 2026, and especially after the May 12, 2026 expiry of the old release hash files, unsupported Automatic Updates flows are no longer harmless legacy. They can leave a team relying on endpoints, generated artifacts, or validation inputs that Drupal has already stopped maintaining. Even if the site is otherwise healthy, that is not a dependency you want to discover during a security response.
This is the kind of Drupal maintenance issue that benefits from a systems-level review. Greg can assess whether a site is genuinely ready for a supported Automatic Updates or Package Manager-based process, where Composer readiness or hosting assumptions are likely to fail, and how the deployment workflow should change so security releases are less disruptive. The point is not to force one fashionable update method onto every site. It is to move each site onto a supportable path that fits its hosting model, Composer posture, and operational reality.
Need help with this kind of work?
Discuss a supported Drupal update path Get in touch with Greg.