[{"data":1,"prerenderedAt":81},["ShallowReactive",2],{"7ac60Iaxgd":3},{"id":4,"slug":5,"title":6,"excerpt":7,"meta_title":8,"meta_description":8,"page_content":9,"featured_image":8,"fields":77,"published":16,"published_at":78,"created_at":79,"updated_at":80},"7b1f9e2c-4a06-4d83-9f51-c8e6a0b73d14","notes/deploying-magento-then-and-now","How I Used to Deploy Magento (and How Shipping Works Now)","Pushing changes live on a Magento store used to be a careful, nerve-wracking routine: maintenance mode, a string of commands, and a real chance the site fell over while you watched. Here is how I used to do it, and how shipping changes works now on a headless build.",null,{"blocks":10},[11,18,24,31,35,45,49,53,57,61,65,69],{"id":12,"data":13,"type":17},"c3a87f60-9d24-4b1e-8a07-6f2d9c4e05b8",{"headline":6,"subtitle":14,"highlight":15,"useGradient":16},"Pushing a change live used to mean maintenance mode, a run of commands, and holding your breath. Here is the old routine, and how it works now without the site going down.","Notes",true,"hero",{"id":19,"data":20,"type":23},"e0d4b29a-1c67-4f35-b8d2-3a905e7c6f41",{"content":21,"maxWidth":22},"\u003Cp>Every website needs changes after it goes live. A new product, a price update, a fix for something a customer spotted. The question that decides how stressful that is comes down to one thing: what happens to the live site while you push the change. Does it stay up and fast, or does it go dark for a few minutes while the work lands?\u003C/p>\u003Cp>For years, on Magento, the honest answer was that it went dark. A deploy was a routine you had to get right, with real risk that something broke in front of customers. I made a few videos about it back when I ran a Magento channel, because it was the kind of thing that tripped people up constantly. Here is what that routine looked like, and how shipping changes works for the stores I build now.\u003C/p>","lg","wysiwyg",{"id":25,"data":26,"type":30},"9f62c1d8-7e30-4a94-8c6b-2d05f8a3e917",{"align":27,"title":28,"subtitle":29},"center","How I used to do it","","heading",{"id":32,"data":33,"type":23},"4a8d3e71-0b59-4c26-9d83-6f1a72c0e54b",{"content":34,"maxWidth":22},"\u003Cp>Deploying a Magento store was never one button. Even in 2021 it still took minutes, and the site had to go into maintenance mode while it happened, which means visitors got a holding page instead of the shop.\u003C/p>\u003Cp>The routine went something like this. Put the site into maintenance mode so nobody hits it mid-change. Run the upgrade command, which enables any new code and applies database changes. Generate the code Magento needs. Then run the static content deploy, which rebuilds the theme files the browser actually downloads, one set per language region. Then flush the caches so the old versions stop being served. Miss the static content step in production and the site throws an error, because unlike in developer mode those files do not regenerate on their own. You had to know that, or you found out the hard way.\u003C/p>\u003Cp>The whole sequence ran over SSH or through a deploy tool, and it was slow. A clean run might be five minutes. A bad one I have watched crawl to fifteen or twenty. The slowest part was always rebuilding the static content, and the database upgrade had to run behind a maintenance page because doing it on a live database with customers on the site is asking for trouble.\u003C/p>\u003Cp>I spent a long time trying to make that safer. The best I landed on was a release-folder setup: build everything in a fresh folder off to the side, then flip a symlink so the new version goes live in one move, and only drop into maintenance mode for the database step if the change actually needed one. With a flag to keep the static content I had just built, that downtime came down to about ninety seconds on the deploys that needed it, and a lot of smaller deploys had none at all. Better. But I stopped calling it zero downtime, because on a real Magento store there is no such thing. The most honest name for it was minimum downtime.\u003C/p>",{"id":36,"data":37,"type":44},"d5c907b2-3f81-4e60-8b14-7a2e6d093c8f",{"url":38,"loop":39,"muted":39,"title":40,"autoplay":39,"provider":41,"subtitle":42,"thumbnail":29,"aspectRatio":43},"https://www.youtube.com/watch?v=T6QPkAVDum8",false,"The original video","youtube","Walking through the Magento 2 deploy commands and the minimum-downtime release setup, from the old AnotherMagentoDev channel.","16:9","video",{"id":46,"data":47,"type":23},"81e4a063-6c92-4d17-9a58-0f3b7e2c41d6",{"content":48,"maxWidth":22},"\u003Cp>Notice what all that effort was really for. None of it made the store better. It was work spent stopping a deploy from taking the shop offline, on a platform where every push rebuilt heavy files and touched a live database. You also had to be careful how often you shipped, because a run of deploys right after launch, exactly when a new client wants ten small tweaks, could drag the site's performance down while it kept rebuilding. The deploy itself was a thing you had to manage.\u003C/p>",{"id":50,"data":51,"type":30},"2c6f80a9-5d13-4b78-8e92-1a47c0f6b35e",{"align":27,"title":52,"subtitle":29},"How I do it now",{"id":54,"data":55,"type":23},"6b03d8f1-9a47-4c52-8d61-3e29f70b4a8c",{"content":56,"maxWidth":22},"\u003Cp>Now there are two kinds of change, and neither one takes the site down.\u003C/p>\u003Cp>The first kind is content: a new product, a price, a photo, a paragraph. That goes through the CMS. The client makes the edit, saves it, and it goes live. No deploy, no commands, no maintenance page. The thing they wanted to change is the thing they change, directly, and the site stays up the whole time.\u003C/p>\u003Cp>The second kind is a code change, the actual build. That gets pushed to git, and from there the build runs and the new version deploys out to a content delivery network automatically. The visitor is always being served a finished, prerendered site from a server close to them, so there is no live application grinding through a rebuild while people wait. The new version simply becomes the version that gets served. If a build has a problem, it does not replace the good one, so a bad push does not put a broken store in front of customers.\u003C/p>\u003Cp>And to be clear about who does that: on the stores I run, the deploys are handled. The client is not SSHing into a server, not running commands, not watching a deploy bar and hoping. They change content when they want to, and the infrastructure side is mine to look after.\u003C/p>",{"id":58,"data":59,"type":30},"f74a1c50-2e89-4b63-9c07-8d51a6e3027b",{"align":27,"title":60,"subtitle":29},"What changed, and why it matters to you",{"id":62,"data":63,"type":23},"a35e0b78-4c91-4d26-8f03-5b1d9a7e62c4",{"content":64,"maxWidth":22},"\u003Cp>The short version is that shipping a change used to be a careful procedure and now it is mostly a non-event. With Magento, pushing changes live meant maintenance mode, a run of commands, a slow rebuild, and a real chance something fell over in front of customers. The headless way splits the two jobs apart: content goes live through the CMS without a redeploy, and code ships by pushing to git and letting the build go out to a CDN on its own.\u003C/p>\u003Cp>For a business owner that lands in a few practical ways. You can change your own content, today, without booking developer time or risking the site to fix a typo. The site does not go offline every time something gets updated, so you are not losing visitors during a deploy. There are fewer moving parts to break, which means fewer of those mornings where a small change took the shop down. And shipping often stops being something to ration, because a deploy no longer drags the live site's speed down while it runs.\u003C/p>\u003Cp>If you sell online and you want this without running any of the deploy side yourself, that is what HD Commerce is for. It is a managed subscription I build and look after for you, fully customisable to how your business works, with no transaction fees taken out of your sales. You are not buying a platform to maintain and you are not handing a cut of every order to a marketplace. You change your content; I handle the infrastructure and the deploys.\u003C/p>",{"id":66,"data":67,"type":23},"08d6f3a1-7b52-4e94-8c60-2a4f1d093e7b",{"content":68,"maxWidth":22},"\u003Cp>\u003Cem>Originally published as a series of videos in 2021 and 2022, rewritten here.\u003C/em>\u003C/p>",{"id":70,"data":71,"type":76},"b29c4f70-6a18-4d53-8e21-9f0b5c3a7d46",{"title":72,"subtitle":73,"buttonLink":74,"buttonText":75,"useGradient":16,"secondaryButtonLink":29,"secondaryButtonText":29},"Stop dreading the deploy","If pushing a change to your store still means downtime and crossed fingers, HD Commerce is a fully managed, fully customisable headless store where content goes live through the CMS and the deploys are handled for you, with no transaction fees on your sales.","/hd-commerce","See HD Commerce","cta",{},"2026-06-12T08:00:00+00:00","2026-06-04T09:00:00+00:00","2026-06-12T08:00:02.094471+00:00",1781251245122]