searx: the unmaintained metasearch engine that still has one clear use

The problem searx solves, and the one it cannot

Every search you type into a commercial engine is a query with an identity attached. searx exists to break that link. It is a metasearch engine: you send one query to your own instance, and that instance fans the query out to third-party engines, aggregates what comes back, and renders a single result page. The upstream engines never see your browser, your cookies or your IP as a search profile, because the requests come from your server rather than from you.

The README is unusually candid about the ceiling on this idea. It states that searx is "fundamentally dependent on third-party search engines", and lists the consequences: results are only as good as what upstream engines expose, privacy guarantees are partial because requests still leave your machine, relevance ranking is limited to what scraped results provide, and there is no persistent memory of what you have already read or found useful. That is a fair summary of the architecture, and it is worth reading before you install anything. searx is for a privacy-conscious individual running an instance locally, which is exactly the audience the FAQ names: "Searx is targeted for privacy conscious users who run their instances locally, instead of using public instances."

How the metasearch pipeline actually works

The repository is a Flask WSGI application. setup.py declares two console entry points, searx-run and searx-checker, which tells you the two things the project expects you to do: serve search requests, and check whether the engines behind them still work. The searx package holds the web application, the engine definitions and the default settings.yml; searx_extra is excluded from the installed package and holds tooling around it. A search request enters the Flask app, is dispatched to the engines enabled in settings.yml, and the responses are parsed and merged into one result list. There is no index of its own and no crawler. Nothing is stored between queries, which is the privacy property and also the reason there is no ranking signal beyond what the upstream engines returned.

The engine layer is the part that ages. Upstream search engines change their HTML, add bot checks, and retire endpoints, so an engine definition that worked at the last release can silently return nothing. That is why the project ships a checker as a first-class command rather than a test-only utility. The FAQ explains the maintenance tension directly: the maintainers did not implement engine-detailed monitoring because they judged it a privacy risk, and they accepted worse bug reports as the price. It is a coherent position, but it means breakage is discovered by users, not by telemetry.

Installing searx from the Dockerfile

The README points to the installation handbook at searx.github.io/searx/admin/installation.html for full instructions; the repository itself carries the Dockerfile used to build the image. That file is the most concrete install artifact available here: it is Alpine 3.15, installs uwsgi and the Python runtime, and exposes port 8080. It also declares two volumes and the settings path, which is what you need to know before running it.

FROM alpine:3.15
ENTRYPOINT ["/sbin/tini","--","/usr/local/searx/dockerfiles/docker-entrypoint.sh"]
EXPOSE 8080
VOLUME /etc/searx
VOLUME /var/log/uwsgi
ENV SEARX_SETTINGS_PATH=/etc/searx/settings.yml
ENV UWSGI_SETTINGS_PATH=/etc/searx/uwsgi.ini

Mount a host directory at /etc/searx and put your settings.yml there, and the container picks it up through SEARX_SETTINGS_PATH without a rebuild. The same file defines INSTANCE_NAME, BASE_URL, AUTOCOMPLETE, MORTY_URL and MORTY_KEY as environment variables, so instance naming and the Morty proxy are configuration, not code changes. The Dockerfile also compiles the Python sources at build time and gzips the static assets, which is why the image does not need a build toolchain at runtime.

For a development instance without Docker, the Makefile is the entry point. Its help target prints the available commands, and its run target installs into a virtualenv and starts the app on 127.0.0.1:8888 with SEARX_DEBUG=1. The Makefile calls ./manage, a shell script at the repository root, for the environment work.

make help
make run

After make run, the Makefile opens http://127.0.0.1:8888/ in a browser after a two-second delay. If the page loads and a query returns results, the engine layer is working. If it loads but returns nothing, the engines are the problem, not the app.

That is what the checker is for. The Makefile exposes it as a target, and setup.py registers searx-checker as a console script, so you can run it either way.

make search.checker
./manage pyenv.cmd searx-checker -v

