Open source site search for government websites

Why open source site search for government websites needs a different build

Agencies replacing a hosted search service on public sites should plan for a self-hosted engine such as Meilisearch, Typesense or OpenSearch, and choose among them based on how many sites share one index, where data must physically sit, and how much uptime the public expects. The hosted service you are leaving was probably sold as a single tenant, one endpoint and one vendor contract, and the replacement has to cover all of those jobs without that vendor behind it. Meilisearch fits a smaller estate with a simple tenancy model and a clear need for typo-tolerant, faceted search. Typesense fits a distributed setup where a three or five node Raft cluster is acceptable to operate. OpenSearch fits larger estates that already run its tooling and need deeper log and analytics capabilities. Confirm each option against your own hosting boundary before shortlisting it.

The compliance clock is the first hard constraint. The ADA Title II rule requires state and local government web content and mobile apps, including content provided through contracts or licenses, to meet WCAG 2.1 Level AA. Under the interim final rule published April 20, 2026, entities serving 50,000 or more people must comply by April 26, 2027, and smaller entities and special districts by April 26, 2028. A search interface that is delivered by a third party still falls within the content your agency is responsible for, so the accessible results page, filters and error messages must be tested as part of your site, not treated as the vendor's problem. Ask any implementation partner to show how keyboard operation, focus order and screen reader announcements for results are verified against WCAG 2.1 AA before go-live.

Data location and procurement decide the rest. A self-hosted engine keeps queries and indexed content inside your boundary only if the servers, backups and logs are also inside it, so confirm where each of them lives, who holds administrator access, and whether search query logs are retained and for how long. Procurement teams should ask for a written support scope, named response obligations and an upgrade path for the engine, because the vendor SaaS contract you are replacing will not carry over automatically. Each of these choices shapes the build more than the choice of engine does.

Which requirements shape a government site search build

This table maps the main US and EU requirements that touch a government site search build to what each means for hosting, the search interface and logging. Read each row for where the requirement applies and where it does not, then confirm applicability with counsel and your compliance office before scoping.

Requirement	What it means for the build	Where it applies or may not
ADA Title II, WCAG 2.1 AA	The search box, results, filters, autocomplete and error messages must be operable by keyboard and readable by assistive technology. Search results pages are web content under the rule.	Applies to state and local government web content and mobile apps, including content provided through contracts. Compliance dates depend on population served, with the first date set for entities of 50,000 or more people.
FedRAMP scope	If a hosted search service stores or processes federal information for an agency as a shared cloud service, it falls within FedRAMP. A self-hosted engine run by the agency on its own infrastructure is generally a different question.	Does not apply to a single agency system on cloud infrastructure not offered as a shared service. Confirm the boundary with your authorizing official and the FedRAMP program.
NIST SP 800-53 baselines	The engine, hosting and logging components inherit access control, audit, configuration and contingency controls from the chosen baseline (low, moderate or high). Documented configuration and monitoring are the evidence assessors expect.	Applies when a federal or federally aligned authorization is in scope. Baseline selection follows system categorization, so confirm the impact level with your security team.
CJIS Security Policy encryption and scanning	If criminal justice information could reach the index or logs, encryption must use FIPS 140-3 validated modules or AES with 256-bit keys, and vulnerability scanning must run at least monthly.	Applies only where criminal justice information is processed. Public-facing search indexes for ordinary content normally fall outside it, but confirm that no case data is indexed.
CUI handling under 32 CFR 2002	Federal agencies applying 32 CFR 2002 to non-federal systems use NIST SP 800-171 for CUI safeguards. Search indexes, caches and query logs holding CUI must follow those safeguards.	Applies where the agency or its contractor handles controlled unclassified information. Public website content is generally not CUI, so confirm labeling rules for internal documents.
NIS2 for EU public administration	Central government entities are covered regardless of size, and public administration is a high-criticality sector. Obligations include risk management, incident reporting and supplier security, which affect hosting and logging of search.	Does not apply to entities working in national security, public security, defense or law enforcement. Member States may extend coverage to local public administration, so confirm national transposition.
Query logs and analytics	Citizen search queries can reveal personal data or sensitive topics. Log retention, access rights and pseudonymization should be set before the first query is recorded.	Applies in every jurisdiction where queries can identify a person. Confirm with counsel which privacy regime governs your agency and whether query data is personal data.

