Drupal Automatic Updates After the Legacy API Shutdown: What to Fix Now

By Greg Nowak. Last updated 2026-07-18.

Drupal’s first-generation Automatic Updates infrastructure is now history. The Drupal Association discontinued the APIs used by Automatic Updates 7.x-1.x and 8.x-1.x on 6 March 2026. The associated release-content hash files expired on 12 May 2026 and may now disappear without notice.

Those are the dates teams should use—not 12 June or the earlier proposed 4 May deadline that still appears in places on Drupal.org. More importantly, the shutdown removes any illusion that an old update setup remains a usable fallback. If a site, script, or internal runbook still depends on that generation, the problem may only become visible when an urgent security release leaves little room for investigation.

This is an operational issue, not module housekeeping

For a business owner, the useful question is not whether a particular module is installed. It is whether the team can take a Drupal security advisory from assessment to tested production deployment within an acceptable window.

For an agency, an unsupported update route creates rushed estimates and awkward client communication. For an internal operations team, it turns planned maintenance into incident response. The sensible goal is therefore not “enable automatic updates everywhere.” It is to give every site a supported, rehearsed update path that fits the way its code reaches production.

Match the approach to the hosting model

Browser-driven Automatic Updates requires Drupal to modify its own codebase. That can work on a suitable writable server, but it conflicts with platforms designed around Git deployments, CI pipelines, immutable containers, or controlled build artifacts. Do not weaken a sound deployment model simply to accommodate an update button.

Site or environment	Practical update route	Priority check
Drupal 7 or 8 using a 1.x branch	Plan core modernisation or a separately supported maintenance process	A module bump alone cannot make an end-of-life core version current
Writable Composer-managed server	Use a compatible Automatic Updates release after readiness testing	Confirm backups, permissions, Composer access, and rollback
Git or CI/CD deployment	Update in development or CI, test, commit dependency changes, and deploy normally	Production must remain reproducible from the repository
Immutable container or artifact	Rebuild and promote a new artifact	No runtime process should rewrite application code

The right update method follows the deployment model instead of fighting it.

Check the branch and platform together

As of 18 July 2026, the project page lists Automatic Updates 4.1.0 for Drupal 11.2 or later. The 4.x line relies on Drupal core’s Package Manager module. Automatic Updates 3.1.7 remains available for Drupal 10.1 and Drupal 11 sites that meet its constraints.

Do not copy an installation command from an older project without checking the current release page and your own composer.json. Composer should resolve the precise compatibility rules, but the team still needs to understand which architecture it is adopting. A Drupal 7 or Drupal 8 site on the retired 1.x generation needs a broader support or migration decision, not merely a new module constraint.

Start with read-only checks from the project root in development or staging:

php --version
composer --version
composer validate
composer show drupal/core-recommended
composer show drupal/automatic_updates

composer validate checks the project definition and whether the lock file is consistent with it. Also inspect pending repository changes, available disk space, backups, readiness-check results, and any custom Composer plugins. If Composer is supplied by the host, container, or CI image, upgrade it through that toolchain rather than running composer self-update casually on production.

Understand what Package Manager changes

Package Manager stages Composer operations in a temporary copy before synchronising changes back to the application. Drupal’s current documentation lists several important prerequisites: the codebase—including vendor—must be writable, Composer 2.7 or later must be available, PHP must be allowed to run Composer, proc_open() must be enabled, and composer validate must succeed.

If Drupal cannot locate Composer, the executable can be configured in settings.php:

$config['package_manager.settings']['executables']['composer'] = '/full/path/to/composer.phar';

Package Manager also relies on PHP-TUF protection for Drupal’s Composer repository. Extra Composer plugins, private repositories, patch tooling, and unusual installer behaviour need careful staging tests. Drupal currently describes Package Manager as experimental, so its use should be an explicit engineering decision rather than an unnoticed side effect of upgrading the module.

Keep a command-line route where it helps

Automatic Updates 3.x includes a console script for environments where the web-server user cannot change the codebase:

php /path/to/module/automatic_updates/auto-update

That can be invoked by a scheduled job running as an appropriately privileged user. Test the exact command, permissions, logging, failure notification, and recovery procedure before scheduling it. A privileged job without monitoring is not a maintenance strategy.

Be precise about what is automated

Automatic Updates is strongest when used for a defined maintenance task. Do not assume it replaces major-version upgrades, contributed-extension review, release approval, or business testing. Even when a release supports more update types, someone still needs to review advisories, assess compatibility, confirm backups, interpret readiness failures, and smoke-test the result.

A useful smoke test should cover more than the homepage. Include administrator login, forms, scheduled tasks, payment or CRM integrations, search, and any journey that would materially affect the organisation if it failed.

A cleanup plan your team can finish

Inventory every site: record core, PHP, Composer, Automatic Updates branch, host, repository, and deployment owner.
Remove legacy assumptions: flag 1.x branches, retired API references, obsolete dates, and copied commands.
Select a supported route: align the module branch and Composer baseline with both Drupal core and the hosting model.
Rehearse the full process: test update, deployment, smoke checks, failure notification, and rollback outside production.
Write the runbook: name the decision-maker, commands, evidence required, escalation path, and manual fallback.

The valuable outcome is not a dashboard saying that updates are enabled. It is confidence that the next urgent Drupal patch can move from advisory to verified production release without improvisation.

If your estate combines older Drupal versions, managed hosting, and custom Composer logic, Greg can review the update path and turn the findings into a practical runbook your team can use.