Hyva Hosting for Magento: What Your Server Must Handle

Hyva hosting for Magento isn’t a special product. Hyvä is a frontend theme, so your host still has to meet Magento’s system requirements, plus a few Hyvä-specific points: a supported PHP version, Node.js 20 or newer somewhere in your build pipeline, and a deploy step that ships a pre-built Tailwind stylesheet.

Key takeaways

• Hyvä’s own getting-started page points to Magento’s documentation for full system requirements, then adds its own: a minimum Magento patch level, PHP 8.1 to 8.4 and Node.js 20.0.0 or newer for the Tailwind compiler.
• Hyvä recommends building the Tailwind CSS bundle on a development, staging or CI/CD environment, not on the production server.
• A production deploy has three steps: build the minified stylesheet, run static content deployment, and transfer the compiled files.
• Hyvä says PHP 8.1 support ends in 2027, and that Magento 2.4.4 and 2.4.5 will lose Hyvä support then too.
• Adobe’s current table tests Adobe Commerce 2.4.9 with PHP 8.5, while Hyvä’s page we read lists PHP 8.1 to 8.4. Confirm compatibility before you choose a PHP version.

If you’re shopping for Hyva hosting, you’ll find providers who sell it as a distinct plan. That’s fine, but it helps to know what’s genuinely different about running Hyvä before you pay for a label. Most of what a Magento store needs from a server is unchanged. What changes is small, specific and mostly about where your build runs.

This guide separates the two. First, what Magento itself demands of a host, using Adobe’s system requirements table. Then what Hyvä adds, using Hyvä’s own documentation. Finally, how to deploy, and what to ask a provider. Everything factual comes from Adobe’s and Hyvä’s published documentation, which we read on the date at the bottom. We don’t name or rate hosting companies, because we haven’t tested them for this article.

What does Hyvä change about hosting?

Less than people expect, and in one place more than they expect.

Less, because Hyvä replaces the storefront theme, not the platform underneath. Hyvä’s getting-started page tells you that the full Magento system requirements are in Magento’s developer documentation. So the database, search engine, cache, web server and message queue you’d need for any Magento store are still needed.

More, in one specific area: the frontend build. Hyvä uses Tailwind CSS, and compiling it requires Node.js. Hyvä’s page says Node.js 20.0.0 or newer is required on development instances to run the Tailwind compiler. That means somewhere in your workflow, a machine needs Node, and Hyvä is firm about where that machine should not be.

Two further differences show up at deploy time. Hyvä sites don’t benefit from Magento’s built-in minification and bundling, so the recommended configuration turns them off. And static content deployment can skip several steps Hyvä themes don’t need. We’ll go through both.

The takeaway for buyers: a host doesn’t need to be “Hyvä certified” to run Hyvä. It needs to meet Magento’s requirements, run a PHP version Hyvä supports, and let your team deploy a pre-built stylesheet. Whether a particular provider adds value beyond that is a separate question.

What are the system requirements for a Hyvä store?

There are two layers: Magento’s, and Hyvä’s. Start with Hyvä’s, since it sets the floor.

Hyvä’s getting-started page lists these minimums:

• Magento 2.4.4-p9, 2.4.5-p8, 2.4.6-p7, 2.4.7-p1 or higher
• A free Hyvä packagist.com key
• PHP 8.1, 8.2, 8.3 or 8.4
• Node.js 20.0.0 or newer on development instances, for the Tailwind compiler
• Content Security Policy support requires Magento 2.4.4 or higher

Then Adobe’s layer. Adobe’s system requirements page, last updated on 13 October 2026, has tabs for Commerce on Cloud and Commerce on-premises. The on-premises tab lists the following for the latest releases.

The 2.4.8 column also lists Elasticsearch 8 alongside OpenSearch 3. Adobe’s page also notes that it supports only the combinations listed and doesn’t validate or support configurations that don’t match one, and gives an example: Adobe Commerce 2.4.9 is tested with MariaDB 12.3, so upgrade to MariaDB 12.3 before you upgrade to 2.4.9.

