How to use this site search requirements checklist
A team comparing self-hosted site search options needs a way to test each requirement instead of debating it in meetings. This checklist turns every requirement into a verifiable test: a question with a stated pass condition and a named piece of evidence. The checklist is organized in five groups: functional, security, integration, operations and compliance. Within each group, score every requirement as must-have, should-have or not needed, and record the evidence behind each score before comparing platforms.
Expect the same requirement to have different answers per engine. Meilisearch's Community Edition is MIT licensed, but its Enterprise Edition is governed by a commercial license or the Business Source License 1.1 and is not permitted in production without a commercial agreement. Typesense is GPL-3.0 on the server and Apache on its clients, and OpenSearch is Apache 2.0 with no paid edition described in its FAQ. Clustering, access control and multi-tenancy also differ, so a feature that is free on one platform may sit behind a paid edition on another. Scoring a requirement without checking the edition and license in writing is the most common way a comparison goes wrong.
Use the evidence column as the basis for a vendor or partner conversation. For licensing, ask for the license text and any edition restrictions that apply to your production use. For clustering and access control, ask for the configuration you would deploy and the test results from a cluster of the size you need, and confirm the version you would run, since release lines are maintained for limited periods. Mark any item you cannot verify as open, not as a pass, and treat open items as a scoping risk to resolve before the fixed-scope agreement is written.
Functional must-haves for site search and how to verify them
This table lists the functional requirements a site search build must meet, why each one matters for visitors and content owners, and a test you can run on a staging index before choosing an engine. Read each row as a pass or fail check that you run against your own content, not as a vendor claim.
| Requirement | Why it matters for the site | Verification step |
|---|---|---|
| Typo tolerance | Visitors misspell product, program and policy names, and a zero-result page ends the session. | Run a set of 50 misspelled queries from your search logs against staging and count how many return the intended page in the top results. Meilisearch's README lists typo tolerance; confirm the same behavior on Typesense and OpenSearch with your own analyzers. |
| Filtering and faceting | Users narrow results by category, date, region or audience, and facet counts must match what they can click. | Define filterable and facetable attributes, then compare facet counts against a database query for three sample categories. Confirm which attributes must be declared up front on each engine. |
| Synonyms and ranking rules | Internal jargon, abbreviations and brand terms need to map to the words visitors actually type. | Load a synonym list and a ranking rule set, then run paired queries with and without them. Confirm how each engine stores synonyms and whether Algolia-style query rules need conversion, as Typesense's migration guide describes for its Overrides API. |
| Multilingual analysis | Sites published in several languages need stemming, accent folding and language-specific tokenization. | Index a sample page in each language and query with inflected forms, accents and mixed-language terms. Confirm language support and tokenizer options with the vendor for each language you publish. |
| Hybrid keyword and semantic results | Semantic matching helps with natural-language questions, but only if it measurably improves top results. | Build a judged query set of 100 queries with expected answers, then compare keyword-only and hybrid ranking. Meilisearch's README lists hybrid search; Typesense lists vector search. Confirm embedding sources and memory cost before enabling it. |
| Per-site or multi-tenant indexes | A group of sites or departments may need separate indexes, separate permissions or separate result scopes. | Create two test tenants with overlapping content and confirm a query in one never returns records from the other, using scoped keys or separate indexes. Meilisearch's README describes multi-tenancy; confirm how isolation is enforced on your chosen version. |
| Feature parity with a hosted engine | Migration from a hosted engine such as Algolia may lose features your front end depends on. | Inventory every Algolia feature in use, such as A/B testing, personalization and event tracking, and mark each as supported, converted or replaced. Typesense's guide states about 85% feature parity and lists server-side A/B testing, built-in event tracking and personalization as missing; Meilisearch's guide lists parameters with no equivalent. |
| Index update latency | Content editors expect new or changed pages to appear in results within a set time after publishing. | Publish 20 test documents through your normal pipeline, time how long each takes to appear in results, and record the worst case. Confirm each engine's indexing and task-queue behavior with the vendor under your expected write volume. |
| Bulk migration of existing records | A full reindex must finish within your maintenance window and keep the old index live until cutover. | Export a full copy of records, import into a new index under a new name, and compare document counts and sample field values. Meilisearch's Algolia guide describes batch imports; Typesense's guide describes JSONL export and upsert import. Confirm batch limits for your record size. |
Which license and edition terms decide what you can run in production
The license of the engine, and of any enterprise edition attached to it, decides whether clustering, single sign-on or replication are available to you without a commercial agreement. Read these terms before you compare features, because a capability that appears in a product comparison may sit behind a paid edition. For Meilisearch, the Community Edition is fully open source under the MIT license, while the Enterprise Edition is governed by a commercial license or the Business Source License 1.1 and is not permitted in production without a commercial agreement. If your checklist includes SSO SAML, high availability or replication, check which edition provides each one and whether production use of that edition requires a signed agreement.
Typesense takes a different path. The server is licensed under GPL-3.0 while its client libraries use the Apache license. The project explains that the GPL lets companies run modified server code internally without publishing changes, as long as they do not distribute it. That internal-use point matters for most site search deployments, but it changes if you ship the server inside a product, appliance or package for customers. Ask counsel whether your deployment and distribution model triggers source obligations, and confirm whether your planned Raft cluster and any vendor tooling fall under the same terms.
OpenSearch is released entirely under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition. That simplifies the license review, but it does not settle the question. Confirm in writing with your vendor or implementation partner which security, alerting or cluster features are bundled, and which come from third-party plugins with their own terms. For all three engines, request a written statement of the license terms that apply to your exact deployment model, including internal use, hosting by a partner, and any distribution to customers or affiliates, and file it with your procurement records before go-live.
Which security controls a site search deployment must prove
A site search engine holds a copy of your content and often your query logs, so it inherits the access and privacy obligations of the systems it indexes. The cards below list the controls an auditor or security reviewer will ask you to demonstrate, and what to confirm for each engine before you choose one.
Authentication integration
Decide whether administrators and any user-facing search administration sign in through your identity provider or through local accounts kept by the engine. OpenSearch supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token backends through its Security plugin, so it can fit most enterprise directories. For Typesense and Meilisearch, confirm which identity options exist in your edition and whether they are covered by your support terms, because access to the admin plane is often managed outside the engine.
Role and document-level access
Search results must respect who is allowed to see which records, not only who can query the index. OpenSearch provides role-based access control, document-level and field-level security, and field masking, so restricted fields can be hidden from some roles without a separate index. For Typesense and Meilisearch, ask the vendor whether the engine enforces these rules natively or whether your application must filter results before they reach the user, and test that filtering with real user roles.
Transport encryption
Every hop that carries queries, documents and credentials should use TLS: browser to front end, application to engine, node to node in a cluster, and engine to backups. OpenSearch documents TLS for node and client traffic in its Security plugin, which you should enable and verify with your own certificate chain. For Typesense and Meilisearch, record how TLS is terminated, who issues and rotates certificates, and whether internal cluster traffic is encrypted in the configuration you plan to run.
Secrets and API key scoping
Search engines issue keys that let front ends query and, in some designs, let back ends write or delete documents. Keep write and admin keys out of browser code, rotate them on a schedule you define, and use scoped search-only keys where the engine supports them. Typesense and Meilisearch both rely on API keys, so confirm which key types exist, whether keys can be restricted to specific indexes or filters, and how revocation takes effect. Store keys in your secrets manager, not in configuration files in source control.
Audit logging
An auditor will want to see who changed index settings, who used administrative functions and when data was exported or deleted. OpenSearch includes audit logs in its Security plugin, which you should configure to record authentication events and administrative actions, then forward to your central log store. For other engines, confirm what is logged natively, how long logs are kept, and whether query logs contain personal data that your retention rules must cover.
Hardening the admin API
The administrative API is the most powerful surface in a search deployment, because it can create, drop and reindex indexes. Restrict it to a private network or management subnet, disable or limit anonymous access, and keep the engine on a supported release line. OpenSearch documents that versions receive security patches during maintenance, so schedule upgrades against its release cadence. Confirm the same for your chosen engine and record which version is running in each environment so you can show the patch history.
Where the index and query logs must live
The first residency decision is where the index itself runs, and the checklist should name it in one of four forms: a cloud account you control, a data center you operate, an EU-only region, or an air-gapped network with no outbound path. Each form changes who can reach the search nodes, where backups land and how updates arrive. Self-hosting moves all of these decisions to the operator, so nothing about location is settled by a vendor's default. Record the chosen location for each environment, including staging and disaster recovery copies, since a restored snapshot in another region is still a copy of the data.
Treat three data sets separately, because each can contain personal data even when the product catalog does not. Indexed content may include author names, customer reviews, member profiles or internal documents. Query logs record what people typed, often with account identifiers or IP addresses attached. Click data links a person to the results they chose. For each one, the checklist should record where it is stored, how long it is kept, who can read it and which backups hold it, and it should confirm the retention period with your privacy team instead of assuming a default. Ask whether the chosen engine or your application writes query logs by default, and whether those logs can be turned off or truncated.
Memory is a residency-adjacent item because it decides whether a chosen location can run the workload at all. For Typesense, the supplied system requirements guidance says keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, each vector needs 7 bytes per dimension, and built-in ML models need roughly 2 to 6 GB of extra RAM. Confirm these figures against the Typesense system requirements guide for your version, and check that the sizing fits inside the approved hosting boundary before the location is signed off.
How to set retention for queries, logs and indexed personal data
Site search touches personal data in three places: the queries people type, the logs and analytics built from them, and the records the index holds from source content. Each needs its own retention period and deletion procedure, written into your policy before you compare engines.
Query log retention
Search logs often reveal user intent and can identify individuals, especially when people type names, account numbers or health terms. Decide how long raw queries are kept, who can read them and whether IP addresses or session identifiers are stored alongside them. Confirm whether each engine logs queries by default, whether that logging is built in or needs a separate component, and how to turn it off or shorten it. Document the answer for each candidate.
Analytics on searches
Search analytics such as top queries, zero-result queries and click-through rates are often the main reason to keep logs at all. Decide whether analytics should store aggregated counts only or per-session data, and whether any query text is masked or truncated before it is stored. Ask each vendor or your partner whether analytics events are part of the engine or come from an external tool, because that changes where the data sits and who must be covered by your retention schedule.
Deletion from the index
When a page, product or record is removed from the source system, the copy in the search index must also disappear within a timeframe your policy sets. Map each indexed field back to its source, define the trigger for deletion and test it on a sample. Confirm how each engine handles document deletion by ID, bulk deletes and re-indexing after a source purge, and whether deleted content can still appear in cached results or snippets.
Backup retention
Snapshots and backups can keep deleted personal data for as long as they exist, which can undercut an index deletion. Set a backup retention period that matches your deletion commitments and decide how restored indexes are scrubbed of records deleted after the snapshot was taken. Confirm how each engine creates snapshots, whether incremental backups keep old documents, and who holds encryption keys for backup copies. Record the answers in the same policy as the other three cards.
Which integrations a site search build depends on
Before comparing Meilisearch, Typesense or OpenSearch, list every source system that feeds the index and the sync method each one uses. Typical sources include the CMS, the commerce catalog, help content, and any application database that holds pages or records. For each source, record whether it pushes changes through a webhook or event, whether it can only be exported in batches, and how deletions and unpublished items are signaled. A deleted or unpublished item that stays searchable is the most common integration defect, and it is easy to miss when only the create and update paths are tested. The engine choice matters less than whether the indexing pipeline can handle each source's change pattern without manual reindexing.
Front-end compatibility is the second check. Teams that already run Algolia InstantSearch widgets should confirm which adapter their chosen engine needs. Meilisearch documents an Algolia export that uses the browseObjects method and an import with addDocumentsInBatches in batches of 100,000, and it maps attributesForFaceting to filterableAttributes and sort replicas to sortableAttributes. Its guide states that aroundPrecision, restrictHighlightAndSnippetArrays and disablePrefixOnAttributes have no equivalent, and that InstantSearch front ends need the Instant Meilisearch adapter. Typesense exports records as JSONL with the Algolia CLI, maps objectID to an id field, imports with the documents import endpoint using action=upsert, and converts query rules for the Overrides API. Its guide says the APIs are not wire-compatible and lists server-side A/B testing, built-in event tracking and out-of-the-box personalization as missing. Ask the engine and partner to name each Algolia parameter your front end uses and mark it as mapped, replaced or dropped.
Finally, list the admin tools and the identity path into them. Decide whether editors who manage synonyms, pinned results or index settings sign in through the company's single sign-on, and whether that access is separate from the search API keys the storefront uses. The OpenSearch Security plugin supports SAML, OpenID Connect, LDAP and Active Directory, which is one concrete example of this kind of check, while Meilisearch Enterprise lists SSO SAML among its commercial features. Confirm these capabilities with each vendor in writing, since a feature on one edition may not exist on the community build you plan to run.
Operational requirements that decide whether site search stays up
This table compares the operational requirements that determine whether a self-hosted search service stays available, how each one is verified, and who carries the work. Read each row as a question to answer in writing before choosing a platform. The main takeaway is that uptime depends on the cluster design, upgrade path and recovery steps you own, not on the engine's license.
| Requirement | What to specify | Verification step |
|---|---|---|
| Availability target | A written uptime target for search, separate from the site it serves, with agreed behavior when search is degraded (for example, fallback to cached or basic results). | Ask the vendor or partner which targets they can commit to in writing, then run a load test at expected peak query volume before go-live. |
| Node count and failover | Typesense recommends a highly available 3-node or 5-node Raft cluster for production, tolerating one or two node failures respectively. Confirm the equivalent design for Meilisearch and OpenSearch. | Run a scheduled failover test: stop one node (or two in a 5-node cluster) under query load and record errors, latency and time to recover. |
| Backups and snapshots | Meilisearch documents that operators manage backups themselves when self-hosted. Specify backup frequency, storage location, retention and who restores. | Perform a restore into a separate environment and confirm search results match the source index on a sample of queries. |
| Upgrade path and version support | OpenSearch keeps a version in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and maintenance adds only bug and security fixes. Record which version you run and its end date. | Rehearse the upgrade on a copy of production data, including rollback, before scheduling the change in production. |
| Release cadence | OpenSearch targets a new minor version about every eight weeks, so plan a recurring patch window rather than an occasional project. | Measure how long one upgrade cycle takes from release to production and confirm the team can repeat it within your change window. |
| Monitoring | Track node health, memory use (Typesense sizing depends on RAM for keyword and vector data), query latency, error rates and index freshness. | Trigger a simulated memory alert and a stalled indexing job, and confirm both reach the on-call channel. |
| Reindexing without downtime | Define how a full reindex or schema change runs alongside live traffic, including a cutover step and a rollback to the previous index. | Run a full reindex on staging while serving queries, then compare result quality and availability against the pre-run baseline. |
| Support hours and escalation | Name the hours of cover, the severity definitions, who can change the cluster and how vendor or partner escalation works. Confirm whether support terms apply after go-live. | Walk through a tabletop incident at 2 a.m. local time and confirm the named person responds within the agreed path. |
Questions that separate Meilisearch, Typesense and OpenSearch
Which edition of Meilisearch gives us the clustering or SSO we need?
Start by checking which edition contains the feature, because the answer changes the license bill. The Meilisearch README states that the Community Edition is fully open source under the MIT license, while the Enterprise Edition is governed by a commercial license or the Business Source License 1.1 and is not permitted in production without a commercial agreement. Confirm in writing whether high availability, replication, SAML SSO or multi-tenant controls you need sit in Community or Enterprise, and what the commercial agreement covers. For Typesense, the server is GPL-3.0 and its clustering uses Raft, so confirm your node count and identity requirements directly against the Typesense GitHub repository. For OpenSearch, the Security plugin already supports SAML, OpenID Connect, LDAP and other backends, which you should verify against your identity provider.
How will the team supply vector embeddings for semantic search?
Decide where embeddings come from before you choose an engine, because the engine stores vectors but does not decide how they are produced. The options are a built-in or bundled model, a model you host yourself, or an external embedding service, and each one moves data across a different boundary. Typesense's system requirements guide says each vector needs 7 bytes of memory per dimension and that built-in ML models need roughly 2 to 6 GB of extra RAM, so model choice directly affects sizing. Meilisearch exposes hybrid search through embedders, and OpenSearch offers vector search as well. Ask each vendor or your team to confirm the embedding model, its dimension count, where it runs, and who maintains model files when they need updating. In a restricted network, model files may have to be imported by media.
Does our catalog size and tenancy model fit the engine?
Map your record count, searchable fields and number of tenants against each engine's memory model before running any proof of concept. Typesense's system requirements guide says keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, so the index has to fit in memory. The Meilisearch README describes multi-tenancy that personalizes results for any number of application tenants, but you should test how tenant isolation works in your version. OpenSearch uses indices and shards, which suits large catalogs but adds node-level tuning. Ask for a sizing estimate based on your actual document size, field list and growth forecast, and run a load test with realistic query volume.
How do we test upgrades before they reach production?
Test every upgrade on a copy of production data in a staging environment that mirrors your topology, then compare search results and latency before cutover. Each engine ships on its own cadence: Meilisearch v1.55.0 was published on October 12, 2026, Typesense v30.2 was published on April 19, 2026, and OpenSearch targets a new minor version about every eight weeks. Check the release notes for breaking changes to settings, API parameters and index formats. OpenSearch documents rolling upgrades from Elasticsearch 6.0 through 7.10 indices, which matters if you are migrating from an older cluster. Write the test plan, rollback criteria and sign-off owner into the scope before the first upgrade.
What happens when an engine version leaves maintenance?
Confirm the support window for your exact version and plan the move to a supported line before the window closes. OpenSearch versions stay under maintenance until the next major version enters maintenance or one year passes, whichever is longer, and during maintenance they receive bug fixes and security patches but no new features. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release. For Meilisearch, maintenance releases ship on older 1.5x lines, but you should confirm which lines receive security fixes. Typesense publishes a 29.1 maintenance release alongside v30.2. Ask each vendor for its published end-of-life policy in writing, and budget for an upgrade cycle on a fixed date rather than waiting for a security incident.
Who owns security patching for the search engine and its host?
Assign patching responsibility for each layer in writing: the operating system, container image, search engine, reverse proxy and the indexing pipeline. Self-hosting means your team or your partner is responsible for applying fixes, because the engine vendor will not patch your servers. Meilisearch's pricing page states that operators manage updates, backups and scaling themselves when self-hosting. Set a patch schedule, define an emergency path for critical advisories, and record who approves each change. If you use a partner, the scope document should name the patch frequency, the tested rollback method and who signs off. Ask how the partner evidences patching for your compliance assessment, since DeployOpen prepares evidence for assessments but does not issue audit reports or certifications.
Can our team run this ourselves, or do we need a partner?
The answer depends on how much of the run cost your team can absorb and how fast it must recover from incidents. Self-hosting removes subscription fees for the Community or open source edition, but your staff then owns installation, backups, scaling, upgrades and monitoring. Meilisearch Cloud and Typesense Cloud publish pricing that moves those tasks to the vendor, with Typesense Cloud billing bandwidth separately. Compare the cost of internal staff time against a fixed-scope implementation and a retainer for support and upgrades. Ask any partner to define the handover, documented runbooks, the test environment and the response process in the written scope before work starts, since most DeployOpen engagements are fixed-scope and quoted from that scope.
How to score the checklist and turn it into a shortlist
This sequence turns the requirements list into a defensible shortlist of self-hosted search options, with the evidence behind each decision and a written set of questions for vendors and partners.
Write requirements and assign owners
Start by converting each checklist area into specific, testable requirements: functional search needs, hosting and data location, identity and access, privacy and retention, integrations, and operations and support. Assign every requirement one named owner from security, legal, the product or content team, or platform engineering, because an unowned requirement cannot be tested or signed off. The step is done when each line has a clear pass or fail condition and an owner who will accept or reject the evidence.
Classify each requirement by priority
Mark every requirement as a must-have, a should-have, or not needed for this site or application. Keep the must-have list short and tie each entry to a rule your organization already has, such as a data residency commitment, an access control policy, or a documented uptime expectation. Ask the security and compliance owners to confirm the must-have list before any product is evaluated, so the bar is not moved after results arrive. The step is done when the signed list shows which items can eliminate an option and which can only lower its score.
Build a representative test data set and query set
Export a realistic sample of your own indexed content, including the largest collection, the fields users filter on, and the synonyms and misspellings your support team already sees in logs. Pair it with a query set drawn from real search history and a set of queries the business cares about most, with expected top results agreed in advance. Where the source is an existing hosted search service, plan the export and the mapping of its settings early, because those migrations differ by engine. The step is done when the data and queries are versioned and reviewed by the content owner.
Run a proof of concept against the must-haves
Install each shortlisted engine in a test environment that matches the intended hosting model, then load the data set and run the query set with the same front end or a close copy of it. Measure relevance against the expected results, check memory use at your catalog size, test an authentication and access scenario, and confirm the behavior when a node or process is restarted. Record anything that needed custom code or a workaround, because that work will become part of the implementation cost. The step is done when every engine has been tested against the same inputs and the results are comparable.
Record evidence for each requirement
For each requirement and each engine, write down the test performed, the result, the date, the version tested, and where the proof is stored, such as a configuration file, a log extract, a screenshot, or a benchmark output. Where a requirement depends on vendor documentation rather than a test, label it as a claim to be verified and link it to the source. Keep the evidence in the same register used for security reviews so that auditors and internal reviewers can trace each decision. The step is done when no score on the matrix lacks a traceable record.
Eliminate options that fail a must-have
Remove any option that fails a must-have requirement, and record the specific failure and the requirement it breached. Do not offset a failed must-have with strong results elsewhere, because the purpose of the classification step was to set those limits in advance. For options that pass, compare the should-have results and the open risks side by side, and flag where a licence, edition, or hosting condition needs legal review. The step is done when the remaining options are the shortlist and each exclusion has a written reason.
Produce the shortlist and open questions
Issue the output as two documents: a shortlist with the evidence summary for each remaining option, and a written list of open questions for each vendor, implementation partner, or internal team. Questions should cover edition and licence obligations, support terms after go-live, the scope of any fixed-price implementation, how upgrades and backups are handled, and any requirement that was only verified on paper. The step is done when the sponsor has signed the shortlist and the questions have been sent with a response date set by the procurement owner.
What do buyers ask before hiring help with site search?
What drives the cost of self-hosted site search implementation?
The main drivers are catalog size, the number of sites or tenants, the uptime target, the migration scope and the support model. A larger catalog means more indexing work, more memory and more testing of relevance. Each additional site or tenant adds configuration, access rules and separate indexes to plan and verify. A higher uptime target usually means a multi-node cluster, backups and a tested recovery procedure. Migration scope depends on how many indexes, synonyms, ranking rules and front-end widgets must move. Support is priced separately from the build. Ask for a quote built from a written scope that lists each of these drivers as its own line, so you can see what changes if one of them moves.
How long does a fixed-scope site search implementation take?
Length is set by the scope you agree in writing, not by the engine alone. The main variables are the number of indexes and sources, how much existing search behavior must be reproduced, the number of front ends that call the search API, the identity integration, and how many review rounds your content and security teams need. Installing a single Meilisearch or Typesense node is quick compared with designing a highly available cluster, tenant isolation and a reindexing pipeline. Ask the implementation partner to show the timeline as phases with named inputs from your side, and to state which dependencies could move the dates.
What does our team need to provide for a search project?
Three groups of staff usually carry the work. Content owners need to confirm which fields are searchable, which synonyms and boosts reflect business rules, and who approves relevance changes. The identity team must describe how users and tenants authenticate, which roles can see which records, and whether the search interface must honor those permissions. The infrastructure team provides hosting accounts or hardware, network paths, DNS, certificates, monitoring and backup targets. Agree on named owners and review dates in the scope. Gaps in these inputs are the most common reason fixed-scope timelines slip.
Can our team set up self-hosted site search alone using a checklist?
A capable team can install and run a single-node search engine using the vendor documentation, and the checklist helps it decide which engine and which options fit. The harder parts are usually production hardening, relevance tuning, migration from an existing hosted search, highly available clustering, backups and security testing. Meilisearch Community Edition is MIT licensed and self-hosting is free of usage limits, but operators manage updates, backups and scaling themselves. Typesense recommends a three-node or five-node cluster for production. Decide which of these tasks your staff will own over time before deciding whether to bring in help for part of the work.
What is one-time cost and what recurs after go-live for site search?
One-time costs cover planning, the initial build, configuration, migration, integration with the site or app, and acceptance testing. Recurring costs cover the infrastructure that runs the engine, backups and monitoring, version upgrades, security patching, relevance maintenance as content changes, and support hours. Hosted options publish subscription pricing: Meilisearch Cloud starts at $20 per month with a 14-day free trial, and Typesense Cloud bills dedicated clusters with bandwidth billed separately, according to each vendor's pricing page. Self-hosted engines have no license fee for the Community or open-source editions, so the recurring cost is mainly infrastructure and staff or partner time. Ask for both figures in the quote.
What support and upgrade terms should we ask for after go-live?
Ask what is covered after acceptance, how security fixes are applied, and who performs upgrades. Engine release cadence matters here: OpenSearch targets a new minor version about every eight weeks, and during maintenance it receives bug fixes and security patches without new features. Ask for the response expectations in writing, the upgrade procedure and test environment, backup restore testing, and whether security testing is included or sold separately. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, and the scope of each retainer is set in writing before work starts.
How DeployOpen scopes, delivers and supports site search selection and implementation
DeployOpen turns a requirements checklist for self-hosted site search into a written, fixed scope, then plans, builds, tests and documents the chosen engine inside your own cloud accounts, data centers or air-gapped networks. The work is agreed before it starts, and ongoing support is available as a retainer.
How we scope
- Walk through functional must-haves such as typo tolerance, filters, facets and synonyms against your catalog or content
- Record hosting location, data residency, tenancy model and identity provider requirements in the written scope
- Agree which deliverables, environments and integrations are in scope before any engine is installed
How we build
- Deploy the selected engine (Meilisearch, Typesense or OpenSearch) in your environment with access controls and TLS configured
- Build indexing pipelines from your source systems and test relevance, filtering and failover behavior against agreed criteria
- Run security testing on the search API and interface, and document configuration, keys and roles
How we hand over
- Deliver architecture notes, runbooks for updates, backups and reindexing, and the configuration baseline
- Provide the evidence you need for internal reviews or compliance assessments, which independent auditors and certification bodies then assess
- Train your operations and engineering staff on day-to-day administration as defined in the written scope
How we support
- Offer ongoing support, version upgrades and continuous testing through a retainer agreed separately from the build
- Monitor patch releases for the engine version in use and plan upgrades in your change windows
- Revisit the requirements checklist when catalog size, tenancy or data location rules change
