Production mode and deploys for Hyvä stores

Hyvä makes the frontend lighter, but it does not change the basics of running Magento well. A store in the wrong mode, or deployed by hand, will be slow and fragile whatever the theme.

This post walks through how we run and deploy Hyvä stores, from the mode setting to the checks after a release.

Always production mode

Magento has three modes: default, developer and production. Live stores belong in production mode.

bin/magento deploy:mode:set production

In production mode, Magento serves pre-built static files and compiled code instead of generating them on request. Errors are logged rather than shown to visitors.

Developer mode is for local work only. We regularly find live stores still in default or developer mode, and it is one of the cheapest speed fixes there is.

Production mode is also part of the setup behind our Hyvä vs Luma benchmark. A fair comparison needs both themes running the way a real store should.

The Tailwind build is part of the deploy

Hyvä styles are built with Tailwind CSS. The build scans your templates and creates a stylesheet that contains only the classes you actually use.

That means the CSS must be rebuilt whenever templates or theme configuration change, before static content is deployed:

cd app/design/frontend/Vendor/hyva-child/web/tailwind
npm ci
npm run build

On our stores, the Tailwind design tokens are rebuilt from config and theme files during deploy. This is how header and brand colours set in Stores > Configuration end up in the stylesheet without anyone editing code.

The details of tokens and the build pipeline are in Tailwind in Hyvä: design tokens and the build pipeline.

A repeatable deploy sequence

Every deploy should run the same steps in the same order. We script them so nobody has to remember them.

1. Pull the release and install dependencies with Composer.
2. Build the Tailwind CSS for each Hyvä theme.
3. Enable maintenance mode if the release contains database changes.
4. Run bin/magento setup:upgrade.
5. Run bin/magento setup:di:compile.
6. Deploy static content for every locale in use.
7. Flush the Magento cache and reload PHP-FPM so OPcache picks up the new code.
8. Disable maintenance mode.
9. Purge the CDN and warm the key pages.

bin/magento setup:upgrade --keep-generated
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f en_GB de_DE
bin/magento cache:flush

Building outside the live directory and switching over at the end keeps downtime short. Releases in separate folders with a symlink switch also give you a fast rollback.

Indexers, cron and background work

Production stores should run indexers on schedule, not on save. Saving a product should not make an admin user wait while the whole catalogue reindexes.

bin/magento indexer:set-mode schedule

Scheduled indexing depends on Magento cron, so cron must run reliably. A stalled cron shows up as prices, stock or new products that do not appear on the frontend.

Other jobs belong in cron too. On our Hyvä demo store, cron creates WebP copies of product images and cleans up test orders every night.

The server underneath

Production mode works best on a server built for Magento. The stack we run for Hyvä stores looks like this:

Separate PHP-FPM pools mean one busy store cannot starve another on the same server. For more on choosing hosting, see best Magento hosting.

Updates and security patches

Magento releases security patches and new versions regularly, and Hyvä publishes updates of its own. Both should go through the same deploy process as any other change.

• Update on a staging copy first. Run the full deploy there and test checkout before touching the live store.
• Update extensions together with Magento. A module that is not ready for the new version can break the frontend or the admin.
• Keep the child theme small. The fewer parent templates you override, the less work each Hyvä update brings.
• Keep everything in version control. Composer files, the child theme and the deploy script all belong in the repository.

Before a larger upgrade, an extension audit shows which modules need attention first.

Checks after every release

A deploy is not finished when the script ends. We run a short check list on the live URL:

• Home, a category and a product page load in every store view.
• Add to cart works and the mini cart updates.
• Checkout reaches the payment step with each payment method.
• No errors in the browser console or in the Magento logs.
• A Lighthouse run on the real URL behind the CDN, after the cache is warm.

Hyvä Checkout has its own content security policy rules. A new payment script or tracking tag can be blocked there, so checkout deserves a real test after every release that touches it.

Pitfalls we hit

• Stale cache after a layout change. If a change does not show, check every cache layer before debugging the code.
• A missing locale in the static deploy. One language then loads without styles or scripts.
• Forgetting the Tailwind build. New classes in a template have no effect until the CSS is rebuilt.
• Testing the origin. We test the public URL behind the CDN with a normal browser user agent, because our nginx blocks bot user agents.

FAQ

Does Hyvä need a different deploy process from Luma?

Mostly the same. The main addition is the Tailwind CSS build, which must run before static content is deployed whenever templates or styles change.

Can I edit templates directly on the live server?

We advise against it. In production mode, template and style changes need a build and deploy, and changes made by hand are lost at the next release.

How do I know if my store is in production mode?

Run bin/magento deploy:mode:show on the server. If it does not say production, that is the first thing to fix.

We run Hyvä stores on optimised servers with scripted deploys, updates and security as part of our Hyvä service. For speed work on an existing store, see Magento speed optimisation.