Self-Hosted Search: Meilisearch or Typesense on a VPS in 2026
Last updated: July 2026
Algolia bills by request and record volume, while Elastic Cloud's managed pricing scales with the compute and storage your index needs — either way, the bill grows with exactly the metrics a growing product can't control: search traffic and catalog depth. Self-hosting Meilisearch or Typesense on a VPS removes the per-request meter entirely, but it shifts the responsibility for capacity planning onto your team. This guide covers meilisearch typesense vps hosting from the angle that actually matters for dev teams: how much RAM the in-memory index needs, why NVMe decides your reindex speed, and when a VPS stops being enough.
Why dev teams are dropping per-request search pricing
Managed search-as-a-service pricing is built around API calls and record counts, which means your search cost grows in lockstep with your product's success. A catalog that doubles in size, or a traffic spike from a marketing push, shows up directly on the next invoice. Meilisearch and Typesense are open-source, self-hostable alternatives that deliver comparable relevance and fast query latency without a metered API in front of them. Once they're running on your own infrastructure, the only variable cost is the VPS itself — and that's a number you control.
Sizing your VPS: the index lives in RAM, not just on disk
The single most common mistake teams make when self-hosting search is sizing the server like a database instead of a search engine. Both Meilisearch and Typesense keep their index structures in memory to serve fast queries, so your RAM budget needs headroom above the raw size of your dataset — not just enough to store it on disk. A dataset that's a few hundred MB on disk can require several times that in RAM once tokenized, indexed, and cached for query performance. Undersizing RAM doesn't just slow things down; it can push the process into swapping or trigger out-of-memory kills during reindexing, which is the worst possible time for search to go down.
A practical rule: estimate your on-disk document size, then plan for a VPS tier with meaningfully more RAM than that figure, with vCPU scaled to your indexing and concurrent query load. For a deeper walkthrough of matching workloads to server specs, see the self-hosting VPS use case guide.
Meilisearch vs Typesense VPS sizing: what changes the decision
Both engines are Rust/C++-based, single-binary, and easy to run on a plain KVM VPS with full root access — neither requires a managed platform. The practical sizing differences come down to your workload shape rather than raw specs:
- Document volume and field count — more searchable fields and larger documents increase memory per record for both engines.
- Filtering and faceting depth — heavy faceted search (common in e-commerce catalogs) adds indexing overhead that benefits from extra vCPU during rebuilds.
- Write frequency — catalogs with frequent updates put more sustained load on CPU and I/O than mostly-static datasets that reindex rarely.
- Multi-tenant or multi-index setups — running several isolated indexes on one instance multiplies the RAM headroom you need, since each index carries its own in-memory structures.
Neither engine changes the fundamentals of VPS sizing — RAM for the resident index, vCPU for indexing throughput, and fast storage for the disk-backed portions. The decision is less "which engine needs more" and more "how does your catalog and query pattern map to available RAM tiers."
Matching catalog size to a VPS tier
Because index memory scales with searchable content rather than raw file size, it helps to think in tiers rather than exact numbers. The table below maps X-ZoneServers' KVM VPS lineup to typical self-hosted search profiles:
| Tier | Specs | Typical fit |
|---|---|---|
| Nano | 2GB / 1 vCPU / 40GB, €4/mo | Dev/staging index, small proof of concept |
| Micro | 4GB / 2 vCPU / 80GB, €6/mo | Small production catalog, low query volume |
| Starter | 8GB / 2 vCPU / 120GB, €10/mo | Growing SaaS product search, moderate faceting |
| Basic | 16GB / 4 vCPU / 160GB, €16/mo | Multi-index setups, active write traffic |
| Pro | 24GB / 6 vCPU / 200GB, €30/mo | Large catalog, heavy faceted search |
| Business | 32GB / 8 vCPU / 300GB, €58/mo | High-traffic search behind a busy storefront or app |
All six tiers run on NVMe SSD storage with unmetered 1 Gbps bandwidth and full root KVM access, so upgrading tiers as your catalog grows is a resize, not a migration. Full specs are on the VPS hosting page.
NVMe: the real differentiator for reindex speed
Query latency gets most of the attention in search engine benchmarks, but reindex speed is where storage choice shows up hardest in production. Every document update, bulk import, or schema change triggers a rebuild that reads from and writes to disk — and on spinning or throttled storage, that rebuild can stall live queries or take long enough to become a deployment risk. NVMe storage removes that bottleneck by delivering far higher IOPS and lower latency than SATA SSD or HDD, which matters most exactly when you're reindexing a large catalog under load. Every X-ZoneServers VPS tier ships on NVMe, so reindex time scales with your engine configuration and dataset — not with a storage tier you have to remember to upgrade. For the underlying comparison, see NVMe vs SSD vs HDD hosting.
Deploying Meilisearch or Typesense with Docker
Both engines publish official Docker images, and full root access on a KVM VPS means Docker runs natively with no platform restrictions to work around. A typical setup pulls the engine image, mounts a persistent volume on the NVMe-backed disk for index data, and exposes the API behind your own reverse proxy and auth layer — giving you full control over network exposure that a managed SaaS doesn't offer. Because the VPS is unmetered on bandwidth, indexing large imports or serving high query volume doesn't introduce a second, separate cost on top of the server itself. For container-specific configuration guidance, see the Docker VPS use case guide.
When a VPS stops being enough
Single-VPS self-hosting has a ceiling. Once a catalog grows large enough that the in-memory index no longer fits comfortably even at the top VPS tier — or once query concurrency demands more sustained CPU than a shared-tenancy VPS can guarantee — it's time to move the workload to dedicated hardware. A dedicated server hands you the full RAM and CPU allocation with no neighbor contention, which matters for search engines that keep their entire working index resident in memory. It's also the right move if you're running Meilisearch or Typesense alongside other memory-hungry services on the same box. Specs and configurations are on the dedicated server page.
Verdict
For teams paying per-request pricing to Algolia or Elastic Cloud, self-hosting Meilisearch or Typesense on a VPS is a straightforward way to convert a variable, usage-scaled cost into a fixed one — provided the server is sized around RAM headroom for the in-memory index, not just disk usage. NVMe storage is the detail that separates a search deployment that reindexes smoothly from one that stalls under load, and it's standard across every tier. X-ZoneServers runs all six KVM VPS tiers on NVMe with unmetered 1 Gbps bandwidth and full root Docker access, with a clear upgrade path to dedicated hardware once a catalog outgrows shared-tenancy limits.