One caution about reading that table. The Commerce on Cloud tab is not identical to the on-premises tab. For 2.4.9 on cloud, Adobe lists MariaDB 12.3 as recommended with 11.8 also listed, and notes that cloud versions sometimes differ from on-premises ones. Make sure you’re reading the tab that matches how you’re hosted.

This table is for Adobe Commerce. If you run Magento Open Source, check the equivalent requirements for your version before relying on these numbers, as we haven’t verified the Open Source table for this article.

Which PHP version should a Hyvä store run?

This is the place where two documentation sets disagree, and it’s worth slowing down.

Adobe’s table lists PHP 8.5 for Adobe Commerce 2.4.9, and PHP 8.4 and 8.3 for the latest 2.4.8 patch. Hyvä’s getting-started page, as we read it, lists PHP 8.1, 8.2, 8.3 or 8.4 as supported. PHP 8.5 isn’t in that list.

We’re not claiming Hyvä doesn’t work on PHP 8.5. We haven’t tested it, and Hyvä’s page may have been updated since. What we are saying is that on the pages we read, the supported ranges don’t overlap at 2.4.9’s tested version. If you plan to move to 2.4.9 and PHP 8.5, check Hyvä’s current requirements and release notes first, and test on staging with your full set of extensions before touching production.

Hyvä’s page adds a planning note. It says PHP 8.1 support ends in 2027: from 2027 onwards, Hyvä products will be built with PHP 8.2 and newer code. Existing installations on PHP 8.1 won’t break straight away, but PHP 8.1 won’t be supported. The same note says Magento 2.4.4 and 2.4.5, including all their patch releases, run only on PHP 8.1 and will no longer be supported from 2027. Hyvä tells you to upgrade to Magento 2.4.6 or higher and to use the latest patch release, giving 2.4.6-p15 as an example.

So the practical guidance is:

• If you’re on PHP 8.1, plan your upgrade now. The deadline is Hyvä’s, not your host’s.
• If you’re on Magento 2.4.4 or 2.4.5, you have two upgrades to schedule, not one, since the Magento version caps your PHP version.
• If you want the newest Magento and PHP, treat Hyvä compatibility as something to verify, not assume.

We cover the PHP side of the newest release in our post on PHP 8.5 and Magento 2.4.9 upgrade readiness.

Where should the Tailwind build run?

Not on your production server. That’s Hyvä’s recommendation, and it’s stated in two places.

On the getting-started page: “We recommend building the Tailwind CSS bundle on a development or staging instance, not on production.” On the deployment page, Hyvä says to generate the production stylesheet on a development, staging or CI/CD build environment rather than on the production server, and that installing Node.js and build tools on production servers introduces unnecessary security risk.

That recommendation has a direct hosting consequence. If your plan assumes you’ll SSH into the live server, install Node, and run the build there, you’re doing what Hyvä advises against. It also has a cost consequence. A pre-built stylesheet means your production server needs less software and fewer moving parts.

Where does the build run, then? Three common options:

A developer’s machine. Fine for small teams if the process is documented and the build is reproducible. The risk is “it worked on my laptop.”

A staging server. Build there, test the result, then ship the output. This keeps the build near a realistic environment.

A CI/CD pipeline. Best for repeatability. For automated pipelines, Hyvä recommends npm ci rather than npm install so builds use the exact versions in the lock file, and adds the --ignore-scripts flag to stop packages running lifecycle scripts during installation, which protects against supply chain attacks.

If you’re comparing hosts, ask how each supports one of these three. A provider that gives you SSH but no staging, or that can’t run your pipeline, makes the Hyvä workflow harder.

What does a Hyvä production deployment look like?

Hyvä’s deployment page describes the standard manual workflow for traditional hosting. It has three steps.

