ElasticSuite: a Magento 2 search and merchandising layer on Elasticsearch

A search engine and merchandising layer for Magento 2

ElasticSuite is a merchandising and search engine for Magento 2 built on Elasticsearch, from the French agency Smile. The project page describes it as a merchandising suite for Magento which aims to provide out of the box a lot of features usually only available through other means, and the topic list names the areas it touches: search, autocomplete, facets, merchandising and the search engine itself.

For a store operator the appeal is control. Magento's own search is a thin layer over whichever Elasticsearch or OpenSearch version the platform expects, and the things a merchandiser actually wants, such as boosting a category during a promotion or controlling which attributes become facets, are limited by that layer. ElasticSuite sits in front and gives the store a place to express those rules.

The implementation is PHP, with the repository layout showing a conventional Magento module structure: src for the module code, Resources for assets and configuration, composer.json for the package definition, a doc directory for the documentation, phpstan.neon.dist for static analysis and .eslintrc and .eslintignore for the JavaScript it ships.

The licence is OSL-3.0, which is the Open Software Licence, and the licence file sits at the root as LICENCE.md.

The last push to the repository was on 2026-10-14, and the homepage is elasticsuite.io, which also carries the commercial pricing page for the paid support offering.

One ElasticSuite line per Magento release

The compatibility table is the most useful page in the repository, and it maps a Magento version range to an ElasticSuite version, an Elasticsearch range, an OpenSearch range and whether that line is actively maintained.

The short version: a store on Magento 2.4.6 or newer should use the 2.11.x line, or 2.12.x for Magento 2.4.9 and above, and a store on anything older than 2.4.6 should stay on 2.10.x. The install is a single Composer requirement, for example:

composer require smile/elasticsuite ~2.12.0

The table also shows how far back the supported matrix goes, with 2.1.x for Magento 2.0.x, 2.3.x for 2.1.x, 2.6.x for 2.2.x, 2.8.x for Magento below 2.3.5 and 2.9.x for 2.3.5 and above. Every one of those older rows is marked as not actively maintained.

The Elasticsearch and OpenSearch columns are the second half of the matrix, and they move with the Magento version rather than with the ElasticSuite version alone. Rows for Magento between 2.4.1 and 2.4.6 support Elasticsearch 6 and 7 with OpenSearch 1. The 2.10.x line from about 2.10.27 adds OpenSearch 2. The 2.11.x line moves to Elasticsearch 7 and 8 with OpenSearch 1 and 2, and from 2.11.13 also OpenSearch 3. The newest row, 2.12.x for Magento 2.4.9 and above, keeps that same search backend range.

The pattern is clear: the search backend you can run is determined by the Magento version you are on, and ElasticSuite's job is to make a supported combination available for each one.

Magento 2.4.6 is why there are two product lines

The project explains the split directly, and the reason is worth understanding because it changes your upgrade planning.

Due to several changes in Magento 2.4.6, especially the introduction of Elasticsearch 8 and OpenSearch 2, the maintainers cannot ensure compatibility between ElasticSuite older than 2.11 and Magento 2.4.6 or newer. So if your project is based on Magento 2.4.6 or newer you can start working with ElasticSuite using the latest 2.11.x release, and if your project is based on Magento below 2.4.6 the latest ElasticSuite release you can use is 2.10.x.

That is a real constraint rather than a marketing position. Magento 2.4.6 changed the search stack underneath the platform, so a suite that rewires search on top of the platform's engine has to be rebuilt against the new one. ElasticSuite responded by cutting a new branch, 2.11.x, and freezing 2.10.x as the maintained line for the older platform generation.

The practical consequence is that the ElasticSuite version is not a free choice. It is determined by your Magento version, and the mapping is published so you do not have to discover it by trial and error. If your store is on 2.4.6 or later and you upgrade the suite, you are also committing to the Elasticsearch 8 and OpenSearch 2 generation of search backends.

The release record shows what that means for maintenance effort. Three versions were published on the same day, 2026-10-05: 2.12.2.1, 2.11.21.1 and 2.10.36.1. The same change is being applied to three lines at once, which is the ongoing cost of supporting a platform generation that has moved on three times.

Headless front ends need their own compatibility module

