SearXNG combines outside indexes instead of building one
SearXNG sends a query to selected search services and merges the returned links into one results page. It does not crawl the web or maintain a general index. That distinction is the whole product decision: you gain control over the front end, enabled engines, cookies, and logging, while still depending on Google, DuckDuckGo, Startpage, Brave, and other upstream services for results.
The project says users are neither tracked nor profiled by SearXNG. An operator still has work to make that true in practice. The reference settings enable an image proxy and a bot limiter, while the Nginx guide explains how to disable access logs for better privacy. A careless reverse proxy can preserve identifying logs or pass the wrong client address. Self-hosting moves trust from a public search site to whoever administers this instance.
Compose brings up the app and Valkey together
The recommended container path uses Docker or Podman and a supplied Compose template. The documented stack starts a core service on port 8080 and a Valkey service on port 6379. Two mounted locations preserve state: /etc/searxng for configuration and /var/cache/searxng for cached data. Operators copy an environment example, edit it, create core-config/settings.yml, then pull new images and review changed templates during updates.
The manual route is more involved. It creates a separate user, builds a Python virtual environment, installs dependencies, and sets up an application server. A minimal configuration must replace server.secret_key. Public deployment adds Nginx or another reverse proxy, TLS, forwarded-address handling, and service management. The limiter requires Valkey. None of this is unusual for a web service, but the short root README deliberately hands these details to the admin guide.
What happened when we ran it
Our sandbox classified the checkout as a Node npm project and completed its install step in 10 seconds. It installed 0 packages and left 29 MB on disk. The repository contained 992 files, about 64,199 lines of source, and occupied 19.8 MB when checked out. It had 6 CI workflow files, a tests directory, and no root Dockerfile, though the repository contains container files under a dedicated directory.
There was no npm build script or target, so the build step was skipped. The same was true for tests: no npm test script or target was available, and no tests ran. Npm audit reported 0 known vulnerabilities across critical, high, moderate, and low severities. These findings describe the Node-oriented harness at commit d226b78. They do not validate the Python application, its own test suite, a container boot, or a live search query.
Upstream CAPTCHAs can remove engines overnight
A metasearch instance is only as useful as the providers willing to answer it. Issue 6596 reports DuckDuckGo returning a CAPTCHA on commit d226b78, the same commit in our sandbox. The reporter found that changing header order affected the response. Issue 6520 reports repeated Startpage CAPTCHA redirects with a 3,600-second suspension. Issue 6570 says Google's workaround using a Nokia user agent stopped returning results.
Those are separate reports from August 2026, and they do not mean every SearXNG engine failed. They show the recurring operational risk: providers can change bot detection without coordinating with the project. Issue 6584 adds a startup case where Wikidata returned 403 and Brave returned 429 in the official container setup. An operator should enable several useful engines, watch error rates, and accept that the result mix can change after an upstream response rule changes.
Public service requires abuse controls and IP planning
A private household instance has a smaller abuse surface than an open public one. Every query leaves the server's IP, so many users can concentrate traffic and trigger provider limits. The included limiter reduces automated abuse, but it brings a Valkey dependency and needs correct client-IP information from the proxy. Exposing the bare application port without that design is a poor production shortcut.
The API and HTML interface also inherit the same engine health. A 200 response from your SearXNG server does not guarantee every requested provider contributed a result. Applications should tolerate partial engine failures and avoid promising complete coverage. Search quality will vary with the enabled engines, their regional behavior, language settings, timeout policy, and the server's reputation. We did not measure result quality or query speed in the sandbox.
August 2026 activity shows an actively maintained service
GitHub recorded the last push on August 29, 2026, with issue and pull request discussion continuing on August 30. The repository had 36,276 stars and 221 combined issues and pull requests when fetched. GitHub's latest-release endpoint returned 404, so a stale release tag is not being used here as a health signal. Current pushes and same-week engine reports provide better evidence of maintenance.
SearXNG is the strongest open choice for people who specifically want configurable metasearch and are prepared to operate it. Our 10-second npm step says almost nothing about that production burden because 0 packages were installed and the Python targets were outside the harness. Start with the official Compose layout, keep Valkey and proxy settings intact, test several engines from your real server IP, and decide whether occasional provider loss is acceptable before making it anyone's default search page.