iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use Composer to build and test a complete release away from production, commit the tested composer.lock, back up the live database and files, deploy with composer install --no-dev, and run Drupal’s required database and cache operations. Drupal’s normal database-update procedure enters maintenance mode. If visitors must continue using the site, you need blue-green or rolling traffic management plus database changes that remain compatible with both the old and new application versions. Drupal itself does not provide a universal “zero-downtime” switch.
What “safe, no-downtime” Drupal patching actually means
A Drupal patch is safe when the exact code, dependency graph, database changes, configuration, and rollback material have been tested together before users reach the release. A no-downtime release adds an infrastructure requirement: traffic must continue serving from a healthy application version while the new version is prepared, then move only after health checks pass.
The supported Drupal workflow is Composer-first. Resolve updates on a local development or staging copy, test the resulting release, commit both composer.json and composer.lock, and deploy that lock file to production. Do not ask a live server to select newer dependency versions during the release; doing so can produce a dependency set that was never tested.
Drupal’s documented update operation includes maintenance mode while code and database updates run. Therefore, a conventional single-server deployment has a short maintenance window even when the Composer installation itself is quick. Literal zero user-visible downtime is an operational design built around that boundary, not a promise made by the Drupal command.
#1 Best Overall
- Read Before You Buy — No Video Output: These adapters support charging and USB 2.0 data transfer, but cannot transmit video signals. Except for standard USB webcams (which use USB data only), they are not compatible with HDMI/DisplayPort cables, video-capable USB-C hubs, or docking stations with video output.
- Convert USB-A Ports to USB-C: Designed to connect USB-C earphones, cables, flash drives, card readers, and other USB-C accessories to standard USB-A ports. Plug-and-play with no drivers or software required.
- Aluminum Alloy Housing: Built with a sturdy aluminum alloy shell that aids in heat dissipation and protects against daily wear and scratches. Designed to maintain a stable and secure connection.
- Compact & Travel-Friendly: The ultra-compact design allows the adapter to stay plugged into your device without blocking adjacent ports or adding bulk, reducing wear and tear on your original USB ports.
- 12-Month Warranty: Backed by a 12-month manufacturer warranty for peace of mind. Designed to meet strict quality control standards for reliable everyday performance.
Before you update: establish a releasable baseline
Check the current site and dependency state
- Put the current production code, database, configuration export, and deployment metadata under a known release identifier.
- Run
composer outdated "drupal/*"on the development or staging copy to see available Drupal packages. - Read the Drupal core release notes and the contributed module’s release notes. Check supported PHP and Drupal versions, required extensions, known upgrade notes, and issue queues relevant to your installed versions.
- Open Drupal’s status report and resolve existing errors before changing dependencies. An update can expose a pre-existing problem that is otherwise difficult to distinguish from a regression.
- Record enabled modules, themes, scheduled jobs, queue workers, external integrations, search services, and any custom code that calls the module or core APIs.
A core minor update can require changes in a contributed module or theme. A contributed module release can also include update hooks, permission changes, new services, or configuration changes that affect custom code. Treat the release notes as part of the change, not as optional reading.
Define the rollback point
A rollback must be a deployable action, not a hope that an earlier package version can be rediscovered. Retain the previous application release, its composer.lock, the matching configuration export, and a restorable database backup. If the release changes uploaded files or private files, include those in the backup or verify that the file storage has independent versioning.
Back up production before touching dependencies
Create both a database dump and a restorable code/files backup immediately before the release. Drupal documents Drush commands such as drush sql:dump for the database and drush archive:dump for an archive containing site material. Validate that the dump can be read and that the backup is available from the environment where an incident responder would need it.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Database: capture the complete production database, including the tables used by contributed modules and queues.
- Code: retain the previous release directory or artifact and its lock file.
- Files: protect public and private files, generated assets, and any server-side secrets required to boot the previous release.
- Configuration: preserve the active configuration export and the exact settings used by the previous release.
- Recovery access: confirm that an operator can switch traffic back and restore the database without relying on the application version that is being replaced.
Do not make a production backup for appearance only. Check its timestamp, size, exit status, and restoration procedure in a non-production environment when the system’s risk warrants it.
Build and test the update on development or staging
Updating Drupal core
For a Composer-managed project using the drupal/core-recommended package, update core on the non-production copy with:
composer update "drupal/core-*" --with-all-dependencies
Use a dry run first when you want to inspect the proposed dependency changes without writing them:
Recommended Free Tools
Rank #2
- 5-in-1 USB-C Hub: Experience comprehensive connectivity featuring a Power Delivery input, two USB-A 2.0 ports, a USB-A 3.0 port, and an HDMI port. (Note: The USB-C power delivery input port is only for connecting an external wall charger to power your laptop and cannot power peripheral devices.)
- 90W Pass-Through Charging: Achieve optimal charging with 90W pass-through power to your laptop, supported by a total input of 100W, with the hub reserving 10W for operational efficiency. (Note: Wall charger not included.)
- Quick Data Transfers: Accelerate your productivity with rapid data transfers using a high-speed 5Gbps USB 3.0 port and two 480Mbps USB 2.0 ports.
- 4K HDMI Display: Enhance your visual experience with a hub capable of delivering 4K resolution at 30Hz in both mirror and extend modes. Please note that this hub is compatible with MacBook (macOS 12 and newer), Windows 10 and 11, ChromeOS, and laptops equipped with DP Alt Mode and Power Delivery. Note: This device is not compatible with Linux.
- What You Get: Anker USB-C Hub (5-in-1, 4K HDMI), welcome guide, 18-month warranty, and our friendly customer service.
composer update "drupal/core-*" --with-all-dependencies --dry-run
The command updates the dependency graph and writes the resulting versions to composer.lock. Review the lock-file diff rather than assuming that only one package changed. Core updates can move Symfony, Twig, or other transitive packages within the constraints declared by the project.
Updating a contributed module
Replace drupal/modulename with the package name of the module you intend to patch:
composer update drupal/modulename --with-all-dependencies
Again, use --dry-run to preview the dependency graph. Read the module’s release notes for update hooks, configuration changes, permission changes, schema notes, and compatibility warnings. If several modules are tightly coupled, update and test them as one release rather than producing a sequence of partially tested lock files.
Run Drupal’s database and cache operations in the test environment
- Apply database updates with
drush updatedb. - Rebuild caches with
drush cache:rebuild. - If the project uses configuration management, inspect and export changes with
drush config:export --diff. Review the diff before committing it. - Run the site’s automated tests and any deployment checks used by your team.
drush updatedb can enable maintenance mode as part of Drupal’s standard database-update procedure. That behavior is expected in the test environment and is the reason a production zero-downtime design must prepare the new release separately from the live traffic path.
Test behavior, not just Composer’s exit code
A successful dependency solve proves only that Composer found a compatible package set. Test the application paths that can fail when services, plugins, schemas, or permissions change.
Rank #3
- Sleek 7-in-1 USB-C Hub: Features an HDMI port, two USB-A 3.0 ports, and a USB-C data port, each providing 5Gbps transfer speeds. It also includes a USB-C PD input port for charging up to 100W and dual SD and TF card slots, all in a compact design.
- Flawless 4K@60Hz Video with HDMI: Delivers exceptional clarity and smoothness with its 4K@60Hz HDMI port, making it ideal for high-definition presentations and entertainment. (Note: Only the HDMI port supports video projection; the USB-C port is for data transfer only.)
- Double Up on Efficiency: The two USB-A 3.0 ports and a USB-C port support a fast 5Gbps data rate, significantly boosting your transfer speeds and improving productivity.
- Fast and Reliable 85W Charging: Offers high-capacity, speedy charging for laptops up to 85W, so you spend less time tethered to an outlet and more time being productive.
- What You Get: Anker USB-C Hub (7-in-1), welcome guide, 18-month warranty, and our friendly customer service.
- Anonymous access: load the home page, representative content pages, listings, search, cached responses, redirects, and error pages without an authenticated session.
- Authenticated access: sign in with representative roles and test dashboards, content creation, editing, moderation, media uploads, and permissions.
- Forms and integrations: submit important forms and verify payment, email, webhooks, APIs, identity providers, and other external connections where applicable.
- Queues and cron: run scheduled jobs and queue workers, then check that items are processed once and that failures are visible.
- Module-specific features: exercise the exact feature supplied by the contributed module, including administrative screens and any custom code that uses it.
- Performance-sensitive paths: check cache hits, uncached responses, search latency, and pages that depend on rebuilt render or discovery caches.
After testing, inspect the status report and recent logs. Look for PHP errors, deprecations that indicate an upcoming incompatibility, missing plugins, broken routes, failed queue jobs, and warnings that appear only for anonymous visitors. Drupal’s update guidance specifically calls for status-report review, basic operation checks, log checks, and anonymous-user testing.
Free tools Windows power users keep installed
One-click scans. No signup required.
Promote exactly the tested release
- Commit the reviewed
composer.json,composer.lock, configuration changes, and any application-code changes required by the release. - Build an immutable artifact or release directory from that commit. Keep the previous artifact available for an immediate code rollback.
- On production, deploy the commit and run
composer install --no-dev. This installs the versions recorded in the lock file instead of resolving fresh versions. - Run the required database updates and cache rebuild using the deployment process selected for your availability model.
- Export configuration only when the release requires it and the resulting configuration has been reviewed. Do not overwrite intentional production-only settings with an unreviewed export.
- Verify the status report, logs, representative authenticated and anonymous journeys, queues, cron, and critical integrations.
Running Composer on production is not inherently forbidden, but production should install a previously tested lock file. The unsafe practice is allowing production to perform a new dependency resolution whose result differs from staging.
Choose an availability model
The correct deployment pattern depends on whether a short maintenance window is acceptable, whether old and new code can share the database, and how quickly traffic and data can be restored.
| Approach | How it works | Availability | Main requirement | Rollback characteristic |
|---|---|---|---|---|
| Single-host maintenance release | Put Drupal in maintenance mode, install the tested release, run database updates, rebuild caches, then re-enable the site. | Brief interruption while updates run. | A tested lock file, backups, and a maintenance window. | Switch code back and restore the database if the update is not reversible. |
| Blue-green release | Bring up a separate environment with the new code, perform health checks, then route traffic from the old environment to the new one. | Can avoid a user-visible outage during application startup; database work still must be compatible with both versions. | Traffic control, duplicated application capacity, shared or synchronized files, and an expand/contract schema plan. | Switch traffic back to the old environment, then recover data if a database change requires it. |
| Rolling release | Replace application instances in batches while a load balancer keeps healthy instances serving requests. | Can maintain service if enough capacity remains and every intermediate version is compatible. | Health checks, session/cache handling, capacity headroom, and backward-compatible database changes. | Stop the rollout and route traffic to the remaining old instances. |
Blue-green and rolling deployment details are infrastructure guidance derived from Drupal’s maintenance-mode boundary. Drupal’s official procedure documents staging, lock-file promotion, backups, updates, and verification; it does not define one universal traffic-shifting implementation.
How to design a Drupal release with no user-visible outage
Use expand-and-contract database changes
Old and new application instances may overlap during a blue-green or rolling release. A schema change must therefore be staged so both versions can operate during the transition.
- Expand: add new tables, columns, indexes, or fields in a way the old code can ignore. Deploy any compatibility code required to write both old and new representations.
- Migrate: backfill or transform data in controlled batches. Monitor database load and queue failures rather than holding a long blocking operation in the traffic path.
- Switch: route traffic to the new release after health checks and application tests pass.
- Contract: only after the old release is no longer serving traffic, remove obsolete columns, tables, or compatibility code in a later release.
Do not assume that every Drupal update hook is safe to run while old code is active. Inspect the module or core release notes and test the exact overlap scenario. If an update requires an exclusive schema change or an operation that cannot coexist with the previous code, schedule a maintenance window or redesign the migration sequence.
Prepare application instances before shifting traffic
- Build the new release from the tested commit and lock file.
- Install dependencies with
composer install --no-dev. - Warm or rebuild caches according to the hosting architecture.
- Run a health check that verifies PHP startup, database connectivity, required services, and a representative anonymous request.
- Confirm that shared files, private files, sessions, and caches are available to the new instances with the intended consistency and permissions.
- Keep the old instances healthy until post-switch verification is complete.
Shift traffic conservatively
Use the load balancer or equivalent traffic controller to move traffic only after health checks pass. For a rolling release, replace one batch at a time and watch error rates, response times, database load, queue depth, and login or form failures. For blue-green, move traffic to the new environment while preserving a fast route back to the old environment.
Rank #4
- Dual Converters, Infinite Potential：Includes 2× USB C male to USB A female adapters and 2× USB A male to USB C female adapters. Perfect for a wide range of uses—tablets with Bluetooth keyboards, expand USB ports on macbook, and more. Two different converters for all your daily needs
- Next-Level 10Gbps & 3A Charging: No more slow 480Mbps, this usb to usb c adapter has a transfer speed of up to 10Gbps, allowing you to do more transferring in less time. This usb adapter fits both USB A and USB C charger, supporting up to 3A fast charging
- Upgraded Exquisite Craftsmanship: With an aluminum alloy housing and metal connector, the usbc to usb adapter is extremely durable and sturdy. Rigorously tested to withstand more than 10,000 times of plugging and unplugging, ensuring long-lasting performance
- Broad Compatible: The usb c to usb adapter widely supports all USB C/ USB A devices like laptops, tablets, cellphones, car chargers, and phone chargers. Such as compatible with MacBook Pro/Air 2023/2022, Thunderbolt 4/3 Devices,Apple MagSafe Watch 9/8/7/SE/Ultra, iPad Pro 2022/2021, Samsung Galaxy S23/S20/S10, and iPhone 17/16/15 Pro. Plug and play
- Please Note: To reach 10Gbps speed, keep the cable under 3.3 ft. For USB A Male to USB C adapters, try flipping the USB C connector. USB C Male to USB A adapters support bidirectional 10Gbps transfer within 3.3 ft
Session storage and cache behavior deserve special attention. If sessions live only on one instance, a traffic shift can log users out or create inconsistent state. Shared session storage or deliberate session draining is required for continuity. Cache invalidation should be planned so users do not receive stale or incompatible render output after the code switch.
Core updates, module patches, and major upgrades are different work
Core patch or minor update
Use the core Composer command, read core release notes, and check compatibility notes for enabled modules and themes. A minor core update can require contributed-project changes even when the public API appears unchanged. Complete the database-update, cache-rebuild, configuration, and regression-testing steps before promotion.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Contributed module update
Update the specific package with composer update drupal/modulename --with-all-dependencies, read its release documentation, apply its update hooks, rebuild caches, and exercise the module’s user and administrative functions. Review custom integrations that call the module’s services, plugins, routes, or entity fields.
Major-version upgrade
Do not fold a major-version migration into an ordinary patch window. Drupal’s manual-update procedure is limited to updates within the same major version, and dependency policy normally places major dependency changes in major releases unless a critical bug or security requirement dictates otherwise. Plan a major upgrade as a separate project with compatibility work, migration testing, a longer rollback plan, and an explicit cutover strategy.
Non-Composer sites
Manual file replacement is intended only for sites that are not Composer-managed and do not have Composer-managed third-party dependencies. Composer is the recommended path for Composer projects. Mixing manual replacement with a Composer-managed dependency tree makes the lock file inaccurate and complicates rollback.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Rollback when verification fails
Stop the rollout if health checks, logs, status reports, or representative journeys show a regression. In a blue-green deployment, route traffic back to the previous environment while it remains available. In a rolling deployment, stop replacing instances and direct traffic to the remaining old instances.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsIf database changes have already run, determine whether they are backward-compatible before switching code back. Some update hooks are irreversible or change data formats. When the prior release cannot safely use the changed schema, restore the database backup together with the previous code and configuration, following the tested recovery procedure. Drupal’s manual-update guidance directs operators to revert to the prior code and database backup when a fatal failure requires it.
Best Value
- 5-in-1 Connectivity: Equipped with a 4K HDMI port, a 5 Gbps USB-C data port, two 5 Gbps USB-A ports, and a USB C 100W PD-IN port. Note: The USB C 100W PD-IN port supports only charging and does not support data transfer devices such as headphones or speakers.
- Powerful Pass-Through Charging: Supports up to 85W pass-through charging so you can power up your laptop while you use the hub. Note: Pass-through charging requires a charger (not included). Note: To achieve full power for iPad, we recommend using a 45W wall charger.
- Transfer Files in Seconds: Move files to and from your laptop at speeds of up to 5 Gbps via the USB-C and USB-A data ports. Note: The USB C 5Gbps Data port does not support video output.
- HD Display: Connect to the HDMI port to stream or mirror content to an external monitor in resolutions of up to 4K@30Hz. Note: The USB-C ports do not support video output.
- What You Get: Anker 332 USB-C Hub (5-in-1), welcome guide, our worry-free 18-month warranty, and friendly customer service.
- Preserve logs and the failed release artifact for diagnosis.
- Record the exact lock-file and database-update state.
- Confirm that queues, cron, sessions, and integrations are healthy after recovery.
- Do not retry the same release blindly; reproduce the failure on staging first.
Common failure modes and fixes
Composer reports dependency conflicts
Read the conflict chain and check the core, PHP, and module compatibility requirements. Use --with-all-dependencies as intended for the update, but do not loosen constraints indiscriminately. Resolve the conflict on staging, test the complete lock-file change, and commit that result.
The site shows a missing plugin, route, or service
Rebuild caches with drush cache:rebuild, then inspect logs and the module’s release notes. Confirm that the module is enabled, its dependencies are present, and any required update hooks have run. If the problem persists, roll back to the tested previous release rather than repairing production ad hoc.
Anonymous pages fail while logged-in pages work
Test through the same cache and reverse-proxy path used by visitors. Clear or rebuild caches, inspect web-server and Drupal logs, and verify that the new release’s permissions, routes, and cache metadata are correct for anonymous users.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Database updates take longer than expected
Do not hide a long-running update behind an optimistic health check. Measure it on a production-sized staging copy, inspect locking and database load, and decide whether the operation needs batching, an expand-and-contract sequence, or a planned maintenance window.
Configuration differs between staging and production
Use configuration management deliberately. Review drush config:export --diff output, separate environment-specific settings from deployable configuration, and verify the active configuration after deployment. Never assume that a full export from one environment is safe to apply unchanged to another.
Release checklist
- Release notes, compatibility requirements, and relevant issue queues reviewed.
- Status-report errors resolved before the update.
- Database, files, code, configuration, and previous lock file backed up.
- Core or module update resolved on development or staging.
- Lock-file diff reviewed and committed.
drush updatedb,drush cache:rebuild, and configuration diff handled in the test environment.- Authenticated, anonymous, forms, search, queues, cron, integrations, and module-specific journeys tested.
- Production prepared to run
composer install --no-devfrom the tested commit. - Availability model selected: maintenance window, blue-green, or rolling.
- Schema compatibility, sessions, caches, files, and traffic health checks verified for any no-downtime rollout.
- Rollback code, lock file, database backup, and traffic switch rehearsed or confirmed.
- Post-release status, logs, caches, queues, cron, and critical user journeys checked.
Bottom line
Patch Drupal safely by treating every update as a tested release: Composer on staging, reviewed lock-file changes, complete backups, database and cache operations, realistic regression tests, and installation of the exact lock file in production. Drupal’s standard database-update step uses maintenance mode, so zero user-visible downtime requires blue-green or rolling traffic control and schema changes designed for old and new code to coexist. If those conditions are unavailable, schedule a short maintenance window rather than risking an untested live update.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