Step 1: generate the production stylesheet. From your theme’s web/tailwind directory, run the build command to produce the minified stylesheet at web/css/styles.css. Hyvä notes that you can alternatively run it from the Magento root with the npm prefix flag pointing at that directory. A history note: Hyvä 1.1.x used a different script name, while current versions use npm run build. Unlike development mode, where a watcher generates CSS on the fly, production needs the pre-built minified file.

Step 2: deploy static content. Run Magento’s static content deployment so the stylesheet and other theme assets are copied into the public static directory, where browsers load them in production mode. Hyvä points out that its themes don’t need LESS compilation, JavaScript bundling or HTML minification, and that turning these off significantly reduces deployment time. Its example deploys the admin theme for one locale and the frontend theme for several locales, skipping LESS and bundling and minification.

Step 3: transfer the assets. Move the public static directory to your production server with whatever method you use, such as rsync, SCP or a CI/CD pipeline.

Then verify. Hyvä’s checklist: flush the cache on the production server, confirm the stylesheet loads in the browser’s Network tab, check the console for missing-asset 404 errors, and test responsive styles by resizing the browser.

For the Magento side of the same sequencing problem, see our post on Magento DevOps.

Because the build and the static content deploy are separate from the live site, you can run them without taking the store down. That’s an advantage of getting the build off the production box.

How do you deploy Hyvä on Adobe Commerce Cloud?

Differently, and Hyvä has a dedicated page for it. The page explains that Adobe Commerce Cloud uses a containerized build environment where Node.js isn’t pre-installed, the build phase runs before Magento is fully initialized, and generated files must be created during specific build hooks or they won’t be included in the deployed static assets.

The guide covers declaring Node.js as a platform dependency, configuring build hooks in the cloud application configuration file to compile Tailwind CSS, setting up Composer authentication for Hyvä’s private packagist, committing the configuration files that can’t be generated during cloud builds, and fixing a gitignore problem. On that last point, Hyvä warns that Tailwind v4 source merging doesn’t work with the default Adobe Commerce Cloud gitignore file, and refers to a separate section for the fix.

One more detail matters if you use Hyvä’s runtime Node services. The page says that if you run a Hyvä Node daemon at runtime, such as the CMS Tailwind compiler or the response minifier, it needs a separate setup and only stays up on Pro Staging and Production environments. That’s a limit to check against your plan before you design around those features.

Hyvä also has deployment pages for Capistrano. We haven’t read those closely for this article, so if you deploy with Capistrano, go to Hyvä’s page directly.

Which server settings change when you run Hyvä?

Mostly configuration, set through the command line. Hyvä’s getting-started page lists the settings.

Theme at website level. Hyvä says to always set a theme at the Website level. Setting hyva/default only at store view level while Website and Store stay on “No Theme” causes storefront issues. It doesn’t matter which theme is set at website level, as long as one is.

Magento’s minification and bundling. Hyvä states that Magento’s built-in minification and bundling of HTML, CSS and JS don’t benefit Hyvä sites, and can cause overhead and unwanted side effects. It recommends turning them off for any store view running Hyvä, giving a list of configuration paths to set to zero covering HTML minification, JS merging, JS bundling, JS minification, moving scripts to the bottom, CSS merging and CSS minification. If you also run Luma-based themes on other store views, Hyvä says to keep these enabled for those store views.

Captcha. Hyvä doesn’t support the legacy Magento captcha, which is on by default, and you need to disable it for forms to work. It supports three Google reCAPTCHA versions provided by Magento: V3 invisible, V2 invisible and V2 “I’m not a robot”.

GraphQL modules. Hyvä uses parts of Magento’s GraphQL API, so certain GraphQL modules must be enabled. Fresh installs have them all enabled, but stores that previously used Luma often have unused ones disabled. Hyvä lists the required modules and says not all are needed in every store, depending on which Hyvä features you use. Recently Viewed Products is the example it gives.