How Meilisearch, Typesense and OpenSearch fit agency estates

A single large public site usually has one search index, one set of content owners and a clear uptime expectation. The engine choice here depends mostly on operating model and on whether the agency can keep one node or must run a cluster. Meilisearch fits a single index with typo-tolerant, faceted search and a small operations footprint, while Typesense fits the same job when the agency wants a documented high-availability cluster from the start. OpenSearch fits when the agency already runs it for logs or other workloads and has staff who operate it.

Operating footprint: A single Meilisearch instance is simple to run, but the operator owns updates, backups and scaling, so plan for those tasks from day one.
High availability: Typesense recommends a highly available 3-node or 5-node Raft cluster for production, tolerating one or two node failures respectively.
Memory planning: Typesense keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, so size nodes from a measured content inventory.
Existing skills: OpenSearch brings value where the agency already has operators and monitoring for it.
Redundant search: Keep the chosen engine's backup and restore path tested before go-live.

Before committing, confirm the search volume, peak traffic and recovery targets with the agency's own service owner, and confirm the engine's edition terms for production use.

Which open source search platforms fit a government estate

Agencies replacing hosted search usually shortlist Meilisearch, Typesense and OpenSearch. Each can run inside the government boundary, but each asks for different decisions on tenancy, memory, edition licensing and migration effort from a hosted Algolia index.

Meilisearch for multi-department tenancy

Meilisearch offers multi-tenancy that personalizes results for any number of application tenants, which can suit one platform serving many department sites. The constraint is licensing: the Community Edition is MIT licensed, 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 the edition before design starts. Check also whether the features you need, such as replication, sit in the edition you can legally run.

Typesense for high availability

Typesense is licensed under GPL-3.0 on the server, so an agency can run modified server code internally without publishing changes as long as it does not distribute the software. Its Raft-based clustering suits a highly available setup. Plan for memory: keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, and each vector needs 7 bytes per dimension. Production guidance points to a 3-node or 5-node cluster.

OpenSearch for analytics-heavy estates

OpenSearch fits agencies that already run log analytics or need deeper aggregation and query tooling alongside site search. It brings more operational weight than the other two engines, including node roles, shard planning and replica management. Confirm which OpenSearch distribution, support model and security plugin configuration your agency will accept before you compare it on relevance or cost.

Algolia migration to Meilisearch

Meilisearch documents an Algolia migration path that exports records with browseObjects and imports them with addDocumentsInBatches in batches of 100,000. Attributes for faceting map to filterable attributes, and NeuralSearch maps to hybrid search with embedders. Three Algolia features have no direct equivalent, including aroundPrecision and disablePrefixOnAttributes, so review each query rule before cutover. InstantSearch front ends need the Instant Meilisearch adapter.

Algolia migration to Typesense

Typesense exports Algolia records as JSONL with the Algolia CLI, maps objectID to an id field and imports with action=upsert. Query rules convert to the Overrides API. The APIs are not wire-compatible, and Typesense reports about 85% feature parity, with server-side A/B testing, built-in event tracking and personalization missing. Agencies that rely on those features need a separate plan for analytics on what citizens search for.

InstantSearch adapter and accessibility testing

Both Meilisearch and Typesense offer adapters so existing Algolia InstantSearch widgets can keep working with small changes. An adapter does not certify the search interface. Results announcements, focus order, autocomplete behavior and keyboard use are set by the front end, so test the adapter output against WCAG 2.1 Level AA in your own accessibility testing before any department adopts it.

Integration points and deployment pattern for agency search

An agency search service touches identity, content sources, a public API path and a query log, and each one has to sit inside the government boundary. The cards below follow those connection points in the order a design review usually walks through them, with the decisions to record at each one.

Identity for admin consoles

