meilisearch-dotnet: the .NET client for Meilisearch, and what it asks of your data model
.NET client for Meilisearch
At a glance
- What is it?
- The official C# client wraps the Meilisearch HTTP API in async methods for indexes, documents, tasks and search. It is small, MIT-licensed and asynchronous by default, but it inherits every constraint of the server, including index rebuilds when you change filterable attributes.
- Who is it for?
- Adopt meilisearch-dotnet if you already run Meilisearch and want to call it from C# without hand-rolling HttpClient plumbing; the package targets .NET Standard 2.1 and the README covers documents, search, filters and task polling. Do not adopt it if you need a search engine embedded in the process, or if your index schema churns often, because changing FilterableAttributes rebuilds the index.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What meilisearch-dotnet actually is, and who it is for
This is not a search engine. It is an HTTP client. The README describes it plainly: "Meilisearch .NET is the Meilisearch API client for C# developers." The search engine itself is a separate project, Meilisearch, that you run as a server and reach over HTTP, by default on port 7700.
The package is for teams that already decided to run Meilisearch and are writing their application in C#. If you are on Node, Python or Go, the same project publishes clients for those; this repository is only the .NET one. The README states that it contains all the documentation you need to start using the SDK, and points to the main Meilisearch documentation site for API reference, tutorials and guides.
The repository carries the MIT licence, and its topics list includes vector and vector-database alongside dotnet and search, which matches where Meilisearch itself has been heading rather than anything specific to the C# wrapper. The README's own examples stay on classic full-text search.
How the client maps onto the Meilisearch API
The architecture is thin by design. MeilisearchClient is constructed with a host URL and a master key, and from it you obtain an index handle. Indexes are addressed by name, and the README notes that if an index does not exist, Meilisearch creates it when you first add documents.
The important structural fact is asynchrony plus task indirection. Writes do not complete when the method returns. AddDocumentsAsync returns a TaskInfo carrying a uid, and the README says you can use that uid to check the status of your document addition, which it lists as enqueued, canceled, processing, succeeded or failed. That means every write path in your application needs a place to observe task completion. The README links to the tasks endpoint rather than providing a polling helper, so the retry and wait logic is yours to write.
Search is the part that returns data directly. SearchAsync returns a SearchResult of your document type, with Hits, offset, limit, processingTimeMs and query fields visible in the sample JSON output. Results are deserialised into whatever class you supply, so your document model and your index schema have to agree.
Installing the package and running a first search
The package targets .NET Standard 2.1, which the README states directly. From the .NET CLI you add it with the package id MeiliSearch, which is not spelled the same as the repository name:
dotnet add package MeiliSearchThe README also gives the Package Manager Console form, Install-Package MeiliSearch, for Visual Studio users.
You still need a running Meilisearch instance. The README offers two routes: Meilisearch Cloud, or self-hosting by downloading and deploying the engine on your own infrastructure. The repository's docker-compose.yml shows the shape of a local setup, with a meilisearch service on port 7700 and MEILI_MASTER_KEY set to masterKey, and MEILI_NO_ANALYTICS set to true. That compose file also defines an nginx service and a second Meilisearch instance behind it, which is test scaffolding for proxied requests rather than a recommended deployment.
With a server listening on http://localhost:7700, the README's getting-started example builds a client, grabs an index and adds documents:
MeilisearchClient client = new MeilisearchClient("http://localhost:7700", "masterKey");
var index = client.Index("movies");
var task = await index.AddDocumentsAsync<Movie>(documents);The returned task uid is what you poll. Then a search, using the README's deliberately misspelled query to demonstrate tolerance:
SearchResult<Movie> movies = await index.SearchAsync<Movie>("philadalphia");
foreach (var prop in movies.Hits) {
Console.WriteLine(prop.Title);
}The README's JSON output for that call shows a single hit, Philadelphia, with offset 0, limit 20 and processingTimeMs 10. Search options go through a SearchQuery object; the README's highlighting example sets AttributesToHighlight to a string array containing "title" and shows the matched fragment wrapped in em tags inside a _formatted object.
Filterable attributes and the index rebuild cost
This is the sharpest operational constraint in the README, and it is easy to miss. To filter, you must first declare which attributes are filterable:
TaskInfo task = await index.UpdateFilterableAttributesAsync(
new string[] { "id", "genres" }
);The README says you only need to perform this operation once, and then adds the caveat that matters: Meilisearch will rebuild your index whenever you update FilterableAttributes, and depending on the size of your dataset this might take time. You track it through the task status.
So the setting is not a lightweight toggle. It is a schema decision with a rebuild attached. If your filterable fields change per tenant, per customer or per release, you are scheduling index rebuilds, not editing a config value. Teams used to adding a database index in a migration will find the cost model unfamiliar. The README does not describe an online migration path or a way to avoid the rebuild, so plan for it rather than discovering it in production.
Where the client ends and your application begins
The README is honest about scope in one place and silent in others. It states that it contains all the documentation you need to start using the SDK, which is true for getting started and less true for operating the thing.
Three gaps stand out. First, task polling: the README explains the statuses and links to the tasks reference, but does not show a wait loop, a backoff strategy or a helper. Second, error handling: the README does not document how API failures surface in the client, so you cannot tell from it whether a rejected request throws a specific exception type or returns a failed task. Third, rollback and index versioning: the README does not document rollback, and nothing in the repository describes reverting a settings change or swapping an index atomically.
The custom HTTP client section is the escape hatch. The table of contents lists "Use a Custom HTTP Client", which matters if you need a proxy, custom handlers or a specific transport configuration. The repository also ships an nginx.conf and a second Meilisearch container in docker-compose.yml, which suggests proxied and load-balanced setups are exercised by the test suite even though the README does not walk through them.
When a hosted search service is the better fit
The real alternative is not another .NET client. It is a hosted search service such as Algolia, or a database you already run.
The difference in approach is who operates the engine. With meilisearch-dotnet you run a Meilisearch process, keep it reachable on a port, manage its master key, and watch task queues and index rebuilds yourself. Meilisearch Cloud, which the README links from the header and from the self-hosting section, removes that operational layer while keeping the same API, which means the same client code. The README frames the choice directly: launch, scale and streamline in minutes with the cloud option, or download and deploy the open-source engine on your own infrastructure.
A database full-text index is the other comparison point, and it inverts the trade-off. You keep one system and one backup story, but you give up typo tolerance, the task model and Meilisearch's ranking behaviour. The README's own example, searching "philadalphia" and getting Philadelphia, is the clearest statement of what you would be giving up. If your users never misspell anything and your corpus is small, a database index is less machinery.
Version pairing, maintenance and licence
The last push to this repository was on 2026-09-01, and the most recent release listed is v0.20.0 from 2026-06-23, preceded by v0.19.0 on 2026-06-22 and v0.18.0 on 2025-12-09. The gap between v0.18.0 in December and two releases in June is worth noting if you pin versions: the cadence is not uniform. The repository is not archived.
The README has a compatibility section titled "Compatibility with Meilisearch", but the excerpt available here does not include its contents, so the exact server-version matrix cannot be confirmed from the README. Treat that as the first thing to read in full before upgrading either side. A client that speaks a newer API than your server will fail at runtime, not at compile time, because the calls are HTTP.
The licence is MIT, stated in the README badge and in the repository's LICENSE file. That is permissive and imposes no copyleft obligation on your application. It says nothing about the licence of the Meilisearch server itself, which is a separate project, and the docker-compose.yml here pulls an image tagged meilisearch-enterprise, so check the server's terms separately if you self-host. Upgrade cost is mostly the client package plus whatever server version it expects; the rebuild cost described above is the part that does not disappear with a version bump.
Editorial conclusion
Adopt meilisearch-dotnet if you already run Meilisearch and want to call it from C# without hand-rolling HttpClient plumbing; the package targets .NET Standard 2.1 and the README covers documents, search, filters and task polling. Do not adopt it if you need a search engine embedded in the process, or if your index schema churns often, because changing FilterableAttributes rebuilds the index. Before committing, verify the package version against your Meilisearch server version, and confirm how you will poll task status after AddDocumentsAsync, since the README only points at the task endpoint rather than showing a polling loop.
Frequently asked questions
What NuGet package do I install for meilisearch-dotnet?
The package id is MeiliSearch, which differs from the repository name meilisearch-dotnet. The README gives both dotnet add package MeiliSearch and Install-Package MeiliSearch, and states that the package targets .NET Standard 2.1.
Do I need to run a Meilisearch server to use meilisearch-dotnet?
Yes. The client is an HTTP wrapper, and the README's example connects to http://localhost:7700 with a master key. The README offers two ways to get a server: Meilisearch Cloud, or downloading and deploying the open-source engine on your own infrastructure.
Why does changing FilterableAttributes take so long in meilisearch-dotnet?
The README states that Meilisearch will rebuild your index whenever you update FilterableAttributes, and that depending on the size of your dataset this might take time. It says you only need to perform the operation once, and that you can track the process using the task status.
Community notes