SearXNG: web search your agent owns

The question this guide answers was asked in public and never really answered. Under the SearXNG thread on Hacker News, a commenter called goodroot wrote: “This appears to be a key tool for providing search to local models. I’m curious what setups folks use to provide this functionality.” So: start the way the project’s own compose file tells you to, with the config directory bind-mounted and Linux capabilities dropped.

Here is what is happening. Docker created ./searxng for you, owned by uid 977 — the container’s own user — with mode 755. The entrypoint then tries to write the default config into it as root. Normally root walks through a permission check like that without noticing, because root holds the DAC_OVERRIDE capability. The quickstart drops it. You can watch the capability do the work:

Write the config file yourself, before the first start, and mount that single file read-only. A read-only bind mount cannot be chowned, so the file stays yours.

• use_default_settings: true makes your file an overlay. SearXNG merges it over its own defaults, so six lines is a complete configuration and upgrades do not silently revert to a stale copy of a thousand-line template.
• limiter: false turns off the bot-protection rate limiter. It exists to stop strangers hammering a public instance; yours is bound to 127.0.0.1 and its only client is your own agent, which looks exactly like a bot and would be throttled.
• The image tag is pinned to a date. SearXNG has no release tags at all — the repository had commits on 1 and 2 November 2026 and not a single version tag — so the Docker tags are YYYY.M.D-<short-sha> and there can be several in one day. latest means “whatever landed most recently”.

Visit http://127.0.0.1:8080/ over an SSH tunnel and it is a search engine, with a preferences page and no account. The part that matters for an agent is the JSON.

Read that last field. It was in the very first query of the run, and it is the beginning of the real story.

mcp-searxng puts an MCP server in front of the JSON API. Version 2.9.0 shipped on 27 October 2026 and needs Node 22 or newer.

Four tools arrive with it: searxng_web_search, searxng_search_suggestions, searxng_instance_info, and web_url_read, which fetches a URL and hands back the text. Search and read, which between them is most of what an agent wants the web for.

One thing nobody mentions: a default search is enormous. These are the payloads the agent actually receives, three calls back to back on the same query.

Then the default call ran five more times a few minutes later and returned 9,041 characters, repeatably, varying by 17 characters across the five. Same query, same config, a third of the size — what changed was which engines happened to answer. So the only payload size you can count on is the one you impose yourself. An agent that searches six times during a task has bought back thirty thousand tokens of room to think in.

Everything above you could do on a laptop. This is the part you cannot. Go back to unresponsive_engines: SearXNG keeps error statistics at /stats/errors, and the picture there was worse than one flaky engine.

DuckDuckGo fails 100% of the time from this box. Next question: which engines were actually carrying the results, across three queries?

The config reports 261 engines enabled. Fifty-six are in the general category, and of those exactly three are real web search engines by default — brave, duckduckgo, google cse — the rest being dictionaries, Wikipedia and currency converters. Two of the three were dead. So this metasearch engine was one search engine wearing a trenchcoat, and nothing said so: the page looked fine and returned twenty results a query. It is what baranul was complaining about in that same thread when he wrote that SearXNG “needs better quality control”, and what vimredo meant about hosted instances giving “results that were complete garbage.”

An agent with a shell on the box can do something about it, because the diagnosis is three commands and the repair is a config file it can edit and a container it can restart. It enabled eleven more general engines and measured which ones answer a datacenter IP.

The four that carried real volume went into settings.yml and the rest were switched off, because an enabled engine that never answers costs you latency and nothing else. wiby returned a single result across three queries and did not earn its place.

Twice the results from five independent sources, for twice the wait. That trade is real and it might not be the one you want: a search that takes 1.2 seconds is a second your agent spends not thinking. If you care more about latency than coverage, keep bing and seznam and stop there.

What makes this your agent’s job rather than yours is that it is never finished. Engines rot. brave was fine in the first query of the morning and rate-limited by the afternoon, and it was the benchmarking in this guide that got it suspended. A box that can read its own error statistics, edit its own config and restart its own container can keep a search engine healthy on a schedule. You cannot, because you will not notice: the failure mode is not an error page, it is quietly getting fewer answers.

Two other honest edges. brave is still suspended in the “after” numbers, so the real ceiling is six engines rather than five. And denysvitali, who maintains a competing MCP server for SearXNG, put the general limitation better than this guide can, in that same thread: it “works very well, until you get rate limited by the providers.” Nothing here makes you immune to that. It moves the problem somewhere you can see it and fix it, which is different from solving it.

Sources. The question, the JSON-format detail and the quoted limitations come from Hacker News, 3 July 2026. Release details are from mcp-searxng v2.9.0 and the SearXNG commit log. Every command and every number above came off one box on 3 November 2026.