A Hyvä theme is a Magento 2 frontend built on Tailwind CSS and Alpine.js that replaces the legacy Luma theme. Since November 2025 the core theme is free and open source under OSL 3.0 and AFL 3.0. You then choose a build path: a ready-made theme, the Hyvä UI component library, or a custom child theme built from the default.
The pricing question that dominated Hyvä conversations for years is settled, which means the real decision has shifted. It is no longer whether the licence is worth it. It is which of the three build paths fits your brand, your catalog, and your team, and whether your Magento version can run Hyvä at all. This guide covers both, with the version requirements taken directly from Hyvä’s documentation.
What people mean by “Hyvä theme”
The term gets used loosely, and the ambiguity causes real scoping mistakes. There are four distinct things:
- Hyvä Theme is the frontend itself: the Tailwind and Alpine replacement for Luma. This is the free, open-source part.
- Hyvä UI is a commercial library of prebuilt, copy-paste components for building pages faster.
- Hyvä Checkout is a separate commercial product that replaces Magento’s checkout.
- Hyvä Commerce and Hyvä Enterprise are bundled suites for Magento Open Source and Adobe Commerce respectively.
When a merchant says “we want to buy a Hyvä theme,” they usually mean the first one, which is no longer something you buy. When an agency quotes “a Hyvä theme build,” they usually mean designing and building a child theme on top of that free core, which is where the actual cost lives. Getting this distinction straight before you request quotes will save you a confusing procurement cycle.
The licence change, and what it actually changed
Hyvä relicensed the theme in November 2025. Per Hyvä’s licence page, the default theme is dual-licensed under AFL 3.0 and OSL 3.0, with the supporting modules under OSL 3.0. Hyvä’s own announcement of the change sets the date at 10 November 2025, from which the theme became freely available on GitHub and through free Composer keys.
What changed: the per-store licence fee that had been the main adoption barrier is gone. A merchant evaluating Hyvä no longer weighs a licence cost against a maintenance saving.
What did not change: the build. Hyvä is a frontend replacement, so every template, every piece of custom styling, and every third-party module that rendered through Luma still has to be accounted for. Free core, paid work. Anyone quoting you a Hyvä project as cheap because the licence is now zero has the economics backwards, and we modelled the real numbers in our 3-year Hyvä total cost of ownership breakdown.
The commercial add-ons remain commercial. Hyvä UI, Hyvä Checkout, Hyvä Commerce, and Hyvä Enterprise are still licensed products. If your plan depends on Hyvä Checkout, that is a separate line item.
Can your store actually run Hyvä?
This is the check to run before any design conversation, and it disqualifies more stores than people expect. From the Hyvä getting started documentation:
| Requirement | Supported | What it means for you |
|---|---|---|
| Magento version | 2.4.4-p9, 2.4.5-p8, 2.4.6-p7, 2.4.7-p1 or higher | Patch level matters, not just the minor version |
| PHP | 8.1, 8.2, 8.3, 8.4 | PHP 7.4 is not supported; upgrade first |
| Node.js | 20.0.0 or higher, on development instances | Needed for the Tailwind compiler |
| Tailwind build | Run on development or staging | Not intended to be compiled on production |
Two things in that table catch teams out. The first is that the requirement is stated at the patch level. Being on 2.4.6 is not the same as being on 2.4.6-p7, and a store several patches behind has an upgrade project in front of the Hyvä project. The second is Node on the build pipeline. Hyvä introduces a frontend toolchain to a stack that may never have had one, which is a deployment change as much as a theme change. We wrote up where that build belongs in the Magento and Hyvä release pipeline guide.
If you are running PHP 7.4 or an old 2.4.x patch level, sequence the platform upgrade first. Attempting both at once is how a three-month project becomes a six-month one.
The three build paths
Once you clear the requirements, the decision is how you get from the default theme to your brand.
| Ready-made theme | Hyvä UI | Custom child theme | |
|---|---|---|---|
| Best for | Small catalogs, speed to launch | Teams with in-house frontend capacity | Established brands with a design system |
| Design fidelity | Constrained to the template | Component-led, flexible | Exact to brand |
| Code you carry | Includes what you do not use | Only components you paste | Only what you build |
| Upgrade friction | Depends on vendor | Low | Low if the child theme is disciplined |
| Typical cost | Lowest | Low to moderate | Highest |
Ready-made themes get you live fastest and are a reasonable choice for a small brand whose design requirements are modest. The trade-off is that ready-made templates carry markup and styling for use cases you do not have, which erodes some of the performance advantage that brought you to Hyvä in the first place, and ties your upgrade path to a third-party vendor’s release cadence.
Hyvä UI is the middle path. You compose pages from a maintained component library rather than inheriting a whole template. It suits teams with a frontend developer who can assemble and adapt components, and it keeps your codebase closer to the core.
A custom child theme is the right answer for brands where the storefront is a competitive asset and the design is specific. Built with discipline, meaning you override only what you must and leave the core untouched, a child theme is also the easiest to upgrade, because there is less of your own code sitting between you and the next Hyvä release.
The failure mode across all three is the same: overriding too much of the core. Every template you copy to change one class is a file you now own forever and must reconcile on every upgrade. The closer you stay to the default, the cheaper the next three years are.
How to evaluate a ready-made theme
If you go the ready-made route, most buyers evaluate on the demo, which is the least informative thing available. Five questions predict how the next two years go.
What Hyvä version does it target, and how quickly does the vendor follow releases? A theme still targeting 1.3 when 1.4 has been out for months tells you what upgrade support will look like. Ask for the changelog rather than a promise.
How much does it override? Ask directly how many core templates the theme replaces. A theme that overrides heavily is one you will fight on every Hyvä upgrade, and the vendor absorbs that cost only while they choose to.
What happens if you stop paying? Licence terms differ. Some themes stop receiving updates, which is survivable. Understand which you are buying before you build a business on it.
Does it assume its own extensions? Some ready-made themes are shop windows for a vendor’s module catalog and degrade if you do not install the rest. That is not necessarily bad, but it is a dependency you should choose deliberately.
Can you see a live store, not a demo? Demos run on curated catalogs and fast hosting. Ask for two production URLs and test them yourself on a phone.
The pattern behind all five is the same. You are not buying a design, you are buying a maintenance relationship, and the design is the part you will care about least by year two.
What actually drives the cost
The theme is free. These are the line items that are not:
- Extension compatibility. Every third-party module with a frontend needs a Hyvä-compatible version, a compatibility module, or a rebuild. This is consistently the largest variable in a Hyvä project, and we covered the triage approach in our guide to adapting third-party Magento extensions to Hyvä.
- Design and build. Whether you adapt a template or build a child theme, someone designs and implements every page type.
- B2B and custom flows. Company accounts, tiered pricing, requisition lists, and any bespoke frontend logic have to be rebuilt against the new frontend.
- The upgrade you may need first. Getting to a supported Magento patch level and PHP version.
- The build pipeline. Adding Node and Tailwind to your deployment process.
A store on a current patch level with few frontend extensions and a straightforward catalog is a genuinely contained project. A store several patches behind with thirty Luma-dependent modules and custom B2B flows is a different conversation, and any agency that quotes both the same way has not looked closely enough.
How Bemeir helps
Bemeir is a Brooklyn ecommerce agency and the USA’s first official Hyvä Gold Partner, with a direct line to the Hyvä team since the project began. Our Hyvä development services cover the whole path: the compatibility audit that tells you what a build will actually cost, the child theme or Hyvä UI implementation, extension adaptation, and the deployment pipeline the Tailwind build needs.
That work sits inside a broader Magento and Adobe Commerce development practice, so if the honest answer is that you need a platform upgrade before a frontend project, we will tell you that and sequence it properly. We also build on Shopify and Shopify Plus, Shopware, and BigCommerce, and the module and integration work behind a frontend rebuild draws on our ecommerce technology partner ecosystem.
You can read more about the team on the about Bemeir page, or start a Hyvä conversation from the Bemeir homepage.
Frequently asked questions
Is the Hyvä theme free now?
Yes. Since 10 November 2025 the Hyvä default theme is free and open source, dual-licensed under AFL 3.0 and OSL 3.0, with the supporting modules under OSL 3.0. It is available on GitHub and through free Composer keys. The commercial products around it, including Hyvä UI, Hyvä Checkout, Hyvä Commerce, and Hyvä Enterprise, remain paid licences.
What Magento and PHP versions does Hyvä require?
Hyvä requires Magento 2.4.4-p9, 2.4.5-p8, 2.4.6-p7, 2.4.7-p1 or higher, and PHP 8.1, 8.2, 8.3, or 8.4. PHP 7.4 is not supported. Development machines also need Node.js 20.0.0 or higher for the Tailwind compiler. Note that the requirement is specified at the patch level, so being on 2.4.6 generally is not sufficient.
Should I buy a ready-made Hyvä theme or build a custom one?
Buy ready-made if you are a small brand with modest design requirements and you want to launch quickly. Build custom if your storefront is a competitive asset, you have an established design system, or your catalog and B2B flows are specific. Ready-made themes ship code for use cases you do not have, which costs some performance and ties your upgrades to a vendor. A disciplined custom child theme usually upgrades more cleanly.
Does the free licence make a Hyvä migration cheap?
No, and this is the most common misconception since the relicensing. The licence was never the bulk of the cost. The work is extension compatibility, design and build, rebuilding custom and B2B frontend flows, and adding a Node and Tailwind step to your deployment pipeline. Removing the fee lowered the entry barrier; it did not change the project.
What is the difference between Hyvä Theme and Hyvä Commerce?
Hyvä Theme is the free, open-source frontend that replaces Luma. Hyvä Commerce is a commercial bundled suite for Magento Open Source that packages the theme together with other Hyvä products. Hyvä Enterprise is the equivalent bundle for Adobe Commerce. If you only need the frontend, you need the theme, not the suite.
