How to manage Meilisearch in production without writing curl scripts

Most teams running self-hosted Meilisearch end up with a folder of bash scripts, half-remembered API endpoints, and one engineer who knows how the settings file works. This guide walks through the four operational tasks that actually need to be solved — and how to solve them without writing more curl by hand.

The four jobs you actually need to do

1. Edit index settings when relevance, ranking, or attribute configuration needs to change.
2. Manage API keys when you onboard a new app, rotate a compromised key, or scope a search-only key for your frontend.
3. Watch tasks complete when you trigger a settings update, document import, or key change.
4. Read search analytics when you want to know what your users are searching for and what's failing.

That's it. Everything else (instance creation, document CRUD, dumps) is occasional. These four are the recurring work.

Job 1: editing index settings

The curl-script approach

Editing settings via the HTTP API means a PATCH to /indexes/{uid}/settings with a JSON body. The body has 13 fields, half of which accept arrays of attribute names you have to remember exactly. Most teams keep a settings.json file in a Git repo and POST it from CI.

This works for stable settings. It breaks down when you want to experiment — every change is a Git commit, a CI run, and a wait for reindexing to complete.

The dashboard approach

Use a visual editor with attribute pickers that pull live field names from your index. No JSON typing, no field-name-from-memory bugs, immediate reindex. This is what AdminDex's settings editor exists for.

Job 2: managing API keys

The curl-script approach

Creating a Meilisearch API key is a POST to /keys with a JSON body specifying actions, indexes, and an expiration date. Revoking is a DELETE on /keys/{uid}. The full key value is returned only once at creation time — if you forget to copy it, you have to revoke and recreate.

This is fine for one or two keys. With ten keys across multiple indexes and multiple environments, you start needing a tracking spreadsheet, which is where things get fragile.

The dashboard approach

A visual key manager with the actions and indexes pre-populated, the full key shown clearly at create time, and a one-click revoke button. See our help article on creating and revoking API keys for the recommended scoping patterns.

Job 3: watching tasks

The curl-script approach

Meilisearch's writes are async — POST to /indexes/{uid}/documents returns a task envelope with a taskUid. You then poll GET /tasks/{taskUid} until the status flips from enqueued to processing to succeeded or failed.

Writing this loop in bash is unpleasant. Most teams paste a snippet, lose it, rewrite it, and never see failed tasks until a user complains.

The dashboard approach

A live-polling task viewer that auto-refreshes every two seconds and surfaces failed tasks with a red badge and the full error message. The single most useful operational signal Meilisearch offers, made visible by default.

Job 4: reading search analytics

The curl-script approach

Meilisearch doesn't ship a built-in analytics endpoint for production query traffic. To get analytics you have to either log every search request from your application code (and aggregate the logs yourself) or proxy traffic through a service that captures it.

The dashboard approach

Capture searches via a proxy that logs query, latency, hit count, and zero-result rate, then aggregate them into a daily dashboard. This is non-trivial to build from scratch — see our guide on reading Meilisearch search analytics for what to actually look for once you have the data.

The pattern

Every operational task that recurs more than once a week is a task that should have a UI. Curl works for the first time you do something. By the third time, the cost of typing endpoints from memory exceeds the cost of standing up a dashboard.

The curl scripts don't go away, by the way — every operation you'd run from a dashboard should still show you the equivalent curl command, so you can copy it, debug it, or run it from CI when you need to. AdminDex renders a copy-able curl block next to every form.

FAQ

Can I just use the Meilisearch CLI?

There is no first-party CLI in 2026. Several community tools exist but none are widely adopted. The HTTP API is the canonical interface.

Do I need a dashboard if I only have one index?

Not strictly. A single-index project with no team and no recurring settings changes can be managed from curl forever. The dashboard becomes valuable when you have multiple indexes, multiple environments, multiple teammates, or settings you want to experiment with.

What about the Meilisearch documentation's example curl commands?

They're great for learning. They're not great for daily operations. The docs assume you'll write your own tooling on top — which is exactly the gap this article (and the dashboard pattern) addresses.

Can I use AdminDex against Meilisearch Cloud?

Yes. AdminDex is just a dashboard — it doesn't care whether the Meilisearch instance is self-hosted or running on Meilisearch Cloud. Point it at any Meilisearch URL with a valid admin key.