Administrators of the search engine, its connectors and its analytics dashboards should sign in through the agency identity provider with multi-factor authentication, not through local accounts shared between departments. Meilisearch, Typesense and OpenSearch each expose an admin key or role model, and the console or dashboard in front of it may be a separate application with its own login path. Ask the implementation partner to list every admin surface, who holds each credential, and how an agency revokes a departing administrator's access across all of them in one step.

Connectors to department CMSs

Each department usually runs its own content management system, so the indexing pipeline must read from several sources with different APIs, update rhythms and page templates. Decide whether the connector pulls on a schedule, receives webhooks on publish, or both, and confirm that unpublished or restricted pages never enter the index. Keep the connector service inside the boundary, with read-only credentials scoped to each source. Document which team owns each connector after go-live, because a broken connector often shows up first as stale results.

Search API behind the agency gateway

Public queries should reach the search engine only through the agency's API gateway or reverse proxy, which applies rate limits, request logging and a read-only key for browser clients. The search engine itself should not be reachable from the internet, and admin endpoints should be blocked at the gateway even if they are open on the internal network. Confirm which key types are safe to expose to a browser, and test that write and settings endpoints return refusals to an unauthenticated caller.

Department index separation

Agencies running many department sites can keep one index per department, or one shared index filtered by a tenant key attribute on every document. Separate indexes simplify deletion and per-department ownership, while a shared index with scoped API keys reduces the number of objects to operate. Whichever pattern is chosen, a missing tenant filter is a data exposure risk, so make the scoped key the only key a department front end can use and test cross-department queries before launch.

Deployment inside the government boundary

Run the search cluster, connectors, analytics store and backups in the agency's own cloud accounts or data center, on infrastructure that already falls under the agency's authorization boundary. Confirm which cloud services the stack depends on, since any managed component outside the boundary changes the assessment. For vendor-hosted cloud, FedRAMP scope turns on whether a service is offered to multiple agencies, so ask the partner to document that position for each component rather than assume it.

Log retention for citizen queries

Search queries can reveal personal circumstances, so the query log is a data store in its own right, with its own retention period, access list and deletion process. Decide what is logged (query text, result counts, clicks, IP address or session identifier), mask or hash what is not needed, and set a retention period in the records schedule rather than leaving the engine default in place. Confirm with the agency privacy office and records officer before indexing analytics, because the answer changes what the analytics dashboard can show.

How an agency rollout moves from pilot to all department sites

The sequence takes search from a single pilot department site to every department site under a tested, documented and reversible cutover. Each phase closes with a named artifact that the agency can review before the next phase starts.

Run discovery and set requirements
DeployOpen works with the agency's web governance team, accessibility lead, security team and hosting group to inventory every department site, its content types, its current search provider and its data handling rules. The team records which sites hold public content only and which carry restricted material, then confirms the hosting boundary and the engine edition the agency is permitted to run in production. The phase closes with a signed requirements register and a scope document that lists in-scope sites, excluded sites and the accessibility target. Confirm the applicable WCAG version and compliance date for the agency's population band with your legal counsel before scoping.
Build and test the pilot on one department site
The engineering team deploys the chosen engine inside the agency's boundary, connects one department site and builds its index, relevance settings and search interface. Accessibility testing covers keyboard operation, screen reader announcements for result counts and filters, focus management, color contrast and error messages, carried out by testers who use assistive technology. The phase closes with a tested accessibility report listing each defect, its severity and its fix status, plus a pilot sign-off from the department owner.
Migrate existing indexes and search settings
The team maps the current provider's index settings, synonyms, ranking rules and facets to the new engine, then exports and imports records in controlled batches. Each migration run is checked against record counts and a fixed set of representative queries that the department has approved. Where the current provider has features with no direct equivalent, the team documents the gap and the agreed workaround. The phase closes with a migration record showing source and target counts, mapped settings, known gaps and the query results compared before and after.
Expand the pattern across department sites
The team turns the pilot configuration into a reusable template with shared index naming, tenancy rules, access controls and logging, then applies it to each remaining department site in waves. Each wave repeats discovery checks, accessibility testing and query validation at the site level, because content and templates differ between departments. Operators keep one configuration repository so that changes to ranking or security settings reach every site through a reviewed change. The phase closes with a per-site acceptance record and an updated configuration baseline.
Prove the cluster and analytics before cutover
Before any public traffic moves, the operations team runs load tests against expected peak search volumes, tests node failure in the cluster design the agency chose, and verifies backup restores into a separate environment. The analytics setup is checked to confirm that query logs are collected, retained and access-controlled according to the agency's privacy and records rules. The phase closes with a test report covering performance, failover and restore results, and a signed log-handling statement from the data owner.
Cut over with a documented rollback
The team schedules the switch for each site in a low-traffic window agreed with the department, keeps the previous search provider running in read mode, and switches the search interface to the new endpoint. A runbook lists each step, the person responsible for it, the checks that confirm success and the exact rollback steps. Post-cutover monitoring watches error rates, zero-result queries and accessibility regressions for an agreed period before the old provider is decommissioned. The phase closes with a cutover record, a rollback test log and a decommissioning certificate for the retired service.

