Self-Host Meilisearch on Kubernetes

Meilisearch gives you typo tolerant search behind an HTTP API, with relevance tuning that does not require learning a query DSL. Self-hosting it needs one pod, one volume, and a master key. This page covers the resource footprint, how indexes use memory, and how it compares to Typesense. Edka deploys it on a cluster in your own cloud account.

What Meilisearch Needs to Run

• A persistent volume. Indexes and the task queue live on disk. Losing the volume means reindexing from your source of truth.
• Memory proportional to your index. Meilisearch memory maps its index files. Search stays fast while the working set fits in RAM, which is why the default memory limit is higher than the CPU request would suggest.
• A master key. Every API route is authenticated. Edka generates a 32 character key and stores it as a Kubernetes Secret.

No external database. Meilisearch is self-contained.

Resource Requirements

Component	CPU request	Memory request	CPU limit	Memory limit
Meilisearch	250m	512Mi	1000m	2Gi
Metrics proxy	10m	32Mi	100m	64Mi

Storage starts at 10 GiB and is resizable later. The 2Gi memory limit is the setting to watch: raise it as your index grows, since indexing throughput degrades sharply once the working set no longer fits. A CPX21 node (3 vCPU, 4GB) handles a modest index. See the Hetzner instance types table.

Meilisearch vs Typesense

Both are typo tolerant search engines with a REST API and sub-100ms queries on modest hardware. The operational split:

	Meilisearch	Typesense
Clustering	Single node	1, 3, 5, or 7 nodes
Default memory limit	2Gi	512Mi
Default CPU request	250m	100m
API port	7700	8108

Meilisearch is the lighter thing to reason about: one pod, one volume, strong relevance defaults. Good when search is a feature of your app rather than its backbone.

Typesense clusters. If search going down takes your product with it, running three nodes with raft replication is the difference that matters, and it costs less memory per node.

What Edka Provisions

Edka installs Meilisearch from the official Helm chart:

• Production defaults. Deployed with MEILI_ENV=production and analytics disabled.
• Persistent storage. A hcloud-volumes PersistentVolume for indexes and task data, resizable later.
• Generated master key. A 32 character key stored as a Kubernetes Secret, protecting every API route from the start.
• Internal API endpoint. A ClusterIP service on port 7700, reachable in cluster at http://<release>.<namespace>.svc.cluster.local:7700.
• Metrics. An nginx proxy authenticates and exposes Meilisearch’s Prometheus metrics on port 9110, wired into the Edka dashboard.

Built in Observability

Edka surfaces Meilisearch health in the dashboard: request rate, p95 latency, database and used storage size, indexed document and index counts, and queued and failed tasks.

Configuration Options

• General. Target namespace, chart and image versions, and the generated master key.
• Storage. Volume size (minimum 10 GiB) and storage class.
• Resources. CPU and memory requests and limits for the Meilisearch pod and the metrics proxy.
• Placement. Pin Meilisearch to a node pool, with automatic tolerations for node pool taints.
• Access. Publish the API through an Envoy Gateway traffic class on your own hostname.

Deploy Meilisearch

1. Click “Deploy Meilisearch” below.
2. Choose your namespace, storage size, and resource limits.
3. Optionally expose the API through a Gateway hostname.
4. Deploy, then retrieve the generated master key from your cluster to authenticate API calls.
5. Create your first index and start adding documents.

Deploy Meilisearch