SearXNG: A Metasearch Engine You Host Yourself

The problem is the account, not the index

SearXNG does not crawl the web. It queries other search services and databases on your behalf, then merges what comes back. The README describes it plainly as a metasearch engine and adds a second claim: users are neither tracked nor profiled. Those two sentences define the project. The first is an architectural fact, the second is the reason someone would choose it over the service it queries. If you search from a commercial engine, the query is tied to an identity, usually a logged-in one, and the result page is shaped by a profile built over time. SearXNG moves the query to a machine you run and strips the identity from the request. It is for people who are willing to operate that machine. It is not for people who want a hosted search box with a support contract, because the project does not offer one. The repository topics list the engines it draws from, including Google, Bing, DuckDuckGo, Brave, Qwant, Startpage and Yahoo, which tells you the value proposition is aggregation plus separation, not a private index.

Aggregation happens per query, at request time

The data flow is request-driven. A user submits a query to the SearXNG instance; the instance fans that query out to the search services enabled in its configuration, collects the responses, and returns a merged result page. Nothing is precomputed and nothing is stored as a corpus. This has a consequence that is easy to miss: latency is bounded by the slowest enabled engine, and result quality is bounded by what those engines will return to your server. Because the instance talks to upstream engines directly, the upstream sees the instance's IP address rather than the end user's. The README does not describe rate limiting, caching or engine-level retry behaviour, and it does not document the internal request pipeline beyond the metasearch description. Treat the architecture as a fan-out proxy with result merging. The configuration guide linked from the README is where engine selection and instance behaviour live, and that is the file you will spend most of your time in.

Installation: the README points, the docs carry the detail

The README does not contain install commands. It says: "To install SearXNG, see Installation guide," linking to docs.searxng.org/admin/installation.html, and for tuning, "see Configuration guide," linking to docs.searxng.org/admin/settings/index.html. That is the honest shape of this project. The repository README is a signpost, and the operational knowledge sits in the documentation site. The configuration guide is referenced under the settings path, which in SearXNG deployments corresponds to a settings file, conventionally settings.yml, though the exact filename and schema are defined in that guide rather than in the README. Do not guess at keys. Read the settings index before editing anything. The project also publishes a CONTRIBUTING file and a Matrix room at #searxng:matrix.org for questions, which is the realistic support channel for a self-hosted deployment. The repository shows no releases, so there is no version number to pin to here; you will need to check the repository or the docs for the current install method.

What breaks: upstream engines, not the code

The failure mode that matters is upstream. A metasearch engine depends on services it does not control, and those services have no obligation to answer a self-hosted instance. When an engine changes its response format, adds a challenge, or decides a datacenter IP looks like automation, results from that engine degrade or disappear, and the instance keeps running with a thinner result set. The README makes no promise about engine availability, and it contains no retry, fallback or health-check description. The practical implication is that a SearXNG instance is something you watch, not something you install once. A second limitation is scope: SearXNG is not a document index, so it cannot answer questions that require a private corpus or a guaranteed recall target. If your requirement is completeness or reproducibility for research, a metasearch fan-out is the wrong instrument. A third is that the privacy claim is about the instance operator's behaviour, not an audited guarantee. The README states users are neither tracked nor profiled; it does not describe logging defaults, and it does not say what the instance writes to disk. Verify that yourself in the settings guide before you point real users at it.

Compared with running your own crawler

The obvious alternative is a self-hosted index such as a crawler plus a search backend, which inverts the trade. A crawler gives you control over what is indexed and how ranking works, and it does not depend on Google or Bing answering your requests. It also gives you a crawl budget problem, a storage problem, and a freshness problem that SearXNG simply does not have, because SearXNG borrows freshness from engines that already solved it. Choosing between the two is choosing which dependency you can tolerate. With SearXNG you depend on external services staying reachable and parseable. With your own index you depend on your own crawl and ranking pipeline being good enough, which for general web search it usually is not. A second alternative is to use a commercial search API, which gives you a contract and a bill instead of a configuration file. SearXNG trades that contract for AGPL-3.0 source you can read and modify, and for the ability to run it on hardware you already own.

Licence and the cost of staying current

SearXNG is licensed under AGPL-3.0, per the README and the LICENSE link. The practical effect for most readers: if you modify SearXNG and let other people interact with it over a network, the AGPL's network clause is the part to read carefully, because it can require offering the corresponding source to those users. Running an unmodified instance for yourself or your team is the straightforward case. This is not legal advice; if you plan to embed SearXNG in a product, have counsel read the licence rather than a review. On maintenance, the repository shows the default branch is master and the last push was 2026-09-10, so the project is active, but no releases were retrieved, which means you should confirm your own upgrade path from the repository rather than from a versioned changelog. Budget for two recurring chores: re-reading the settings guide after upgrades, since configuration keys can move, and re-checking which engines still respond from your host. Neither is large, but neither is zero, and an instance nobody checks is an instance that quietly returns fewer results.

Who should run it, and what to check on day one

SearXNG fits a specific operator: someone comfortable running a Python service, who wants queries to originate from infrastructure they control, and who accepts that result quality is a function of third-party engines. It fits a small team or an individual who will actually look at the instance when results thin out. It does not fit anyone who needs a contractual uptime guarantee, anyone who needs a private document index, and anyone unwilling to read a settings guide before deploying. The first thing to verify is not performance. It is engine reachability: enable a small set of engines in your settings file, run a query, and confirm each one returns results from your server's IP. The second is logging behaviour, which the README does not specify. Until you have checked both against the configuration guide at docs.searxng.org/admin/settings/index.html, you are running an instance whose privacy properties you have assumed rather than confirmed.

Editorial conclusion

Adopt SearXNG if you can operate a Python service and want search queries to leave a machine you control rather than a vendor account. Do not adopt it if you need a guaranteed uptime SLA or cannot absorb upstream engines blocking your instance's requests. Before committing, verify one thing first: that every engine you enable in settings.yml still returns results from your server's IP, since the project's own documentation frames SearXNG as a metasearch engine whose output is only as good as the services it can reach.

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. searxng/searxng on GitHub