We know the recommended Magento 2 deployment process which roughly contains the following steps:

php bin/magento maintenance:enable
composer require <package> <version> --no-update
composer update
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy
php bin/magento maintenance:disable

This process includes a downtime which can take a while depending on different factors like the number of modules, dependencies and of course the included database changes in a version. While the static content can easily be deployed in non production environment and taken later into production (e.g. container, simlinks etc.), the database schema update is a challenge.

I have read a lot about this issue, for example the answers and discussion to this question: Can you achieve zero downtime deployment with magento2?

There are a lot of E-Commerce sites where continuous deployment is state-of-the-art and a deployment downtime is not acceptable.

Now my questions are:

  • What are your proven production deployment strategies (and architectures) to achieve a zero-downtime with Magento 2?
  • Is zero-downtime deployment only possible if there are no database changes?

And yes, I know that for the most stores a downtime of a few minutes is not an issue and acceptable :-)

  • I have been wondering this myself because some people just can't handle any type of downtime for development reasons. It would be great if this answer receives some response. I can see in the devdocs that there are tools for the Magento Cloud Commerce platform where they achieve zero downtime while redeploying.
    – gabtzi
    Commented Jul 3, 2019 at 12:23
  • zero-downtime = you can not run these commands you posted on live system. so with some little research you need to have pre-production system, you push updates from to live...
    – MagenX
    Commented Nov 23, 2019 at 13:22

2 Answers 2


Long story short, if there are database changes there will be downtime since you will need to do setup:upgrade and that will take the application down temporarily.

Currently, we have CI/CD setup on AWS, we build the application (static content deploy, di compile etc) and pack it as an EC2 AMI. Once this is done, we deploy the new images into the cloud keeping the old ones running. At this stage, we have the old version of the website running and new new version not receiving any traffic. Then we enable maintenance mode, do setup upgrade, redirect traffic from old codebase to new codebase and disable maintenance. Now you could say, do maintenance enable, setup upgrade and maintenance disable on the new codebase so the old codebase still processing requests, but the problem is that when you do setup:upgrade, since there is only one database working, both version of the codebase would go down.Doing this approach we achieve a few seconds downtime (the time setup:upgrade takes).

IF you want, I can specify a bit more how we have achieved the above.


On my projects, I use Magento 2 Zero Downtime Extension by Magefan. It's a paid one but it works well. It is very simple to install and configuration as it just Magento module and no server-side changes are required. Also, some of my clients use shared web hosting with no root access, so no way to use solutions that require infrastructure changes.

I use GIT to manage the code changes and this module compatible with git, once I need to deploy any new code (fixes, new extensions, new features, etc.) I just run CLI command:

bin/magento magefan:zero-downtime:deploy

And the module creates an additional deployment instance (folder), pulls the new changes from git, installs new dependencies through composer, runs all bin/magento setup stuff, and then pushes all the changes to the live Magento folder and all of this without breaking the website and maintenance mode during the process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.