Drupal teams have been able to treat older Automatic Updates setups as harmless technical debt for a long time. As of June 12, 2026, that is no longer a safe assumption. The first-generation Drupal.org Automatic Updates API is already retired, and the legacy release hash files tied to that generation expired on May 12, 2026. If part of your update process still depends on that old path, the next security release can turn a forgotten backlog item into an operational problem.
For business owners, operations leads, and agency teams, the key point is simple: this is not about chasing a fashionable feature. It is about making sure your Drupal maintenance process still works under pressure, on the hosting model and deployment workflow you actually have.
What changed, exactly?
Drupal Association engineering announced on February 10, 2026 that the old Automatic Updates API cutoff was being moved up immediately. The APIs used by Automatic Updates 7.x-1.x and 8.x-1.x were discontinued on March 6, 2026, and the related release-content hash files expired on May 12, 2026. Those dates matter because they remove the idea that old Automatic Updates plumbing is still “good enough for now.” It is not.
This is also a good example of why teams should verify update guidance against current primary sources, not old internal notes. Drupal’s project and documentation pages are in transition: some older docs still show an earlier Composer baseline and an older install example, while the current project page reflects newer branch requirements. If your runbook was copied forward from an older project, it may already be pointing your team at the wrong setup.
Why this becomes a business issue fast
Automatic Updates is meant to reduce the time, cost, and uncertainty around patching Drupal. But that only works when the underlying setup is supported. If your site is on the wrong module branch, depends on outdated API behavior, or assumes writable production code where your host forbids it, then security-response time goes up exactly when it should go down.
That is the real risk here. Not “the module is old,” but “the team will discover process failure during a security advisory window.” For agencies, that means rushed client communication and avoidable fire drills. For in-house operations teams, it means a routine maintenance task turns into an incident-response exercise.
Check your branch, Composer baseline, and hosting model together
As of June 12, 2026, the Automatic Updates project page lists Composer 2.6 or later as the baseline. It also shows a split many teams need to account for: the stable 3.1.7 release works with Drupal ^10.1 || ^11, while the 4.x line is for Drupal ^11.2 and depends on Drupal core’s Package Manager module. That means the right answer is not “install the latest thing everywhere.” The right answer is to map each site to the branch and workflow it can actually support.
Start with four questions:
- Is the site fully Composer-managed, and is Composer at a supported version?
- Which Drupal core version is the site on today, and which Automatic Updates branch matches it?
- Can the environment safely write to Drupal core, contributed code, themes, and
vendor? - Will updates happen in the browser, from a privileged console process, or in local or staging before deployment?
If you cannot answer those quickly, you do not have an update process yet. You have a hope that the next advisory will be easy.
Do not force browser-based updates onto the wrong platform
Drupal’s current guidance is explicit: browser-driven Automatic Updates requires Drupal to be able to change its own codebase. That is often a poor fit for managed or immutable hosting models. If you run on a platform that expects deployments through Git, CI, or build artifacts, forcing in-browser code changes into production usually creates more risk, not less.
For those environments, a better pattern is to use Automatic Updates in local development or staging, validate the result, and then ship it through the normal deployment flow. The 3.x line also includes a console script that can run updates when the web server user is not allowed to modify the codebase directly:
php /path/to/module/automatic_updates/auto-updateThat should be run from a scheduled job under a more privileged server user, not improvised during a crisis.
If you are moving toward 4.x, treat Package Manager as a real engineering change
The 4.x direction is not just a module bump. Drupal’s Package Manager documentation describes stricter prerequisites: a writable codebase including vendor, Composer 2.7 or greater, permission for PHP to run Composer, a clean composer validate, secure Composer downloads, and an available proc_open(). If Drupal cannot find the Composer executable automatically, you may need to define its path in settings.php.
There is also more underneath the surface. Package Manager requires PHP-TUF integration and TUF protection for the Drupal package repository, and the docs warn that unsupported Composer plugins can break a site. If your estate depends on extra Composer plugins, patch tooling, or hand-tuned build behavior, you should test compatibility before promising a Package Manager-based workflow to stakeholders. Drupal also documents Package Manager as experimental, which is another reason to handle rollout deliberately.
A few fast checks are worth running before you plan anything bigger:
composer --version
composer validate
composer self-update
composer config --unset disable-tls
composer config --unset secure-httpThe last two are mainly relevant if someone has previously overridden Composer’s secure defaults.
Be clear about what Automatic Updates will and will not solve
The initiative scope is narrower than many people assume. Drupal’s minimum implementation is aimed at core patch and security releases, with readiness checks, code verification, and Composer integration. It is not a promise of zero-touch operations for every update type. Core minor and major upgrades are out of scope for the minimum implementation, and contributed project updates are out of scope too.
That is useful, not disappointing. It tells you how to design the process. Use Automatic Updates to make urgent core patching safer and more repeatable. Keep broader upgrade planning, contributed module review, and release management in the hands of your normal engineering workflow.
What a sensible cleanup looks like now
A good outcome here is not “turn everything on.” It is a short, evidence-based cleanup that gets each site onto a supportable path: the right module branch, the right Composer baseline, clear readiness checks, and an update workflow that matches the host instead of fighting it.
If you want that clarified quickly, talk with Greg about reviewing the current setup and turning it into a practical update runbook before the next security window.
Need help with this kind of work?
Need a quick Drupal update-path review before the next security advisory? Contact Greg. Get in touch with Greg.