Meilisearch admin key security: a complete guide

The Meilisearch master key is the root credential for your search engine — it can read and write any index, create and revoke any API key, and trigger any administrative action. Treat it like a database root password: store it in a secret manager, never put it in client-side code, and rotate it the moment you suspect compromise.

The 30-second answer

• Master key — root credential, set once at server startup, used only for admin operations and key creation.
• Admin API keys — derived from the master key, scoped to specific actions and indexes, safe to use in trusted server-side code.
• Search-only API keys — also derived, scoped to search only, safe to ship to your frontend.
• Never ship the master key to a browser, mobile app, or any other client.

The Meilisearch key model

Meilisearch has three layers of credentials:

Layer 1: the master key (server-level)

Set at server startup via the MEILI_MASTER_KEY env var or --master-key flag. Once set, it cannot be changed without restarting the server. The master key is what you use to call POST /keys to create the keys you'll actually use day-to-day.

Layer 2: API keys (operation-level)

Created via the master key. Each API key has:

• A list of allowed actions (e.g. search, documents.add, indexes.create, or * for everything)
• A list of allowed indexes (e.g. movies, products, or *)
• An optional expiration date (ISO 8601 timestamp)
• A name and description for tracking

Layer 3: tenant tokens (request-level, since v1.0)

JWT-style signed tokens derived from a parent API key, with their own embedded scopes (e.g. "this user can only search documents where tenant_id = 42"). Generated by your application, no Meilisearch round-trip needed. Used for multi-tenant SaaS applications.

The minimum-scope rule

Every Meilisearch deployment should have at least three keys:

The master key doesn't need to be embedded in any application code at all. Use it once to provision the three keys above, store it in a secret manager, and then use the scoped keys for everything else.

How to rotate the master key

1. Generate a new master key: openssl rand -hex 32
2. Update MEILI_MASTER_KEY in your secret manager.
3. Restart Meilisearch. The new master key takes effect.
4. All existing API keys are invalidated. Meilisearch derives them from the master key, so changing the master invalidates everything.
5. Recreate every API key your application uses with the new master key.
6. Update each application's environment variable with the new key value.

This is a non-trivial operation. Plan it during a maintenance window. The good news is that it's fast — the entire rotation takes a few minutes if you've scripted the key recreation.

How to rotate a single API key (without touching the master)

1. Create a new key with the same scopes (different name).
2. Deploy the new key value to your application.
3. Wait until you're sure the old key is no longer used (check Meilisearch's logs for last_used_at on the old key).
4. Revoke the old key via DELETE /keys/{uid}.

This is the standard pattern for key rotation in any distributed system: provision new, drain old, revoke old.

What "compromised" looks like

You should rotate immediately if any of these happen:

• An admin or developer with access to the master key leaves the team
• The master key was committed to a public Git repo (even briefly — search history caches it)
• The master key appears in a log file you didn't expect
• Meilisearch shows API requests from an IP you don't recognise
• You see unexpected key creation or deletion activity in your task log

Storing the master key safely

Use a real secret manager. The acceptable options:

• HashiCorp Vault
• AWS Secrets Manager / Parameter Store
• GCP Secret Manager
• 1Password Secrets Automation
• Doppler / Infisical

Do NOT store the master key in plain text on the server filesystem, in a Slack message, in a wiki, or in your application's regular env file that gets read by every container.

FAQ

Can I have multiple master keys?

No — Meilisearch has exactly one master key per server, set at startup. If you need separate root credentials for separate environments, run separate Meilisearch instances.

What's the difference between an admin key and the master key?

The master key is set at server startup and is the root credential. An "admin" API key is one with all actions on all indexes — it can do everything the master key can do via the HTTP API, but it can be revoked, expired, and tracked. Admin API keys are the recommended pattern for any application that needs full Meilisearch access. The master key should only be used to provision other keys.

How long should API keys live?

For server-side keys (indexer, admin), no expiration is fine — rotate them annually as policy. For tenant tokens (frontend or per-user keys), set an expiration of hours to days, not years.

How does AdminDex store my master key?

Encrypted at rest with authenticated AES-256, decrypted only in-memory immediately before the outgoing HTTP call to your Meilisearch server, then discarded. Never logged, never visible in any UI after you save it, never sent back to your browser. See the full security explanation.