Drupal automatic updates: should your team let Drupal apply core updates?
If your Drupal site must stay on supported releases under change control, the question is not whether to apply updates but who approves each change and how fast you can reverse it. Drupal's Automatic Updates project (the automatic_updates module) can apply Drupal core updates on the site itself and provides a form for updating contributed projects. It is a tool for shortening the gap between a security release and a patched site, and it runs inside the same codebase you already operate. About 14,846 sites report using it, according to its Drupal.org project page, but adoption numbers do not tell you whether it fits your change process. The 4.1.0 release requires Drupal ^11.2, so a site still on an earlier Drupal 11 minor or on Drupal 10 cannot take that release as it stands.
Before you decide, check three things with your own environment. First, confirm which Drupal version and minor release you run and whether your hosting lets the web process write to the codebase, since the module's requirements and file permissions determine whether it can run at all. Second, check whether your site is built with Composer and whether the lock file is the source of truth for every environment. Automatic Updates works with the Package Manager in ways that a Composer-managed build must account for, and a site that deploys from version control can drift if updates are applied only to production. Third, confirm with your security and compliance owners whether an unreviewed change to production code is acceptable under your change policy, and whether that policy names an approver for each release.
Automatic Updates suits teams that can accept a short, pre-tested path from release to production and that have a tested rollback, such as a database backup taken before the update and a documented restore. Where every change needs a peer-reviewed commit, a staging run with your test suite, and a recorded approval, CI-based updates that open a merge request with the composer changes are usually easier to audit. The decision also depends on how often you can accept a security release landing within the day. Write down who approves, what evidence is kept, and how a failed update is reversed, then choose the method that produces that record. Speed matters, but approval and rollback decide whether the choice holds up in an audit.
What changes in the update cycle and what to do about it
This table compares the release and version facts that affect Automatic Updates planning, with the impact of each and the action your team should take. Read each row as a dated decision point, and confirm current version constraints on the project page before you commit to a plan.
| Change | Impact | Action needed |
|---|---|---|
| Automatic Updates 4.1.0 requires Drupal ^11.2 | Sites on earlier Drupal 11 minors or Drupal 10 cannot take this release line, so the version constraint decides whether the feature is available at all. | Confirm the current version constraint on the Automatic Updates project page, then check your core minor before scoping the feature. |
| Monthly bugfix releases on the first Wednesday | Non-security core changes arrive on a predictable day each month, which lets change windows be scheduled ahead of time. | Book a recurring review slot after each release and decide whether bugfix updates go through the change board or a standing approval. |
| Security releases on the third Wednesday | Security fixes can land on a day that does not match your normal change calendar, so the window for applying them may be short. | Agree in advance who can approve an out-of-cycle security update and how it is tested before it reaches production. |
| Drupal 10 end of life on December 9, 2026 | Drupal 10 sites lose core security coverage on this date, and Automatic Updates requiring Drupal 11.2 or later does not help them until they move. | Plan the Drupal 11 upgrade with a dated cut-off and treat the automatic update path as available only after that stage. |
| Drupal 12 requires PHP 8.5 or later | Automatic core updates cannot move a site to Drupal 12 without the server runtime being upgraded first, so PHP changes must be sequenced with code updates. | Check the PHP requirements page, inventory PHP versions across all environments, and include runtime upgrades in the change plan. |
| Drupal 12 scheduled for the week of December 7, 2026 | Major version moves are not handled by a routine core update, so the change needs a separate project with its own testing. | Keep major upgrades out of the automatic update lane and schedule them as planned work with contributed module checks. |
Which update path fits your environment
Automatic Updates applies Drupal core updates and a form for contributed projects directly to the running site, so the change reaches users as soon as it is applied. Approval usually sits with the site owner who enables the feature and accepts the update, with no separate release review. Testing happens on production unless the team adds its own staging step outside the module. Rollback depends on a backup and database snapshot taken before the update, so confirm exactly what the module restores in your version.
- Approval: the production site owner enables updates and decides what runs, often without a second reviewer.
- Testing: checks happen after the change on live content unless a staging step is added by your team.
- Rollback: restore from a pre-update backup; confirm whether the module offers its own reversal path.
- Requirements: the Automatic Updates project page lists the Drupal version constraints for each release, and the 4.1.0 release requires Drupal ^11.2.
- Suits: low-exposure public sites and small teams that can respond quickly to a failed update.
Check whether your change policy permits production changes without a prior staging run.
In this model, an update is a change to composer.json and composer.lock that a pipeline builds, tests and releases as a versioned artifact. Approval happens at the merge request and release gate, where a reviewer signs off and the change record is linked to the build. Testing happens in CI and on a staging environment that mirrors production before any deployment. Rollback means redeploying the last known-good artifact, and because updates can change the database schema, the database rollback needs its own plan.
- Approval: a named reviewer approves the merge and the release, which fits formal change advisory workflows.
- Testing: the pipeline runs code checks, automated tests and a staging deployment before production.
- Rollback: redeploy the previous artifact, and document how schema changes are reversed or restored.
- Reproducibility: commit
composer.lockso every environment builds from the same versions. - Suits: regulated estates with formal change control, multi-site programs and teams that already run a deployment pipeline.
Check that your pipeline can ship a security release within the window your advisory process requires, since Drupal security releases follow a fixed monthly schedule.
The hybrid model lets Automatic Updates apply low-risk patch releases on the live site, while minor and major changes continue through the Composer pipeline. Approval is pre-agreed in policy for the patch class, and anything outside that class returns to human review. Testing is split: patch releases depend on the policy and on monitoring, while feature and dependency changes receive the full CI run. Rollback follows the same split, with a backup restore for automatic patches and an artifact redeploy for everything else.
- Approval: the change board pre-approves a defined patch class, and any exception goes back to the pipeline.
- Testing: confirm which releases the module will apply in your version and review contributed module side effects for those releases.
- Monitoring: add error tracking and uptime alerts so a bad automatic patch surfaces quickly.
- Drift control: automatic changes can move the live code away from
composer.lockin git, so reconcile them on the next pipeline run. - Suits: organizations with a mature patch policy, strong monitoring and staff who can reconcile code drift.
Confirm with the module documentation that automatic updates can be limited to patch releases in your version before you write the policy around them.
Requirements to confirm before you enable Automatic Updates
Automatic Updates only works when the Drupal version, PHP runtime, database, web server and file permissions line up with the release you plan to run. Confirm each item below against the project page and your own environment before you schedule a first automated update.
Drupal version and project constraint
The Automatic Updates project declares which Drupal core line its current release supports. The 4.1.0 release requires Drupal ^11.2, so a site on an older core line needs a different plan. Read the project's Composer constraints for the exact version range, then confirm your site can reach that core line through your normal upgrade path before you enable the module.
PHP version for the target core
Each Drupal core release sets its own minimum PHP version, and the Package Manager needs a runtime that meets the target release, not only the current one. Check the PHP requirements page for the core version you plan to apply, and confirm that the CLI PHP used by cron and Composer matches the web PHP. A mismatch here is a common reason an automated update fails on the first run.
Supported database engine
Drupal runs on MariaDB, MySQL, PostgreSQL or SQLite. Confirm that the database version in your environment is one the current core release supports, and that the database user can run the schema changes that core updates require. Test an update against a copy of production data, because database compatibility problems tend to appear during post-update database steps rather than during file changes.
Web server configuration
Drupal runs on Apache, Nginx and other web servers. Confirm the server configuration your site uses, including rewrite rules, PHP handler and any reverse proxy in front of it, because updates can change files that the web server must serve or block. Verify that direct access to the vendor and composer files is denied, and that your server configuration does not depend on file paths that a core update may move.
File system permissions for the update process
Automatic Updates needs write access to the codebase so it can stage and replace packages, and it needs a writable temporary location. Review which user the web server and cron run as, confirm that deployment ownership does not block writes, and check that the production file system can accept the staged copy during an update. Document the exact paths and owners, because a permissions gap found during a change window is harder to fix than one found in staging.
Contributed modules without a compatible release
Automatic Updates applies core and can offer contributed updates, but a contributed module without a release for the target core blocks a clean update. Decide in advance who reviews the Upgrade Status or dependency report, which modules are critical to business function, and whether a blocked module is replaced, pinned or held back. Agree that a blocked module pauses the automated run for that site rather than leaving it half updated.
How Automatic Updates fits regulated change control
In a regulated environment, the question is not whether Automatic Updates works but whether it can produce the evidence your change process requires. A typical change control process expects a documented approval, a change that was tested before it reached production, a record of what was deployed, and a rollback plan. Automatic Updates applies Drupal core releases on the site itself, so the change can reach production without passing through the approval step your team has defined. If the update button is reachable on production, the approval gate exists only on paper.
The practical split is to keep the update form for staging or a non-production environment and to restrict who can trigger updates anywhere else. Confirm in your environment which Drupal permissions control the update form and the Package Manager, and remove them from every role that is not part of your change group. Then decide whether production updates will be applied by a pipeline from a version-controlled composer.lock after review, or by a named operator during an approved window. Ask your team to test which roles can reach the update form on each environment, because a permission granted for a content workflow can silently grant update access too.
Keep evidence that a reviewer can check later: the approval ticket, the Composer diff or lock file change, the staging test results, the database and file backup taken before the change, the deployment log and the post-change verification. Record which release the site ran before and after, and keep the security advisory the update addressed, since Drupal publishes security releases on the third Wednesday of the month according to the Drupal core release schedule. Agree with your auditor and your change board how this evidence will be presented. The module does not produce an audit-ready record on its own, and it does not satisfy any control framework by being installed.
How to roll out CI-based updates with checkpoints
This sequence moves a Composer-managed Drupal update from a branch to production in stages, with a verified rollback point after each deployment. Each gate produces evidence that the change is safe to promote, so approvers decide on proof rather than on the update's version number alone.
Update the lock file in a branch
A developer runs the Composer update for drupal/core and the contributed projects that need new releases inside a feature branch, so the change is isolated from the main line. The commit includes the updated composer.lock and a short note listing each package and its old and new version. Done means the branch builds from a clean checkout with the lock file alone, without manual edits to the codebase.
Run tests and the upgrade status check
The CI pipeline runs the project's automated tests, code quality checks and Upgrade Status against the new versions, so deprecated API use and incompatible contributed modules surface before any environment is touched. The team reviews the report and fixes or records each finding in the branch. Done means the pipeline is green and every remaining finding has a named owner and a decision.
Deploy to a staging copy with a fresh snapshot
The pipeline takes a new database snapshot and file backup of production, restores them into a staging copy, and then applies the branch's code and database updates with the standard database update step. The snapshot is labeled with the commit hash so it can be restored later. Done means staging runs the new code against production-shaped data and the snapshot is recorded as the first rollback point.
Run functional and security smoke tests
Testers run scripted checks on the critical paths, including login through the identity provider, content editing, forms, search, payments or other business transactions, and the public pages most used by visitors. A security scan covers the known exposed endpoints and the security headers configured for the site. Done means each check has a recorded pass result, and any failure is logged with a go or no-go decision.
Obtain change approval
The change owner reviews the evidence package: the lock file diff, the test and Upgrade Status reports, the staging smoke test results and the snapshot reference. The approver records acceptance under the organization's change control process, which may require a separate board or risk owner for regulated systems. Done means the approval is attached to the change record before any production step starts.
Deploy to production with a rollback point
Immediately before deployment, the pipeline takes a fresh production backup of the database and files, then deploys the approved commit and runs the database updates. The team tags the release and keeps the previous build artifact available so the prior code can be redeployed. Done means the production smoke tests pass and the backup, tag and previous artifact are recorded together as the rollback point.
What makes update work longer or shorter
This table compares the factors that lengthen or shorten a Drupal core update cycle, with what each one changes and what to check before committing to a method. Read each row against your own estate, because the same update can take a small fraction of the effort on one site and most of a sprint on another. The main takeaway is that contributed code, custom code and change control usually matter more than the core update itself.
| Driver | Effect on effort | What to check |
|---|---|---|
| Contributed modules and themes | Each one needs a release compatible with the target core version, and incompatible ones block the update or force replacement | Count installed projects, confirm each has a release for the target version, and list any that are unmaintained |
| Custom code touching changed APIs | Deprecated or removed calls in custom modules and themes need fixes before or after the core update | Run Upgrade Status against custom code and note findings that Drupal Rector cannot fix automatically |
| Composer-managed or not | Composer-managed sites take updates through the lock file, while sites without it need manual file handling and drift risk | Confirm how core is installed, whether the lock file is committed, and whether Automatic Updates can apply changes to that layout |
| Database size and backup time | Larger databases lengthen the safe backup and restore window that must exist before any update runs | Measure current backup and restore times in a copy of production, not from memory |
| Number of environments | Each environment must receive the same tested change, so more environments add promotion and verification steps | Map development, staging and production, and confirm whether staging matches production in code and configuration |
| Change control approval steps | Each required sign-off, change window or evidence request adds elapsed time even when the technical work is small | Ask the change board which artifacts it needs, such as test results, rollback plan and release notes |
| Frequency of monthly bugfix releases | Applying every monthly bugfix release keeps each update small, while skipping several releases creates larger, riskier batches | Agree a cadence with the team, and check the release schedule for the first Wednesday bugfix and third Wednesday security dates |
When CI-based updates are safer than in-place updates
CI-based updates are the safer choice when a failed update would be expensive to detect or expensive to reverse. Automatic Updates applies core and contributed changes to the live site, so the release is tested only if your own pipeline tests it first. That gap matters most on sites with custom modules and themes, sites with many contributed projects, and sites with integrations that fail without showing an error, such as a CRM sync, an SSO login flow or a payment callback. In those cases, a Composer change should be built in a pipeline, deployed to a staging environment with a copy of production configuration, run through automated tests and smoke checks against the integrations, and only then promoted. The pipeline also gives you a build artifact you can redeploy, which is the simplest rollback when a database update has already run.
Regulated environments usually need evidence for each release, not just a successful update. A pipeline produces a versioned lock file, test results, a deployment record and an approval step that map onto change tickets and the evidence your auditors ask for. Confirm with your change advisory board whether each core security release needs a separate approval, how emergency patches are handled, and who signs off. Multi-site estates add a second reason: one tested build can be promoted across sites in a controlled order, while in-place updates run site by site with separate outcomes. Confirm how your sites share code, whether they use separate databases, and whether each one has its own integrations.
In-place updates are reasonable for a small brochure site with little or no custom code, few contributed projects, no transactional integrations and a rollback you have actually rehearsed, such as a recent full backup of code and database with a tested restore. Before choosing, check the Automatic Updates requirements for your Drupal version in its project documentation, confirm your hosting allows the file writes the module needs, and run a restore test rather than assuming the backup works. Also confirm who receives failure notices and who acts on them outside business hours. If any of those answers is unclear, the pipeline route is the safer default.
What buyers ask before choosing an update method
Do we need a partner to set up Drupal Automatic Updates?
No, your own team can install and configure Automatic Updates, but a partner is worth considering when the site has regulated change control, many contributed modules or no one who can own the Composer build. The module is a Drupal contributed project that applies core updates and offers a form for contributed projects, so the setup work is mostly environment and process design rather than custom code. Ask a partner to show how they would fit the updates into your approval steps, test environments and rollback plan before you decide who does the work.
How much effort does the initial setup take, and what drives it?
Effort depends on how the site is built and how much change control must be recorded. The main drivers are whether the site is Composer-managed, whether the file system is writable at runtime, how many contributed projects are installed, and whether updates must pass through staging and approval before reaching production. Automatic Updates 4.1.0 requires Drupal ^11.2, so a site on an older core line must first be upgraded before the module can be used at all. Ask for a written list of prerequisites and an environment check before agreeing to a timeline.
What does the work need from our client team?
Your team needs to decide who approves an update, where it is tested, and how a failed update is rolled back. Engineers must confirm the hosting setup, file permissions, database backups and access to the Composer repository, while the security or compliance owner should agree on evidence to keep for each change. Business owners need to commit to reviewing the content and user journeys that an update could affect. Without these owners named in advance, automatic changes tend to stall at the approval step.
Can a small team run monthly Drupal updates on its own?
A small team can run monthly core updates on its own if it has a repeatable test routine, a staging copy of production and someone who can read Composer output. Bugfix releases arrive on the first Wednesday of each month, so the routine should be scheduled around that date. Security releases arrive on the third Wednesday and may need faster action. Teams that lack a second person to review changes or a tested restore procedure should consider a retainer for updates and testing.
What happens when a contributed module has no compatible release?
Core updates can proceed only when every installed contributed module supports the target version, so an incompatible module blocks the update or forces a decision. Options include waiting for a maintainer release, replacing the module with an alternative, patching it in a controlled fork, or removing the feature. Each option changes cost and risk, so record the decision and its owner before the update window. Check compatibility with Upgrade Status or the project page before scheduling the update.
How do security releases change the update schedule?
Security releases are published on the third Wednesday of the month, outside the regular bugfix cycle, and they may affect core or contributed projects. Automatic Updates can apply them when the pipeline allows, but regulated teams usually need a fast-track path that skips the routine monthly window and still records approval. The Drupal Security Team publishes advisories with CVE identifiers and risk scores, which your team can use to decide urgency. Agree the fast-track criteria and emergency approver before an advisory arrives.
When is a CI-based update safer than Automatic Updates?
A CI-based update is usually safer when change control requires every code change to be versioned, reviewed and tested in a pipeline before deployment. In that model, Composer changes are committed, the build runs automated checks and the release is promoted through environments, which gives auditors a clear record. Automatic Updates suits sites that need in-place core patches with less manual work, but it does not replace a review gate. Choose based on your evidence requirements and the team's ability to maintain the pipeline.
How DeployOpen scopes, delivers and supports Drupal updates
DeployOpen plans, implements, tests, documents and supports self-hosted Drupal inside your own infrastructure, including the choice between Automatic Updates and a CI-based update pipeline. We agree the scope in writing before work starts, so the update method, test gates and approval steps match your change control.
How we scope
- Review your current Drupal version, Composer setup, hosting and which contributed modules and custom code the update touches.
- Confirm whether Automatic Updates meets your change control or whether updates should run through a tested CI pipeline.
- Agree deliverables, test environments and approval roles in a fixed-scope written agreement before any work starts.
How we build
- Configure the update method, file system permissions and Package Manager requirements in a staging environment that mirrors production.
- Build and run a repeatable update pipeline with automated tests, backup checkpoints and rollback steps you can review.
- Test core and contributed updates against your content, integrations and single sign-on before any production change.
How we hand over
- Document the update workflow, approval gates, rollback procedure and the evidence each release leaves for your auditors.
- Walk your platform and security teams through the pipeline and run a supervised update together with them.
- Hand over configuration, runbooks and access so your team can operate updates without DeployOpen involvement.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer that tracks the Drupal release schedule.
- Review each security release against your installed modules and plan the update window with your change board.
- Keep documentation and the pipeline current as your modules, hosting and Drupal version change over time.
