meilisearch-php is the official PHP client for the Meilisearch engine

A thin client that follows the HTTP API

Meilisearch PHP is the Meilisearch API client for PHP developers, and the tagline is that it is the Meilisearch API client written for PHP. Meilisearch itself is an open-source search engine, with its own repository and its own documentation.

What that framing tells you is the design philosophy. The SDK is a mapping of the HTTP API onto PHP, not an abstraction layer with its own ideas. The search method takes the same options the API documents, and the response objects carry the fields the API returns.

That is the right choice for a search client, because search is a domain where the API is the contract. Anyone who has read the Meilisearch API reference can read the PHP client and know exactly what the call does, and anyone who has used the client in another language will find the same method names.

The repository carries the standard signals for a client library. There is a Dockerfile, a docker-compose.yml for local development, a phpunit.xml.dist, a phpstan.dist.neon for static analysis, a .php-cs-fixer.dist.php for style, a .phpdoc directory, a .yamllint.yml, tests and scripts directories, and an AGENTS.md alongside a .cursor and a .agents directory. The licence is MIT, the homepage is meilisearch.com, and the topics are client, meilisearch, php and sdk.

The HTTP client is your decision, not the SDK's

The installation section makes one thing mandatory that is unusual for a client library: you must also install packages that provide the PSR interfaces.

The two are psr/http-client-implementation and psr/http-factory-implementation, and the README points to the providers list on Packagist and to php-http.org for a list of compatible HTTP clients and client adapters.

If you do not know which HTTP client to use, the recommendation is Guzzle 7, and the install is:

composer require meilisearch/meilisearch-php guzzlehttp/guzzle http-interop/http-factory-guzzle:^1.0

The alternative shown is the Symfony HTTP client:

composer require meilisearch/meilisearch-php symfony/http-client nyholm/psr7:^1.0

The practical effect is that the SDK does not drag a HTTP stack into your project, and the README has a table of contents section titled HTTP Client Compatibilities, with a Customize your HTTP Client subsection. For a project that already has Guzzle or Symfony HTTP in its dependencies, that is a feature. For a project with no HTTP client at all, it is one more decision to make before the first search works.

Adding documents and watching the task

The getting started section opens with adding documents, and the example uses a movies index.

<?php

require_once __DIR__ . '/vendor/autoload.php';

use Meilisearch\Client;

$client = new Client('http://127.0.0.1:7700', 'masterKey');

# An index is where the documents are stored.
$index = $client->index('movies');

$documents = [
    ['id' => 1,  'title' => 'Carol', 'genres' => ['Romance, Drama']],
    ['id' => 2,  'title' => 'Wonder Woman', 'genres' => ['Action, Adventure']],
    ['id' => 3,  'title' => 'Life of Pi', 'genres' => ['Adventure, Drama']],
    ['id' => 4,  'title' => 'Mad Max: Fury Road', 'genres' => ['Adventure, Science Fiction']],
    ['id' => 5,  'title' => 'Moana', 'genres' => ['Fantasy, Action']],
    ['id' => 6,  'title' => 'Philadelphia', 'genres' => ['Drama']],
];

# If the index 'movies' does not exist, Meilisearch creates it when you first add the documents.
$index->addDocuments($documents); // => { "uid": 0 }

Two details carry the design. The comment notes that the index is created automatically when you first add the documents, so there is no separate create step to forget. And addDocuments returns a task identifier rather than a result, because indexing is asynchronous on the server side.

The uid is the handle for that asynchronous work, and the README says you can use it to check the status of the documents addition, with the possible states being enqueued, canceled, processing, succeeded or failed, through the tasks endpoint of the API.

Typo tolerance is the engine's, and the client passes it through

The basic search example shows what Meilisearch is actually for:

// Meilisearch is typo-tolerant:
$hits = $index->search('wondre woman')->getHits();
print_r($hits);

The query is misspelled on purpose, and the returned hit is the Wonder Woman document. The output block in the README shows the structure the client returns, an array of associative arrays with the id, the title and the genres array.

The custom search example shows the same call with options:

$index->search(
    'phil',
    [
        'attributesToHighlight' => ['*'],
    ]
)->getRaw(); // Return in Array format

and the JSON output shows the fields you get back, hits with a _formatted block where the matched term is wrapped in em tags, plus offset, limit, processingTimeMs and the query itself. The getRaw call returns the array format, and getHits in the earlier example returns the hits.

One gotcha the README flags is the filterable attributes. If you want to enable filtering you must add your attributes to the filterableAttributes index setting, and you only need to perform that operation once:

Filters need a one time index setting

The filterable attributes call looks like this:

$index->updateFilterableAttributes([
  'id',
  'genres'
]);

The performance consequence is stated immediately afterwards. Meilisearch will rebuild your index whenever you update filterableAttributes, and depending on the size of your dataset that might take time, and the process can be tracked using the tasks endpoint.

That is a real operational detail for anyone indexing a large catalogue. Filterable attributes are not a per request setting, they are an index wide property, and changing them is a rebuild. A platform team that enables filtering on a new field during a launch has to plan for a reindex, not a configuration change.

It is also a reminder of where the client ends and the engine begins. The SDK sends the call and returns the response; the rebuild happens inside Meilisearch, and the client gives you the task identifier to follow it. The search parameters themselves are documented in the Meilisearch search parameters reference, and the README points at a wiki page for more about the search method.

Everything in the SDK is a thin pass through, which is exactly why the API reference is the place to look when something does not behave as you expect.

The 1.x line and the 2.0 beta at the same time

The release history shows two lines in flight. v1.17.0 was tagged on 2026-08-11, and the 2.0 line is progressing through betas, with v2.0.0-beta.7 on 2026-07-22 and v2.0.0-beta.8 on 2026-10-07. There are no GitHub releases for the 2.0 betas in that list, but the tags exist.

The README has a Compatibility with Meilisearch section in its table of contents, which is where a 2.0 user needs to look first, because a client major version usually tracks a server major version.

The last push was on 2026-10-15, and the repository is not archived, so the work is current even though the stable line has not moved since August.

The local development setup is a good indicator of how the project expects itself to be worked on. The compose file runs a package service built from the repository root with the source bind mounted at /home/package, pointed at a Meilisearch instance through MEILISEARCH_URL, and a meilisearch service using the enterprise image at v1.54 with the master key, analytics disabled and experimental allowed IP networks set to any. The Dockerfile is based on php:8.5 with git and unzip, a memory_limit of 512M written into a conf.d ini file, and Composer 2 copied in from the composer image.

Editorial conclusion

meilisearch-php suits a PHP team that has chosen Meilisearch as its search engine and wants an SDK that follows the API rather than wrapping it in a different abstraction, and the PSR-18 and PSR-17 requirements mean it fits whatever HTTP client the project already has. It is the wrong choice if you want a batteries included client, because the HTTP client is your decision to make, and it is a poor bet if you need a stable 2.0 API today, since the 2.0 line is still in beta. Before starting a migration, read the compatibility table in the README against your Meilisearch version and decide whether you take the 1.17 line or a beta.

Frequently asked questions

Official sources

1. License: MIT
2. meilisearch/meilisearch-php on GitHub
3. Project website
4. README
5. Releases