Self-Host Typesense on Kubernetes

Typesense is a typo tolerant search engine that clusters. Unlike most search tools in its weight class, it replicates across nodes with raft, so a node failure does not take search down. Self-hosting it needs a volume per node and an admin API key. This page covers clustering, resources, and how it compares to Meilisearch. Edka deploys it on a cluster in your own cloud account.

What Typesense Needs to Run

• A persistent volume per node. Each node keeps its own copy of the data.
• An odd node count when clustering, so raft has a quorum. Edka offers 1, 3, 5, or 7.
• An admin API key. Edka generates a 48 character bootstrap key and stores it in a Kubernetes Secret.

No external database. Typesense holds its own state.

Resource Requirements

Setting	CPU	Memory
Request	100m	256Mi
Limit	1000m	512Mi

Per pod, so a three node cluster requests 300m CPU and 768Mi memory. Storage starts at 10 GiB per node and is adjustable after deployment.

Typesense holds indexes in memory, so the 512Mi limit is the number to raise as your collections grow. A single node fits comfortably on a CPX21 (3 vCPU, 4GB) alongside other workloads. See the Hetzner instance types table.

Single Node or Cluster

A single node is the right default for most applications. Move to three when search is on the critical path:

• 1 node. Lowest cost. A pod restart means a brief search outage while it comes back.
• 3 nodes. Raft replication with quorum. Survives losing one node. This is the smallest configuration that stays up during a rolling node pool upgrade.
• 5 or 7 nodes. For read throughput beyond what three can serve.

Typesense vs Meilisearch

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

Both deliver typo tolerant search in single digit milliseconds on small datasets. Pick Typesense when search must survive a node failure, or when you want a smaller per-pod footprint. Pick Meilisearch when one pod is enough and you prefer its relevance defaults and tuning model.

What Edka Provisions

Edka installs the Edka Typesense Helm chart:

• Single or multi-node clusters. Choose 1, 3, 5, or 7 nodes. Use 3 or more for high availability.
• Bootstrap admin API key. A 48 character key generated and stored in a Kubernetes Secret.
• Persistent storage. Data volumes backed by your storage class (defaults to hcloud-volumes), sized from 10 GiB and adjustable after deployment.
• Internal service endpoint. Typesense on port 8108 at a stable in-cluster address.
• Optional external access. Publish the API through an Envoy Gateway traffic class on a hostname of your choice.

Configuration Options

• CORS. Let browser apps call Typesense directly and whitelist specific origins.
• Search analytics. Persist aggregated query analytics on the volume, with configurable flush interval and rate limits.
• Query cache. Control how many query results Typesense caches (default 1000 entries).
• Indexing concurrency. Cap batch indexing concurrency, or let Typesense decide.
• Write guardrails. Reject writes when memory or disk usage exceeds a chosen percentage.
• Result limits. Snapshot interval, max results per page, and max group limit.
• Resources and placement. CPU and memory requests and limits per pod, and node pool pinning with optional taint tolerations.
• Auto-updates. Automatic chart and image updates with a patch, minor, major, custom, or all version policy on a schedule you choose.

Deploy Typesense

1. Click “Deploy Typesense” below.
2. Pick your node count and Typesense image tag.
3. Set storage size and storage class.
4. Adjust configuration, resources, and access, then deploy.
5. Connect your application to the in-cluster endpoint on port 8108 using the generated admin API key.

Deploy Typesense