If your store front end is not the standard Magento theme, the project does not assume you can just install the suite. Two compatibility modules are named.

For the Hyvä theme, ElasticSuite is compatible, and the project links the Hyvä blog article about the partnership. To use it you need to install their compatibility module, which lives in a GitLab repository under hyva-themes and is named magento2-smile-elasticsuite.

For the Breezefront themes, you need their module, which lives on GitHub as breezefront/module-breeze-smile-elasticsuite.

In both cases the front end vendor maintains the glue, not ElasticSuite. That is a sensible division: the front end knows how it renders search results and autocomplete, and ElasticSuite knows how Magento's search API works, and the module is where the two meet.

It does mean a dependency outside the ElasticSuite ecosystem, on a repository with its own release cycle, for a store using a headless theme. That is worth weighing before you commit, because a mismatch between the module version and the ElasticSuite version is a class of problem you cannot fix from inside the ElasticSuite repository.

The same pattern appears for Magento Commerce B2B. If you are using the B2B feature with ElasticSuite, you need the Elasticsuite Shared Catalog module and the Elasticsuite Quick Order module, both published by the same organisation in separate repositories.

What the additional modules add

The project publishes a set of further modules that are free and open source on GitHub, and the list is worth reading because it shows where the suite stops.

CMS Search allows searching for CMS pages, in autocomplete and in search results. Ratings allows filtering and sorting on ratings, based on the standard Magento rating module. Elasticsuite for Retailers is a suite of retail oriented modules including a Store Locator and price segmentation per store.

TargetRules with Elasticsearch is the one with a commercial dependency. It computes target rules via Elasticsearch instead of full MySQL, and the documentation marks it as requiring Magento Commerce, formerly known as Enterprise Edition.

That last item is a good example of the general shape of ElasticSuite's pricing and packaging. The core search suite is open source under OSL-3.0, the extension modules are free and open source, and the pieces that depend on the commercial Magento Commerce tier stay commercial.

There is also a community layer. The project lists add-ons distributed by users rather than by the maintainers, currently ComWrap ElasticsuiteBlog, a bridge that lets ElasticSuite index MageFan Blog posts and show them in the autocomplete and on the search results page.

For a store owner, this means the practical decision is not simply whether to use ElasticSuite but which combination of modules the business actually needs, and how many of them are supported by someone other than the maintainer.

Packaging, tooling and the shape of the codebase

The repository is a Magento module rather than an application, and the build and quality tooling is visible in the top level entries.

There is composer.json for the package definition, phpstan.neon.dist for static analysis configuration, .eslintrc and .eslintignore for the JavaScript that ships with the suite, .codeclimate.yml for the code quality service, and ISSUE_TEMPLATE.md so that bug reports arrive in a consistent shape.

The continuous integration badges at the top of the project page name two workflows, PHP Code Quality and Integration, which means the project is checked both for static analysis and for behaviour against a Magento instance. The Packagist badge shows the download count for the smile/elasticsuite package, and there is a PRs welcome badge.

The default branch is 2.11.x, which is worth noting against the compatibility table. The branch you land on by default is the 2.11 line, so a store on Magento 2.4.9 or newer has to move to the 2.12.x branch deliberately, and a store below 2.4.6 has to move away from the default branch to 2.10.x. The default branch choice reflects where the bulk of recent work is, not a recommendation for every installation.

Documentation lives in the doc directory in the repository, and the hosted site at elasticsuite.io carries the documentation, the news and the pricing information.

Editorial conclusion

ElasticSuite suits a Magento 2 store that needs search and merchandising features beyond the platform default, or a store on an older Magento release that wants to stay on Elasticsearch 6 or 7 rather than move to the Elasticsearch 8 and OpenSearch 2 stack that Magento 2.4.6 introduced. It is the wrong choice for a store on Magento 2.4.9 or newer that is content with the platform search layer, and it is the wrong choice if you cannot accept a suite that ties your search backend version to your Magento version. Verify three things before you install: which ElasticSuite line matches your exact Magento patch level, whether you need a theme compatibility module for a headless front end, and whether the merchandising features you want live in the core suite or in one of the additional modules.

Frequently asked questions

Official sources

1. License: OSL-3.0
2. Project website
3. README
4. Releases
5. Smile-SA/elasticsuite on GitHub