Evidence an agency and its assessors will ask for

This table lists the evidence items a government team usually has to produce for a self-hosted search deployment, which component generates each one, and what an assessor will check. Read it as a preparation list: DeployOpen prepares the evidence, while independent auditors and the agency's authorizing officials issue the assessments.

Evidence item	Produced by	What the assessor checks
WCAG 2.1 AA test results for the search interface	Accessibility testing of the search front end, including keyboard use, focus order, labels on filters and results announced to screen readers	Whether results, autocomplete and facet controls meet WCAG 2.1 Level AA, which the ADA Title II rule requires for state and local government web content, with compliance dates to confirm for the agency's population size
Hosting and government boundary diagram	Infrastructure-as-code and network design for the search cluster, reverse proxy and sync pipeline	Where each search node, index, backup and log store runs, which accounts or data centers are inside the boundary, and how traffic from departmental sites reaches the cluster
Encryption configuration for CJI paths	Load balancer, TLS settings and storage encryption settings for the search nodes and backups	Only where criminal justice information is indexed: key lengths and module validation against CJIS Security Policy v6.1, which calls for FIPS 140-3 validated modules or AES with 256-bit keys
Vulnerability scan records	Scanner for hosts, containers and the search engine version in use, run by the operations team	Scans at least monthly, findings tracked to closure, and evidence the scan covered the search engine and its dependencies
Backup and restore test records	Snapshot or backup job for indexes, configuration and API keys, plus a restore exercise	Dated restore tests on a separate environment, recovery time and data loss observed in the test, and proof that backups are encrypted and access-controlled
Query log retention rules	Analytics pipeline that stores search queries, with its retention and access settings	Retention period set by the agency, who can read logs, whether logs contain personal data entered by citizens, and how they are deleted at end of retention
Access control and identity configuration	Search admin console, API key scoping and integration with the agency's identity provider	Least-privilege API keys for each department site, separate admin roles, and logging of administrative changes to indexes and synonyms
Software bill of materials and version record	Build pipeline and package manifests for the search engine, plugins and front-end adapters	Exact versions in production, supported release lines for the chosen engine, and a documented patch process for maintenance releases

Analytics on what citizens search for, without over-collecting

Search terms that return no results are one of the most useful signals a government site can collect, because they show where content is missing, where a department uses different wording from the public, and where a form or service page is hard to find. A team reviewing a monthly list of zero-result queries can add a page, a redirect or a synonym in the search engine's settings without commissioning a survey. The catch is that a search box invites people to type whatever is on their mind, and some of that text is personal data: a name, a case number, a benefit reference, a health condition or an address. Whether your logs count as personal data, and for how long you may keep them, is a question for your legal team and your data protection officer, and the answer depends on your jurisdiction and on the sites involved. Confirm it before you turn logging on.

Design the collection to reduce what you hold. Log the query text only where it is needed, strip or hash anything that looks like an identifier before it is written, and do not store the IP address or session identifier alongside the query unless a documented purpose requires it. In the self-hosted engine, decide which events the front end sends to your analytics store, and keep that configuration in version control so a reviewer can see exactly what is captured. Note that Meilisearch and Typesense do not provide built-in event tracking in the way hosted SaaS search products do, so the logging pipeline is part of your build and part of your privacy evidence. Ask your implementation partner to show where the query is written, what is dropped, and who can read the output.

