The Problem

Search engines track users, profile them, and filter results through opaque ranking. Organizations and individuals who need search without surveillance have few self-hosted options, and those that exist are usually single-engine proxies. SearXNG solves this by aggregating dozens of search backends behind one privacy-preserving interface.

What This Does

SearXNG is a Flask-based metasearch engine written in Python (403 files). It queries multiple upstream search providers — Google, Bing, Brave, DuckDuckGo, and hundreds more — normalizes their results, and renders them through a client-side TypeScript frontend in client/simple/src/js/. The server never stores user queries or sets tracking cookies.

The repo is a full fork of searxng/searxng (36k+ stars upstream), so it carries the complete production stack: Docker deployment (container/docker-compose.yml), admin documentation (docs/admin/), a plugin system, and per-engine adapters under searx/engines/.

How It Is Wired

Execution begins at the Flask app in searx/webapp.py (not listed in the entry-point scan, but the searx/ package is the server). A request flows: Flask route → searx/search.py search orchestration → engine adapters in searx/engines/ → outbound HTTP to upstream providers via searx/search.py's network layer. The client side starts at client/simple/src/js/index.ts, which bootstraps the TypeScript router and plugin system (Plugin.ts, router.ts).

Key files and their responsibilities:

  • searx/search.py — search orchestration; central hub for query routing, result merging, and category filtering. Highest blast radius: every engine passes through it.
  • searx/engines/ — per-engine adapters (one file per provider, e.g. google.py, bing.py). Each defines a request() and response() function.
  • searx/enginelib/ — engine base classes and registry.
  • searx/settings.yml — main configuration (server, engines, plugins, outgoing proxy settings).
  • client/simple/src/js/ — frontend logic: search.ts, results.ts, autocomplete.ts, preferences.ts.
  • container/docker-compose.yml — production deployment with Redis/Valkey for caching and rate limiting.
  • searx/plugins/ — plugin hooks (calculator, infinite scroll, map view).

The module graph shows searx/search.py as a hub with many dependents; changing result-merging semantics there affects every engine and the frontend's results.ts rendering. No circular dependency issues are evident from the file structure.

How To Use It

Setup (from container/docker-compose.yml and container/dist.dockerfile):

git clone https://github.com/moses-y/searxng
cd searxng
cp container/.env.example container/.env
docker compose -f container/docker-compose.yml up -d

Configuration: edit container/settings.template.yml (copied to searx/settings.yml at build) to enable/disable engines, set server.secret_key, and configure Redis under redis:.

Running it: the Docker compose file exposes the service on port 8080 by default. For development, the Makefile provides targets (e.g. make run), and the Python entry point is searx/webapp.py invoked via python -m searx.webapp.

Real-World Use

A small team deploys SearXNG behind nginx (docs/admin/installation-nginx.rst) with Docker. They disable Google in settings.yml, enable Brave and Mojeek, set a shared secret_key, and point the limiter at a Valkey instance. Users hit the instance through a VPN, get aggregated results with no cookies, and the team retains full control over which engines see queries.

Code Health & Issues

The repo is well-maintained: 47 test files, 189 documentation files, GitHub Actions CI for container builds, integration tests, and l10n, plus a LICENSE (AGPL-3.0) and SECURITY.md. No structural red flags. The ai-policy.yml workflow and AI_POLICY.rst suggest the project has explicit rules about AI-generated contributions. One observation: go.mod at the root is unexpected for a Python project and may be a leftover or tool dependency — worth confirming before relying on it.

The Bottom Line

This is a production-grade, actively maintained metasearch engine with solid documentation and deployment tooling. The trade-off is operational: it's a real service to host, not a library, and engine adapters break when upstream providers change their HTML. Use it if you need self-hosted, privacy-preserving search and can commit to maintaining the infrastructure.