SearXNG as a Private Search API for LLM Agents: What It Is, What It Is Not, and How to Run It

SearXNG has become a standard building block in local and private LLM stacks. Tens of thousands of GitHub stars, Docker one-liners, and built-in integrations in agent frameworks make it look like a drop-in privacy tool. That picture is only half right. The other half is how it actually works, where it breaks, and why it matters now that Google is closing its programmable search API.

What people think it is

Common descriptions call SearXNG a privacy-respecting search engine that does not log or monetize queries. Developers recommend it for de-Googling, for feeding local AI agents without a commercial API, and for keeping search traffic inside their own network. Public instances get treated as ready-made services, and self-hosting is seen as the ultimate privacy safeguard.

The mental model is simple: send a query, get private results, leave no footprint.

What it actually is

SearXNG is a metasearch engine, not a search engine with its own index. It is an actively maintained fork of the original searx project. When a query arrives, the instance fans it out to a configurable set of upstream engines (Google, Bing, Brave, Startpage, Wikipedia, and others), strips identifying headers and cookies, merges and re-ranks the responses, and returns one results page. It never crawls the web itself.

Privacy comes from architecture, not from a policy promise:

  • Upstream engines see your SearXNG server’s IP address and a generic request, not your browser fingerprint, cookies, or home network address.
  • The code is built to avoid query logging and user profiling.
  • JavaScript and cookies are optional, and results can be served as HTML or JSON.

There is no single service called “the SearXNG.” The ecosystem is a set of public instances run by volunteers and private instances run by individuals and organizations. On a public instance you trust the operator with your query text. On a private instance you control the code, the config, and the access logs.

The project is free software under the AGPL-3.0 license, written mainly in Python, and usually deployed in containers alongside Valkey or Redis.

Why it matters now: the Google API clampdown

Google’s Custom Search JSON API was the default programmatic route to web results. It is closed to new customers, and existing customers lose it on January 1, 2027. Google points existing users to Vertex AI Search, which is a different product aimed at searching a defined set of sites rather than the public web. For full-web search, Google says it has a solution “for those requiring our entire index,” but it is not self-serve. Brave also changed its Search API in February 2026. New sign-ups no longer get the old free plan (2,000 requests per month). They get prepaid credits instead: the current Search plan costs $5 per 1,000 requests and includes $5 in free credits each month, with a credit card required. Brave has said that accounts already on the old free plan keep it, so existing users are unaffected, but new projects should budget for metered billing.

For local LLMs, RAG pipelines, and agent frameworks that need live web results, that leaves paid SERP scrapers (recurring cost, terms-of-service friction, another dependency) or running your own aggregation layer. A self-hosted SearXNG instance with JSON output is the practical version of the second option.

Turning it into an API

A default install serves only HTML. To use it programmatically:

  1. Add json to the output formats in settings.yml, next to html:
search:
  formats:
    - html
    - json
  1. Restart the instance, then test it:
curl "http://localhost:8080/search?q=test&format=json"

A 403 Forbidden response means JSON output is not enabled yet.

  1. If your client is another container or machine, check the reverse proxy, network binding, and the instance’s bot-detection limiter. Do not disable the limiter on an instance that is reachable from outside your network. Keep the instance on a private network or behind authentication, because SearXNG does not provide authentication itself.

Operational realities

Production use surfaces problems that overviews skip.

Upstream blocking. Scraped engines often return CAPTCHAs or rate limits when queried from datacenter IP ranges. SearXNG detects this and suspends the affected engine for a cooling period. If only a few engines are enabled, a burst of traffic can leave you with almost no results.

Official API quotas. Adding an official API such as Brave’s improves stability, but brings rate limits (the Search plan allows 50 queries per second) and metered cost, since credits run out. Parallel searches from an automated agent can hit those limits quickly, and the engine will return empty results until the quota resets.

Configuration pitfalls. Some engines ship disabled by default. Supplying an API key does not automatically enable the engine, so you also have to turn it on explicitly. Outdated configuration keys are ignored silently, which makes problems slow to diagnose.

Operational overhead. Containers, secrets for API keys, engine health after network changes, and fallback providers all need maintenance. Failures of minor engines often appear in logs without breaking search, but they need monitoring.

Limitations

Because SearXNG has no index of its own:

  • Result quality and freshness depend on the health of the upstream engines.
  • One busy server IP is an easy target for rate limiting and CAPTCHAs.
  • There is no personalization or long-term history to improve relevance.
  • Public instances are fragile under heavy abuse, and a private instance concentrates all your traffic on one IP.
  • High volume needs engine tiering, fallback chains, and traffic management.

SearXNG is an excellent privacy proxy and aggregation layer. It is not a replacement for a dedicated enterprise search index or a guaranteed high-volume SERP API.

Wiring it into an LLM gateway

LiteLLM supports SearXNG as a search provider. You define a search tool in the proxy config, set search_provider: searxng, and point api_base at your instance. The proxy then exposes the tool at /v1/search/<search_tool_name>. See the LiteLLM SearXNG docs for the exact config.

search_tools:
  - search_tool_name: searxng-search
    litellm_params:
      search_provider: searxng
      api_base: http://searxng:8080

Two details from the LiteLLM docs and community reports:

  • SearXNG returns a fixed page of results (about 20 by default), and max_results is not supported for this provider. Provider options such as categories, engines, language, pageno, and time_range are.
  • The web-search interception feature, which lets models without native search call it through the gateway, may read the SEARXNG_API_BASE environment variable rather than the api_base in your config. Set both and verify against your LiteLLM version.

Any OpenAI-compatible gateway, agent runtime, or workflow tool can use the same JSON endpoint, so you can swap or scale the search backend without changing the applications that call it.

A reasonable production layout:

  1. Local or self-hosted models behind a gateway.
  2. SearXNG as the private multi-engine search backend.
  3. A mix of official APIs and scraped engines so that no single provider is a point of failure.
  4. Rate-aware routing so bursts from agents do not get your primary engines suspended.

Key takeaways

  • SearXNG is a metasearch proxy that queries other engines for you. It has no index of its own and does not make you anonymous.
  • A self-hosted instance moves the identity footprint from individual browsers to a server you control, along with the logging policy and the operating cost.
  • It must be switched to JSON output before agents can use it, and it should stay on a private network or behind authentication.
  • Expect CAPTCHAs and rate limits on scraped engines. Plan fallbacks and rate-aware routing.
  • With Google’s Custom Search JSON API ending on January 1, 2027 and Brave’s free plan closed to new sign-ups, a self-hosted JSON search endpoint is one of the few remaining low-cost ways to give local agents live web access.

Get the next one in your inbox

Enjoyed this? I write about local AI, self-hosting, and cloud cost ninjutsu. Join the Ninja Dispatch for occasional, high-signal notes. No fluff.