Set retention and access before the first report is produced. Keep raw query logs for a short, written period, then keep only aggregated counts by term, site and date, and delete the raw records on a schedule that a system job enforces. Limit read access to the content team and the analytics owner, use role-based access in your analytics tool, and record who exports data and why. Aggregation should also apply to small counts: a term typed by only one or two people can still identify them, so suppress or group rare terms in shared reports. Treat these settings as controls to test, not as policy statements. Evidence such as the configured retention job, the access list and a sample of the redacted logs will be what an assessor or privacy reviewer asks to see.

Questions agencies ask before commissioning site search

What drives the cost of self-hosted site search for a government website?

The cost is driven by who does the work and how many sites are in scope, not by the engine's license, because Meilisearch Community, Typesense and OpenSearch are open source. Expect one-time costs for design, indexing pipelines, accessibility testing and migration, plus recurring costs for hosting, monitoring, patching, backups and support. The Meilisearch pricing page says self-hosting is free of usage limits but that operators manage updates, backups and scaling. Ask every bidder to price these components separately: infrastructure in your own cloud or data center, implementation, accessibility remediation of the search interface, and a support retainer. Note that the Meilisearch Enterprise Edition is not permitted in production without a commercial agreement, so confirm the edition before pricing.

How long does a site search rollout take, and what sets that time?

No general duration is published here, so treat any single figure from a vendor with caution. The main variables are the number of department sites, the content types to index (pages, documents, PDFs, forms), how many indexes you need, and whether search results must respect permissions. Time also depends on the accessibility review, because the ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. Ask for a written plan with milestones, a pilot site, and a cutover approach that keeps the existing search running until the new one passes testing.

What must the agency provide before implementation starts?

Agencies should prepare an inventory of the sites and content sources, a list of the search features each department needs, and a decision on hosting location and identity integration. The inventory should name content owners, update frequency and any restricted content that must not appear in public results. Provide access to the current hosted search so exports can be mapped, along with the analytics data you want to keep. Confirm the approved hosting boundary, network routes, certificate authority, logging destination and the staff who can approve production changes. Ask the implementation partner to produce a written list of these inputs before the fixed scope is signed.

Can our internal teams run self-hosted site search after go-live?

Yes, if they have capacity for operations, and the decision depends on skills rather than licensing. Your team will own upgrades, index rebuilds, backups, capacity planning and incident response. For Typesense, the system requirements guide sets a minimum of 2 vCPUs and strongly recommends a highly available 3-node or 5-node cluster for production, and keyword search typically needs 2 to 3 times the size of the searchable fields in RAM. Check whether your staff can operate a clustered service, monitor it, and restore from backup. If not, plan a support retainer from the start rather than adding it after an outage.

How should we procure ongoing support for self-hosted search?

Procure support as a separate, written service with defined response expectations, covered versions and named responsibilities. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. Ask bidders to state what the retainer covers: patching cadence, version upgrades, backup restore tests, vulnerability scanning and changes to the index schema. Confirm how the contract handles upgrades to new release lines, since maintenance releases are shipped on older lines and support windows differ by project. Ask for the scope of any service level commitments in writing and do not accept undefined uptime promises.

How do federal or EU scope rules change the choice of search platform?

Scope rules decide whether a cloud search service can be used at all, which is why hosting inside your own boundary is often the simpler route. Under FedRAMP's scope, cloud services that process federal information on behalf of an agency fall in scope, and systems used only for a single agency's operations on cloud infrastructure that are not offered as a shared service are out of scope. NIST SP 800-53 Release 5.2.0 provides the control catalog, and SP 800-53B selects 149, 287 or 370 controls for low, moderate or high baselines. For EU public administration, NIS2 covers central government entities regardless of size and may be extended to local bodies. Confirm with your legal and security teams which regime applies before choosing a platform.

What security evidence should we ask for before approving site search?