The -v flag is the verbose form used in the Makefile. Run this before you trust an instance you have configured: it tells you which engines respond, which is the single most useful signal about whether your setup is actually usable.

Where searx fails, and what the pinned dependencies cost you

The README's own announcement is the main limitation: "Searx is no longer maintained." The FAQ repeats it in the maintenance question, and the last push to the repository was on 2026-05-14. The most recent tagged release is v1.1.0 from 2022-08-07, so the release line has been quiet for years regardless of later commits. If you are choosing a search backend for a team, that combination is a hard constraint, not a footnote.

requirements.txt shows the second cost. Every dependency is pinned exactly: Flask 2.2.2, Jinja2 3.1.2, lxml 4.9.2, requests 2.28.2, PyYAML 6.0, and so on. Exact pins make the build reproducible, which is the stated goal, but they also mean you inherit the security and compatibility state of those versions until someone changes the file. There is no rolling update path in the project, and the FAQ says so plainly when contrasting searx with SearxNG: SearxNG has "rolling releases, dependencies updated more frequently, and engines are fixed faster."

A third limitation is the interface. The FAQ states that searx is not adding "a new UI that relies on Javascript." For a local instance that is a feature. For users who expect autocomplete, instant results or a modern single-page interface, it is a wall, and the same FAQ directs those users to SearxNG. Finally, the engine set is a moving target you cannot fix from inside searx. When an upstream engine changes its markup, no amount of local configuration restores it.

searx against SearxNG and DuckDuckGo

The real alternative is SearxNG, a fork of searx created by a former maintainer. The README does not pretend this is a cosmetic split. The fork happened because the majority of maintainers at the time judged the proposed engine-metrics feature insufficiently privacy-respecting; searx chose to forgo better bug reports rather than collect more data about what users search for. SearxNG went the other way, with engine monitoring and metrics, frequent dependency updates, and a JavaScript-based interface. The README's own summary is that SearxNG is "for users that want more features and bugs getting fixed quicker", while searx is for those who "prefer a minimalist software and stable experience." That is a genuine difference in priorities, not a quality ranking, and it is the decision you are actually making.

DuckDuckGo is a different kind of alternative. It is a hosted search service with its own index and its own privacy claims; you send your queries to someone else's servers. searx is software you run, so the trust boundary sits on your machine. The trade is operational: DuckDuckGo requires nothing from you and keeps working when engines change, while searx requires a server, a settings.yml and periodic engine repair. If you are not willing to do that repair, a hosted engine is the better answer. If the point is that no third party sees your query stream, only self-hosting gets you there, and searx and SearxNG are the two ways to do it.

Licence, upgrades and what the AGPL-3.0 means here

searx is licensed AGPL-3.0, and setup.py declares it as GNU Affero General Public License v3. The AGPL's distinguishing feature is the network clause: if you run modified searx as a network service that others use, the licence obliges you to offer those users the corresponding source. Running an instance for yourself raises none of this. Running a public instance on modified code does, and that is a decision for your own legal review, not something this article can settle.

The upgrade picture is thin. The README's own comparison says SearxNG has rolling releases and searx does not; the last tagged release in the repository is v1.1.0 from 2022-08-07. In practice an upgrade means pulling the master branch, re-reading settings.yml because that file ships with the package, and re-running the checker to see which engines survived. The Dockerfile bakes a VERSION_GITCOMMIT build argument into searx/version.py, so a locally built image can record which commit it came from. That is the closest thing to a version story here, and it depends on you passing the argument at build time.

Editorial conclusion

Adopt searx only if you want a small, dependency-pinned, JavaScript-free metasearch instance you run locally for yourself, and you accept that the README states it is no longer maintained and that engine fixes arrive only if someone ports them from SearxNG. Do not adopt it for a public instance, for a team that needs engine breakage fixed quickly, or for anything where an unmaintained upstream is a compliance problem. Before you commit, read the top of README.rst, check the pinned versions in requirements.txt against the engines you actually need, and run the searx-checker target to see which engines currently answer.

Frequently asked questions

Official sources

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