Deploy mode. Hyvä’s guidance on verification varies by mode. In developer mode the theme appears straight away, though a cache flush may be needed. In production mode you need to run static content deployment first. In default mode you must enable each new module manually, and Hyvä adds that you should never run a Magento store in default mode.

On-the-fly minification (experimental). Hyvä mentions a module that minifies HTML, JS and CSS on the fly, rather than at static content deployment. It describes it as experimental. We wouldn’t build a production plan around an experimental module, but it’s worth knowing it exists.

These are all things your host’s control panel or your deploy scripts need to be able to do. None of them is exotic.

What stays the same for the rest of the stack?

Almost everything else. Magento still needs a database, a search engine, a cache and session store, a message queue and a web server, and the versions listed in Adobe’s table still apply. Hyvä’s pages we read don’t list separate requirements for these components. They point to Magento’s documentation for full system requirements.

Adobe’s page makes a couple of related points worth repeating. It recommends verifying that PHP OPcache is enabled to improve performance, and notes that many PHP distributions enable it, and that on Cloud the opcache extension is installed by default. On-premises, you should verify the extension is installed. Adobe also directs you to its documented PHP settings, such as memory_limit, to help avoid common problems.

So when a provider markets Hyva hosting as optimised, ask what specifically is optimised. The honest answers are things like: a Node-capable build environment, a staging site, a deployment pipeline, a PHP version in Hyvä’s supported range, and caching configured for Magento. Those are all reasonable. A claim that Hyvä needs a faster or different kind of server than Magento isn’t something the Hyvä pages we read say.

Performance claims about Hyvä itself are a separate question. Our comparison of Hyvä versus Luma performance and cost is the place to read about that, and our Magento performance optimization playbook covers the server and application side.

How do you choose Hyva hosting for your store?

Work from your requirements, not the provider’s marketing. Here’s a way to do it.

Step one: write down your Magento version and PHP version targets. Choose them from Adobe’s table and Hyvä’s supported range, and note where they conflict.

Step two: decide where the build runs. Developer machine, staging or CI/CD. That determines whether you need a shell on the host, a staging environment, or neither.

Step three: list your required services. Database, search, cache, queue and web server at the versions in Adobe’s table for your Magento version.

Step four: ask each provider to confirm in writing that they support those exact versions, and what they’ll do when you upgrade.

Step five: check the operational basics. Backups, restores, staging, access control, monitoring and support hours. These matter more than any theme-specific feature.

Step six: test with a staging copy. Before you migrate, deploy a Hyvä build to a staging environment on the host and run through the verification steps from Hyvä’s deployment page.

If you’re moving from Luma to Hyvä at the same time as changing hosts, resist doing both at once. Moving the theme and the infrastructure together makes problems hard to attribute. We have a separate Hyvä implementation timeline guide, and our move Magento to Hyvä service is there if you want help with the migration itself.

What should you ask a hosting provider?

Take this list into the conversation.

• Which Magento and Adobe Commerce versions do you support, and how quickly do you adopt new releases?
• Which PHP versions can I run, and can I pick per environment?
• Can I run Node.js 20 or newer in my build environment, and where does that run?
• Do I get a staging environment that mirrors production?
• Can I deploy a pre-built pub/static directory, and can I use my own CI/CD pipeline?
• Which versions of MariaDB or MySQL, OpenSearch, Valkey or Redis, RabbitMQ, Varnish and nginx do you run, and do they match Adobe’s table for my version?
• Is PHP OPcache enabled?
• How do backups and restores work, and when did you last test one?
• What happens when Magento and PHP need to be upgraded? Who does it and who pays?
• If I need Hyvä’s runtime Node services, are they supported on every environment?

None of these questions is about Hyvä specifically except the Node ones. That’s the point: most of the evaluation is about running Magento well.

Common Hyva hosting mistakes