Ask for a system description, a data flow diagram showing what search queries and indexed content leave your boundary, and a control mapping to the baseline you have adopted. Request the hardening standard applied, the encryption configuration, and the audit log design. Where criminal justice information might appear in indexed content, the FBI CJIS Security Policy v6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys, and vulnerability scanning at least monthly. Ask the partner which evidence it prepares and note that DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Independent assessors make those determinations.

Does DeployOpen handle search for multiple government sites?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For a multi-site estate, the scope would normally cover one shared search service or per-site indexes, an indexing pipeline for each content source, a consistent accessibility standard for the search interface, and an agreed support model. Engagements are fixed-scope, so ask for the written list of sites, content types and deliverables before work starts. Confirm how new departments are onboarded after go-live and how that work is priced.

What to ask an implementation partner before signing

Start with how the partner tests accessibility of the search interface. Ask whether they test the results page, filters, autocomplete and error states against WCAG 2.1 Level AA, which is the level the ADA Title II rule names for state and local government web content, and whether testing uses automated scans, manual screen reader sessions with named tools, and keyboard-only passes. Ask who signs off the findings and how fixes are retested before go-live. Ask for a sample test report from a past engagement, with client details removed, so you can judge the method rather than a summary. Also ask how they handle the compliance dates in the rule, since the first deadline for larger entities is April 26, 2027, and how a schedule slip would be recorded in the written scope. Next, ask about government hosting and boundary controls. Ask which hosting environments they have built into, how they document the authorization boundary for the search cluster, query logs and analytics store, and which NIST SP 800-53 Rev. 5 baseline they map to (low, moderate or high). Ask whether they have worked with FedRAMP-authorized cloud services or with an agency's own data center, and how they would confirm the boundary matches your system security plan. Ask about edition and licence checks: confirm in writing that the chosen edition permits your production use, and ask who verifies the licence terms for each component, including any Enterprise Edition features they propose. Where the platform is Meilisearch, confirm the Community Edition terms against the current README and pricing page yourself. Finally, pin down the commercial terms. Ask how the partner plans migration from the hosted service, including export and import of records, mapping of ranking and facet settings, and a parallel-run period with rollback. Ask for the fixed-scope definition in writing: which sites, indexes, connectors and accessibility fixes are included, and what triggers a change request. Ask what support and upgrade terms apply after go-live, how security patches are delivered, and whether support is a separate retainer. On evidence, ask which files they produce (test reports, configuration baselines, backup test records, change logs) and who holds them after handover. Ask how they prepare this evidence for your assessors without claiming audit outcomes, since independent auditors and certification bodies issue those results.

How DeployOpen scopes and supports government search

DeployOpen plans, implements, hardens, documents and supports self-hosted search inside the agency's own cloud accounts, data centers or disconnected networks. Each engagement starts with a written, fixed scope covering the sites, accessibility evidence and hosting boundary that the agency must meet.

How we scope

Inventory every department site, document store and app that needs search, and record which content is public and which is restricted
Confirm the hosting boundary, identity provider and logging rules before choosing between Meilisearch, Typesense or OpenSearch
Agree in writing which WCAG 2.1 Level AA checks the search interface must pass before the April 26, 2027 or April 26, 2028 compliance dates

How we build

Deploy the chosen engine in the agency's environment with infrastructure as code, separate environments and documented configuration
Build indexing pipelines per department site, with tenant-scoped keys so each agency unit searches only the content it owns
Test keyboard operation, screen reader output and contrast of the search interface, and record the results against the agreed checks

How we hand over

Deliver runbooks for index updates, reindexing, backups, restore tests and version upgrades that agency staff can follow
Document the security configuration, data flows and access model so the agency can show how search fits its own control baseline
Train named operators and transfer administrator credentials, keys and monitoring dashboards to the agency at the close of the fixed scope

How we support

Offer ongoing support, upgrades and continuous testing under a retainer agreed separately from the fixed-scope build
Track engine release notes and patch maintenance releases, then test and roll out updates in the agency's staging environment first
Confirm with the agency which evidence an independent assessor will need, since DeployOpen prepares evidence but does not issue audit reports or certifications