Zero Downtime Deployment
Questions about compatibility? Contact us.
- Free lifetime updates – every new Magento 2.4.x and Shopify release covered
- Support reply within 24 hours – by the engineers who built it
- Cancel subscriptions anytime – monthly or yearly, no lock-in
- Secure checkout, instant access – download or activate right after payment
Details
Magento zero downtime deployment becomes practical with Zero Downtime Deployment, a digital extension for Magento 2 that builds each release separately and then switches the prepared files into place.
Magento zero downtime deployment workflow
The module prepares releases with Composer, dependency injection compilation and static deployment. Once the release is prepared, it switches the prepared files. Build work stays separate from the live switch, so your team can review each step before the release goes live.
Release visibility and control
- Admin history of deployments
- Deployment logs
- Webhook automation
- Rollback tools that support the release workflow
What to plan before you deploy
Database upgrades still need compatible change and rollback planning. Run preflight database changes and deployment rollback steps on the destination installation before you switch files.
Requirements
- Magento 2.4.9 package line
- PHP and runtime requirements, listed in the included guide
- CLI filesystem ownership and release directory permissions
- Git and Composer when used
- A writable application tree for the in-place release switch
Adobe Commerce on cloud infrastructure
Adobe Commerce on cloud infrastructure must use its supported build and deploy hooks and platform workflow. This package does not replace that pipeline.
What you get
Choose the edition that matches your installation: Community, Enterprise or Magento Cloud. The digital download includes Zero Downtime Deployment Version 1.5.2 and the included guide. This product is listed in the Magento 2 Extensions category under SKU TI-EXT-ZERO-DOWNTIME.
Change Log
Version 1.6.0 – October 26, 2026
New
- First commit of a new site. Connect & Set Up on a store that is not a git checkout yet pushes the store's code to the branch: as the first commit of an empty repository or a new branch, or on top of a branch that has no store (only a README, for example). A store that is a git checkout already pushes its commit. A branch with a store is never overwritten. Never committed: app/etc/env.php and its copies, auth.json, .env, .ssh/, var/, generated/, pub/media/, pub/static/ (their .htaccess files are committed), node_modules/, database dumps, the excluded paths, and vendor/ when composer.lock exists, whatever the store's .gitignore says; a store without .gitignore gets one. Files over 95 MB stop the push with their names.
- Deployments stop when the branch is not ready, like the Adobe Commerce Cloud build (bin/magento module:config:status): before building, app/etc/config.php of the branch must list exactly the modules of the code; after building, the build must not have changed or removed a repository file. The deployment fails before anything goes live and its log lists each file with the reason (module list, a file composer install copies from magento/magento2-base, a committed vendor/ that does not match composer.lock, a build hook) and the command to run on your computer. A config.php with the same modules in another order and JSON files with the same data do not count. Setting When the Branch Is Not Ready (Stores > Configuration > Zero Downtime Deployment > Git; default: stop) and -f deploy anyway.
Improved
- Test Connection reports a branch that does not exist yet as a warning: Connect & Set Up creates it.
- The Git Connection page and the guides describe the first commit; the token needs write access to the repository's contents for it (read-only is enough afterwards).
Version 1.5.3 – October 24, 2026
New
- Customer user guide USER-GUIDE.md (installation with Composer, configuration, usage, troubleshooting).
Improved
- The shadow database example in the admin comment and README is shop_zdd.
- Unit tests build query and JSON result doubles instead of constructing Magento framework classes without arguments, so the suite runs against the real framework.
Version 1.5.2 – October 22, 2026
Fixed
- "Notification could not be sent: Class "Hyva\Theme\ViewModel\SvgIcons" not found" after a deployment that removed Hyvä. The deployment process still runs the code it started with, so rendering the email after the switch needed classes of modules that were gone. Notifications are now sent by bin/magento techimprovement:zdd:notify , a new process with the code that is live; in-process sending is the fallback.
- app/etc/config.php was reported as "changed by the deployment, different in the branch" when setup:upgrade had only sorted the module list. When the modules and their values are the same as in the branch, the log now says that nothing has to be done.
Version 1.5.1 – October 22, 2026
New
- Compare files with the branch at the end of every deployment, also when it fails or is switched back:
- the files it changed, by origin (repository files from the branch, composer packages in vendor/, other files);
- the composer packages it removes, updates and adds, and the folders with the most changes;
- the server compared with the commit it runs, with what to do about each kind of difference.
- The full list is saved in var/techimprovement_zdd/changes/deployment-.txt.
- bin/magento techimprovement:zdd:changes (zdd:changes) shows the same comparison at any time. --diff adds the content changes, --next fetches the branch and shows what the next deployment brings (commits, files, composer packages), and --deployment= prints a deployment's full file list.
- When a page fails the health check without a Magento error report, the log shows the exception text of the page (developer mode prints it). For an empty error page, the same request is run with PHP on the command line, which prints the PHP error. When the page works there, the log says that PHP-FPM differs (usually OPcache).
- The OPcache reset reports PHP-FPM's opcache.validate_timestamps and opcache.revalidate_freq.
Fixed
- Deployments that remove composer packages (for example Hyvä, Magewire or Mollie) were switched back with "Health check failed: HTTP 500" on every page. The switch deleted the removed files while PHP-FPM still ran cached code of the previous release (OPcache), whose autoloader includes them. Every request failed, including the OPcache reset request that would have cleared the cache. Removed files are now deleted right after the OPcache reset. A deployment interrupted in between deletes them on the next run.
Version 1.5.0 – October 22, 2026
New
- Test Connection and Connect & Set Up list files changed on the server (content only), and files only on the server that the branch's .gitignore does not cover, with what to do about them.
- In git deployments, composer require/update/remove is refused before anything changes: composer.json and composer.lock come from the branch.
- When app/etc/config.php in the branch does not list a module that is in the code, or lists one that is not, the deployment log names the command to run on your computer, so the branch has it ready.
- The log of each deployment names the repository files the deployment itself changed, so you can make the same change on your computer.
Improved
- The store never writes to the repository. The branch is the only source of the code, and every change has to be made on a computer and pushed. Removed:
- Commit Store Changes (button, techimprovement:zdd:connect --commit);
- the first commit Connect & Set Up pushed to an empty repository. An empty repository is now refused before anything changes;
- the .gitignore rules Connect & Set Up added to the store;
- the pipeline file committed through the GitHub / Bitbucket API. It is written to var/techimprovement_zdd/ for you to commit. Switching to the webhook asks you to delete it instead of deleting it.
- Only deployments move the store's git checkout. Connect & Set Up used to move it to the newest commit of the branch, so commits pushed but not deployed yet looked like changes made on the server. Commit Store Changes then pushed the store's older files back and undid them, for example a composer update pushed from a computer. Connect & Set Up now only fetches. Test Connection shows which commit the store runs and whether the branch is ahead.
- "Allow Uncommitted Changes" is now Files Changed on the Server. Replace them with the branch version (new default) deploys the branch version and keeps a copy of each replaced file in var/techimprovement_zdd/replaced/-/. Stop the deployment stops until the branch has the change. Messages say to make the change on your computer and push it, instead of pointing to Commit Store Changes.
- GitHub tokens need only the repo scope. Fine-grained tokens need Administration, Secrets and Webhooks read and write, and Contents read-only. The workflow scope is no longer needed.
Fixed
- The module-name fix command that the build prints no longer rewrites this module's own README and tests.