Building on the production server. Hyvä recommends against it, citing security risk from installing Node and build tools there. Build elsewhere and ship the output.

Skipping the lock file in CI. Using npm install instead of npm ci can pull newer compatible versions and produce non-reproducible builds.

Leaving Magento’s minification and bundling on. Hyvä says these add overhead and side effects for Hyvä store views. Turn them off for those store views.

Forgetting the website-level theme. Setting the theme only on a store view while the website has none causes storefront problems, according to Hyvä.

Leaving the legacy captcha enabled. Forms won’t work correctly until it’s disabled and one of the supported reCAPTCHA types is used instead.

Assuming PHP 8.5 works. Adobe tests 2.4.9 with PHP 8.5, but Hyvä’s page we read lists 8.1 to 8.4. Verify before you upgrade.

Staying on PHP 8.1 or Magento 2.4.4/2.4.5 too long. Hyvä says support for PHP 8.1 and for those Magento versions ends in 2027.

Disabling needed GraphQL modules. Stores that used Luma often have unused ones switched off, and Hyvä needs several of them.

Using GitLab SSH in pipelines. Hyvä says GitLab availability isn’t guaranteed and to always use packagist.com for build pipelines and production deployments. The GitLab route is for contributors and technology partners.

Frequently asked questions

Do I need special hosting for Hyvä?

None of the Hyvä pages we read describe special hosting. Hyvä requires Magento’s normal system requirements plus a supported PHP version and Node.js 20.0.0 or newer in a development, staging or CI/CD environment to build Tailwind CSS.

Which PHP versions does Hyvä support?

The Hyvä getting-started page we read lists PHP 8.1, 8.2, 8.3 and 8.4, and says PHP 8.1 support ends in 2027. Adobe’s table lists PHP 8.5 for Adobe Commerce 2.4.9, so check Hyvä’s current requirements before using 8.5.

Does Hyvä need Node.js on the production server?

Hyvä recommends against it. It says to build the Tailwind CSS bundle on a development, staging or CI/CD environment and not on production, because installing Node and build tools on production adds unnecessary security risk.

How do I deploy a Hyvä theme to production?

Build the minified stylesheet, run Magento’s static content deployment, then transfer the public static directory to production. Afterwards, flush the cache and check that the stylesheet loads without 404 errors.

Can I run Hyvä on Adobe Commerce Cloud?

Yes, Hyvä has a dedicated deployment guide for it. Node.js isn’t pre-installed there, so you declare it as a platform dependency and compile Tailwind in build hooks. Hyvä Node daemons stay up only on Pro Staging and Production.

Should I turn off Magento’s JS and CSS bundling for Hyvä?

Hyvä recommends turning off Magento’s built-in minification and bundling for store views running Hyvä, because they add overhead and unwanted side effects. Keep them on for any Luma store views.

Which Magento version do I need for Hyvä?

Hyvä lists Magento 2.4.4-p9, 2.4.5-p8, 2.4.6-p7, 2.4.7-p1 or higher. It also says 2.4.4 and 2.4.5 will lose support in 2027, so Hyvä advises upgrading to 2.4.6 or higher.

Is Hyvä hosting faster than normal Magento hosting?

The Hyvä pages we read don’t describe Hyvä hosting as a different class of server. Speed depends on your theme, your Magento configuration and the server. For specifics, see our Hyvä versus Luma performance comparison.

Where to go from here

Write down three facts about your current store: the Magento version, the PHP version, and where your Tailwind build runs. If the third answer is “on the production server,” fix that first, since it’s the one change Hyvä’s documentation pushes hardest.

Then check your versions against Hyvä’s minimums and Adobe’s table, and plan any PHP or Magento upgrade you need before 2027. When you’re comparing Hyva hosting options, bring the question list above and ask for answers in writing. If you’d like help planning the move or the deployment pipeline, talk to our Magento development team.