SearXNG and the repository that hands you a few links and a settings file

The README is one sentence and four links

Here is the whole product description: SearXNG is a metasearch engine, and users are neither tracked nor profiled. Then the file moves straight to Setup, where the instruction is to see the Installation guide, to fine-tune it see the Configuration guide, and for anything else to go to the how-to index at docs.searxng.org/admin/index.html. Community is a Matrix room, #searxng:matrix.org, contributions point at CONTRIBUTING.rst, and the license is AGPL-3.0.

So the repository front door is a signpost, and the project's own homepage field points at docs.searxng.org rather than at a service. That is a deliberate choice about where the documentation lives, and it has a cost for a reader deciding whether to run this: nothing in the README says which search services are aggregated, how privacy is configured, or what the resource profile looks like. You leave the repository to learn what the thing is.

The version is not written in the packaging file

setup.py is short and does something worth noticing. It does not contain a version string. It imports VERSION_TAG and GIT_URL from searx.version, reads the long description from README.rst, and reads dependency lists from requirements.txt and requirements-dev.txt. The package name is searxng, the license is AGPL-3.0-or-later, and python_requires is >=3.10, with classifiers for Python 3.10 through 3.13.

Two consequences. Your package metadata depends on a module inside the application for its own version, and there are no GitHub releases to fall back on. And the URLs are read from the app's settings rather than hard-coded: url comes from get_setting('brand.docs_url') and the issue tracker from get_setting('brand.issue_url'). Branding edits therefore propagate into package metadata, which is convenient until you want the PyPI page to point somewhere else.

Every runtime dependency is pinned with two equals signs

requirements.txt is short and completely frozen. Every line is an exact version, no ranges anywhere:

certifi==2026.7.22
flask==3.1.3
jinja2==3.1.6
lxml==6.1.3
curl_cffi==0.16.3
valkey==6.1.1

The full list adds babel and flask-babel for translations, pyyaml, python-dateutil, markdown-it-py, msgspec, typer, isodate, whitenoise, pygments, and typing-extensions. Because the pins are exact, a rebuild months from now needs those exact releases to still resolve, and nobody picks up a patched release of flask or lxml until somebody commits a new number. That is a real operational choice: reproducibility in exchange for patch lag, with the maintenance work landing on whoever runs the instance. Note also that setup.py reads requirements-dev.txt as well, so a development install pulls the development set too.

curl_cffi instead of requests, and Valkey for state

The dependency list tells you the deployment shape. This is a Flask application rendering through Jinja2, serving its own static assets through whitenoise, and translating through babel with flask-babel on top. The installed console script is searxng-run, wired to searx.webapp:run, and the classifiers say WSGI :: Application, which means you put it behind a WSGI server you choose.

The outbound client is the interesting entry. requests does not appear in the pinned list, and curl_cffi does, so the HTTP calls this engine makes to other search services go through a curl based client rather than the requests library most Python code reaches for. Separately, valkey is pinned, which puts a Valkey compatible key value server in the picture, and typer is pinned, which suggests a command line interface.

The consequence for an operator: this is not a static site and not a single binary. It wants a Python environment, a WSGI server, and a state store you run.

Three language toolchains for one Python application

Count the ecosystems in the top level listing. Python is obvious: setup.py, requirements files, a Makefile, an extensionless manage script, and mise.toml for pinning tool versions. Node appears as a .nvmrc file and a package.json that declares no dependencies at all, whose single script is rm -Rf node_modules package-lock.json. That manifest exists to clean up, not to install anything.

Then there is Go. go.mod declares module searxng.org/devtools, requires go 1.24.5, and carries one tool directive, mvdan.cc/sh/v3/cmd/shfmt, which is a shell formatter, with its own dependency tree of renameio, go-internal, golang.org/x/sys, golang.org/x/term, editorconfig, and sh v3 itself.

So contributing means a Python environment, a Node install, and a Go toolchain, where the Go part exists to format shell scripts. Checks are split to match: pyrightconfig.json for types, .pylintrc for lint, .coveragerc for coverage, and .yamllint.yml for YAML.

Translations live on Codeberg, and there is an AI policy file

The README carries a translation badge, and its target is translate.codeberg.org/projects/searxng/, not GitHub. The tree agrees: a .weblate directory and babel.cfg. That means localization for this project is a Weblate project hosted on a different forge.

Next to CONTRIBUTING.rst and SECURITY.md there is an AI_POLICY.rst at the root. It is a separate file from the contributing guide, and nothing in the README mentions it.

Taken together with the Matrix room as the only contact channel named, the picture is a project that keeps its policy in files and its community in chat. For a user, none of that changes the engine; for a contributor, it decides how much of the process you can see before you start.

AGPL-3.0 over a WSGI app you run, not a service you call

The license is GNU Affero General Public License, AGPL-3.0-or-later, and the SPDX header at the top of the README says or-later, which matters if you hold an older copy of the license text. The project classifies itself as Development Status :: 5 - Production/Stable, which is a statement the maintainers publish about their own package rather than an independent assessment.

The delivery shape is deliberately unglamorous. There is a container/ directory and a .devcontainer/ for editor environments, but the install path on record is a Python package you can put behind any WSGI server, and the documentation site owns the install decisions. Combined with the AGPL network clause, that gives a clear shape for an organisation: modify it and expose it to colleagues over a network, and the source obligation applies. Run it unmodified for yourself and that question does not arise.

Editorial conclusion

SearXNG fits a self-hoster who wants aggregation under their own roof, who is comfortable maintaining a Flask application and a Valkey-compatible store, and who reads the settings guide before touching anything. It is a poor fit if you need a turnkey public instance, a documented command to copy, or an install that picks up security updates on its own. Before you deploy, read the Installation and Configuration guides, decide who applies the pinned dependency updates, and confirm the engines you need are configurable in the settings you are given.

Frequently asked questions

Official sources

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