SearXNG: a self-hosted metasearch engine that does not profile its users

The problem SearXNG solves for people who run their own infrastructure

A normal search query tells a search provider what you are interested in, from which network, and at what time. SearXNG exists to break that link. The README states it plainly: it is a metasearch engine, and users are neither tracked nor profiled. It does not crawl the web itself. It takes your query, fans it out to search services and databases it knows how to talk to, and merges what comes back into a single result page.

The audience is narrower than the tagline suggests. SearXNG is a Python application that you host, so its real users are people who already run a VPS or a home server and are comfortable with a reverse proxy and a config file. The second audience is tooling: anything that needs an HTTP search endpoint without a commercial API key, from a script to an assistant front end. The docs.searxng.org site is the canonical reference for both, and the README points there for installation and configuration rather than repeating the steps.

How the aggregation works: engines, request flow and the result merge

The repository is a Python package under searx/, installed via setup.py, which declares python_requires=">=3.10" and registers one console script: searxng-run = searx.webapp:run. So the process you start is a WSGI application. A request hits the webapp, the query is parsed against the configuration in settings.yml, and the selected engines are queried.

The engines are the unit of extension. Each one describes how to build a request for a particular service and how to parse that service's response. Because the parser is per engine, a change on the upstream side breaks that engine alone rather than the whole instance. This is the main operational reality of running SearXNG: upstream search pages change, and the project's engine definitions have to follow. The dependency list hints at how requests are made, with curl_cffi pinned alongside lxml for parsing and msgspec for fast structured handling.

Results are merged and ranked in the application before rendering. That merge is where the design trade-off lives. A metasearch engine cannot apply the ranking signals a first-party engine has, because it only sees the result pages, not the click data behind them. You get breadth across sources and you give up some ordering quality. The project also ships a client/ directory and a container/ directory, and there is a Go module (go.mod, module searxng.org/devtools) that only pulls in shfmt as a tool, which tells you the Go code is developer tooling, not part of the running server.

Installing SearXNG with Docker and running a first query

The README does not contain install commands. It says: "To install SearXNG, see Installation guide", linking to docs.searxng.org/admin/installation.html, and the same for configuration. The repository does contain a container/ directory and a .devcontainer/ directory, which is why container-based deployment is the common path and why "searxng docker" is one of the phrases people search for. The exact image tag and compose file live in the installation guide, not in this repository's README, so fetch them from there.

Once the instance is up, the settings.yml file is the control surface. It is shipped as package data inside the searx package (setup.py lists 'settings.yml' under package_data for searx), and the configuration guide documents its keys. The keys themselves are not reproduced in this repository's README, so take the exact names from that guide before editing the file.

After restarting the process, open the root URL and search. You should see a results page with a source label under each entry, which is how you tell which engine returned it. If a whole engine is missing from a query, that engine is usually disabled in settings.yml or has been rate-limited upstream; the instance's own logs are where that shows up.

The HTTP API is the second entry point and the reason "searxng api" is searched so often. The API is the same web application reached with a format parameter, and which formats an instance exposes is controlled in settings.yml. The configuration guide covers those keys and how to restrict them. Keep format access closed on anything reachable from the internet, because an open JSON endpoint is a free search API for whoever finds it.

Where SearXNG breaks: upstream rate limits and the wrong use cases

The failure mode that catches new operators is not a crash. It is a slow degradation. Because every query becomes outbound requests to third-party services, your instance's IP address accumulates a reputation with those services. When an upstream starts returning a block page, the engine's parser gets HTML it did not expect and that engine quietly stops contributing results. Nothing in the README promises otherwise, and the configuration guide is where rate limiting and bot detection settings are described. A public instance that anyone can query will hit this faster than a private one.

The second limitation is legal and structural rather than technical. You are re-serving other people's result pages. That is a different posture from crawling, but it is not the same as being a first-party search engine, and operators should read the project's own documentation on the subject rather than assume.

The wrong-tool case is simpler. If you want search results with a contractual uptime, a support contact, and ranking tuned on real query logs, a self-hosted metasearch engine is not that product. If you want a single binary with no Python runtime, this is also not it. And if you are searching for something obscure where one specific engine's index is the only place the answer exists, aggregating ten engines does not help you; going to that engine directly does.

SearXNG compared with running searx or a hosted search API

The search question "What is the difference between searx and SearXNG?" has a factual answer. SearXNG is the project in this repository, a Python package named searxng with the console script searxng-run, licensed AGPL-3.0-or-later. The original searx is its predecessor, and the README and setup.py describe only SearXNG. If you are choosing between the two today, the choice is between a codebase that is not archived and a predecessor.

The more interesting comparison is against a hosted search API. A commercial API gives you a stable JSON contract, per-key quotas, and someone else absorbing upstream breakage. SearXNG gives you no quota and no contract, but also no per-query billing and no third party seeing your queries. The difference in approach is where the parsing work sits: with a hosted API, the vendor maintains the parsers and you consume a schema; with SearXNG, the parsers live in your deployment and you update them. That is the whole trade. Teams with a person who can babysit a container get a search endpoint for the cost of a VPS. Teams without one get an instance that slowly loses engines.

Maintenance, upgrades and the AGPL-3.0 licence in practice

The repository is not archived. No last push date was available, so how frequently master moves cannot be stated here; check the commit history on the master branch before you rely on it. What the repository layout does show is a CHANGELOG.rst, a CONTRIBUTING.rst, a SECURITY.md and an AI_POLICY.rst, and translations handled through Weblate (the .weblate file and the translated badge both point at translate.codeberg.org). That is a project with an established process, not a weekend script.

Upgrade cost is dominated by two things: the Python dependency pins in requirements.txt, which are exact (flask==3.1.3, lxml==6.1.3, curl_cffi==0.16.3 and so on), and settings.yml compatibility. Pinned dependencies make builds reproducible and make upgrades a deliberate act. If you have customised settings.yml, diff it against the shipped file on every upgrade, because that file is package data and will be replaced.

The licence is AGPL-3.0-or-later, per both the README and setup.py. The practical consequence, stated as a fact rather than legal advice: if you modify SearXNG and let users interact with it over a network, the AGPL's source-availability obligation is the thing to read carefully. Running an unmodified instance for yourself does not raise the same question. For anything beyond that, talk to a lawyer who knows the licence.

Editorial conclusion

SearXNG suits teams that already run a server and want search queries to leave their network from an address they control, and it suits anyone who wants an HTTP search endpoint for scripts and LLM tooling. It is the wrong choice if you want a managed service with an uptime commitment, or if you expect a drop-in replacement for Google's result quality on every query. Before committing, verify that the upstream engines you care about still answer your instance's requests, and read the settings.yml documentation for the limiter and botdetection options, because an open instance will be scraped and rate-limited by upstreams within days.

Frequently asked questions

Official sources

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