SearXNG: The Self-Hosted Metasearch Engine That Searches Everything and Profiles Nobody

"DuckDuckGo asks you to trust a company not to log you. SearXNG asks you to trust yourself — because you own the only machine that ever sees the query."

Every search you type into a commercial engine is an entry in a ledger someone else keeps. Your location, your interests, the sequence of your curiosity, the 3 a.m. medical query — all of it becomes inventory. SearXNG (GitHub: searxng/searxng) is the open-source answer to that arrangement. It is a metasearch engine: it takes your query, fans it out across dozens of upstream search services, merges the results, and shows them to you — while tracking nobody and building no profile. As of August 2026 it carries roughly 33,000 stars, is licensed AGPL-3.0, is written in Python, and actively maintained. For a blog about software you run on your own hardware, it's the most philosophically pure entry in the whole stack: the only search engine where the query never has to leave your control. This is the honest breakdown — how metasearch actually works, the self-host versus public-instance trade-off that trips people up, what it really costs, and the one problem (upstream blocking) that no amount of configuration solves.

1. What SearXNG Is (and Isn't)

The crucial distinction, and the one most people get wrong: SearXNG is not a search engine in the Google sense. It maintains no index of the web. It doesn't crawl anything. It is a broker — it forwards your query to other search services and databases, then merges and de-duplicates what comes back. That architectural choice is the entire privacy mechanism. Because your queries are distributed across many upstream engines rather than funnelled into one, no single provider receives a complete picture of what you're looking for. There's no account, no persistent identifier, no behavioural profile being assembled — because from the upstream's perspective, requests come from an opaque proxy, not from you. What it isn't is a magic anonymity tool. It doesn't anonymise your network connection; your instance's IP still makes the requests. What it does is remove the identity from the query, which is a different and genuinely valuable thing. The project descends from the original searx, forked in 2021, with "NG" marking a generational cleanup of architecture and maintenance. It has been steadily modernised since, consolidating on in-repo container and Compose files (the separate searxng-docker helper was retired in early 2026).

2. How Metasearch Actually Works

Understanding the request path explains both the privacy properties and the failure modes. 1. You submit a query to your SearXNG instance. 2. The instance selects which engines to query based on your configuration and the selected category (general, images, news, science, files, and more). 3. It dispatches requests to those upstream services — potentially dozens in parallel. 4. Responses are parsed, normalised, de-duplicated, and ranked. 5. Merged results are rendered — often in under a second for healthy engines. Two consequences follow directly. Engine health is your problem. Upstream sites change their HTML constantly, and when they do, the parser for that engine breaks until someone patches it. This is why the project ships updates so frequently and why some engines in your list will periodically show errors. Result quality is a function of your engine selection. Enable too few and results are thin; enable a broken one and you'll see errors. Tuning which engines are active is the core operational skill.

3. The Privacy Argument, Made Precisely

It's worth being exact, because the marketing version of this argument oversells and under-delivers in both directions. What SearXNG removes: the persistent identity attached to your query. No account, no cookies for tracking, no query log tied to a person, no profile accumulating across sessions, no personalised filter bubble reshaping results based on what the engine thinks of you. The project's own commitment — "users are neither tracked nor profiled" — is a design constraint, not a privacy policy you're trusting someone to honour. What SearXNG does not remove: your instance's IP address still makes outbound requests. If you self-host on a home connection, your ISP sees you connecting to search providers, and a provider that wanted to could rate-limit or challenge that IP. Self-hosting moves the trust boundary to you, but it doesn't make the requests invisible. That's why the common recommendation is to run a private instance behind a VPN or Tor for outbound cover: you get unprofiled results and the requests don't originate from an IP tied to your identity. The alternative — using one of the roughly 70 well-maintained public instances — gives you crowd cover (your queries blend with other users') at the cost of trusting that instance's operator not to log. Neither is wrong; they're different threat models, and you should pick deliberately.

4. Self-Host vs Public Instance

This is the decision people actually face, so here it is plainly: Use a public instance if you want zero setup and are doing casual, throwaway lookups. It costs nothing, works immediately, and your queries blend into the traffic of everyone else on that instance. The catch is unverifiable trust: the operator could log you, and you have no way to prove they don't. Self-host if this is your daily driver. You trust nobody, because the only logs are yours — and you can turn them off. The trade-off is that every query now originates from a single IP, which makes you more individually identifiable at the network layer unless you add VPN or Tor egress. A reasonable middle path many people land on: a public instance for casual searches, a self-hosted instance on your tailnet (see the headscale piece in Related) for anything you'd rather not have logged at all. The two aren't mutually exclusive.

5. Engines and Categories: Tuning Result Quality

Out of the box, SearXNG supports a very large catalogue of engines — the docs reference figures in the hundreds — across categories including general web, images, news, science, files, social, and more. The admin interface lets you enable, disable, and weight them per category. Practical guidance: start narrow and expand. Enable a handful of reliable general engines plus one or two per specialty category you actually use. Watch which ones return errors over a week and disable the flaky ones. A shorter list of healthy engines gives better results than a long list where a third are silently failing. This is also where you decide your own bias profile. Want less reliance on any single big-tech index? Disable it and lean on independent crawlers. Want comprehensive coverage? Enable more. That configurability is a genuine freedom no commercial engine offers.

6. The Cost, Honestly

Software: $0, AGPL-3.0. Hosting: light. SearXNG is a Python web app; a small VPS ($4–6/month) or spare capacity on an existing Docker host handles a personal instance easily. If you already run a homelab, the marginal cost is essentially zero. Your time: low to start, low-but-nonzero ongoing. Initial setup is a container and a config file. Ongoing, you'll occasionally update (engine parsers break when upstream sites change) and prune engines that stop working. Note that the project ships rolling container images rather than formal version tags, so "stay current" means pulling periodically rather than tracking release numbers. The hidden cost: if you want outbound anonymity you'll want VPN or Tor egress, which is either a subscription or additional setup. Budget for it if it matters to you. Against the "free" commercial engines, the honest comparison isn't money — you're not paying for those either. You're paying with your data. SearXNG replaces that currency with a few dollars of hosting and a little maintenance.

7. Honest Limitations

• Upstream blocking is the unsolvable one. Search providers dislike automated queries and will rate-limit, CAPTCHA, or block your instance's IP. This is the single most common frustration and there is no configuration that fixes it — only mitigation (fewer engines, slower rate, different egress).
• No index of its own. Result quality and freshness are entirely dependent on upstream engines. If they degrade, so do you.
• Engines break. Parsers are coupled to other people's HTML. Expect periodic errors and occasional manual pruning.
• Self-hosting has a network-layer trade-off. Single IP, no crowd cover, unless you add VPN/Tor.
• Public instances require trust you cannot verify.
• Not a convenience-optimised product. No personalised ranking, no "did you mean" ecosystem polish, no image search as refined as the majors. Results are deliberately unpersonalised — which is the point, and also occasionally annoying.
• Rate limits apply. Hammer upstream engines and you'll get blocked faster.

8. Getting Started

``yaml services: searxng: image: searxng/searxng:latest container_name: searxng restart: unless-stopped volumes: - ./searxng:/etc/searxng ports: - "8080:8080" environment: - SEARXNG_BASE_URL=https://search.example.com/ ` Then: (1) edit settings.yml to set a secret key, (2) enable only the engines you actually want, (3) put it behind a reverse proxy with TLS, (4) decide whether it's public or private — and if private, restrict it to your tailnet or VPN rather than exposing it to the open internet. An open instance is a resource anyone can abuse, which will get your IP blocked.

9. SearXNG vs the Alternatives

| | SearXNG (self-hosted) | Google | DuckDuckGo | Startpage | |---|---|---|---|---| | Who sees your identity | only your server | Google, fully | DuckDuckGo | the proxy operator | | Profiles you | ❌ | ✅ (the business model) | claims not to | no personal profile | | Own index | ❌ | ✅ | mostly Bing | Google (proxied) | | Self-hostable | ✅ | ❌ | ❌ | ❌ | | Ads | none | many | some | some | | Personalisation | none (by design) | heavy | none | none | The defining difference is who holds the logs. Self-hosted SearXNG means only you can see your queries. DuckDuckGo and Startpage ask you to trust a company's policy. For a degoogling purist, that distinction is the whole point.

10. Who Should Run It

Run it if: you've accepted that "free search" is paid for in behavioural data and you'd rather not pay that way; you want reproducible, unpersonalised results for research; you want a private search gateway for a household or team; or you simply want the option of searching on infrastructure you control. Skip it if: you need the best possible result ranking and instant answers, you're unwilling to deal with occasional engine breakage, or you expect it to anonymise your network traffic (it doesn't — pair it with a VPN or Tor if that's the goal). For this blog's readers — already running Home Assistant, headscale, changedetection.io, and a Docker host — SearXNG is the piece that closes the loop on the outside world. Your documents are local, your photos are local, your network is private; now your questions are private too.

11. A Real Deployment Walkthrough

Step 1 — decide private or public first. This changes everything downstream. Private (tailnet/VPN only) is far less likely to get your IP blocked and is the right default for a personal instance. Step 2 — set a secret key. Generate a real random value in settings.yml. Default or empty keys are a real security problem on anything reachable. Step 3 — start with ~8 engines, not 80. Pick reliable general engines plus one each for images and news. Fewer engines means fewer breakages and less upstream load. Step 4 — put TLS in front. Even on a private instance, TLS is cheap and prevents credentials or queries crossing your network in the clear. Step 5 — watch for a week, then prune. Check which engines return errors and disable them. This single habit is the difference between an instance that feels reliable and one that feels broken.

12. Troubleshooting & Keeping Engines Alive

• "Engine X suspended" or CAPTCHA errors — upstream is blocking you. Reduce request rate, drop that engine, or change egress. This is the #1 issue and it's external, not a bug.
• Results feel thin — too few engines enabled, or your enabled ones are silently failing. Check the statistics page.
• Slow responses — too many engines queried in parallel. Trim the list; the slowest engine sets your latency.
• Works locally, fails through the proxy — SEARXNG_BASE_URL` mismatch. It must match how the instance is actually reached.
• Instance got blocked after going public — expected. Open instances attract abuse. Restrict access and the block usually clears with time.

13. The No-JavaScript Interface Is a Feature

Worth calling out because it's rare: SearXNG's no-JavaScript HTML interface is first-class, not an afterthought. The whole thing works with scripts disabled. That's deliberate — it keeps the attack surface small, loads fast, keeps the tool usable over Tor and on ancient hardware, and stays accessible to screen readers. In an era where a "simple" web app ships two megabytes of JavaScript to render a text box, a search engine that works perfectly with scripting off is a quiet statement of values. It also means the thing keeps working when a CDN is down or a script is blocked — which, for infrastructure you rely on, matters more than it sounds.

14. Responsible Use

A closing note that's easy to skip and shouldn't be: querying public search engines through SearXNG is the same activity your browser already performs, and the tool is entirely legitimate. But with that comes the operator's responsibility. Rate-limit sensibly so you're not hammering upstream services. Respect the terms of the sources you query. Don't use a self-hosted instance to circumvent access controls or lawful restrictions — that's not what it's for, and it will get your IP blocked and misrepresent the project. Used as intended, SearXNG is one of the few pieces of software that measurably reduces how much of your inner life is recorded — while giving you results that no algorithm has pre-filtered based on what it thinks of you. That's a rare combination, and it's why it has earned 33,000 stars.

15. Using the API for Automation

A capability that separates SearXNG from a purely interactive tool: it can return results as JSON, which turns your instance into a search API you own. That's useful in more ways than it first appears. Research scripts can fan out a query across every configured engine and collect de-duplicated results without negotiating API keys, rate limits, or per-call pricing with a commercial provider. Internal tooling can query your private instance rather than sending potentially sensitive lookups to a third party. And because it's your instance, the logging policy is whatever you decide it is. If you enable the API, though, treat it like the sensitive endpoint it is. An open instance with the JSON format enabled is an unauthenticated search proxy that anyone can script against — which is exactly how instances get rate-limited into uselessness. Restrict access, rate-limit, and keep it on a private network unless you deliberately want to serve the public. For most self-hosters the right shape is: API enabled, instance reachable only over a tailnet, and used by the occasional script. That gives you automation without turning your search engine into someone else's free infrastructure.

16. Keeping Engines Healthy Over Time

The operational reality nobody warns you about: engines break, and they break often. SearXNG works by parsing other people's HTML. When an upstream site redesigns, that engine's parser stops working until a fix ships. A long engine list therefore means a steady trickle of errors. A sustainable routine:

• Check the statistics page periodically. It shows which engines are failing. Prune the ones that are chronically broken rather than tolerating errors forever.
• Pull updates regularly. Because the project ships rolling images rather than version tags, staying current is the main fix for broken parsers. A monthly pull-and-restart handles most of it.
• Prefer quality over quantity. Ten healthy engines beat sixty where twenty are broken — better results, less upstream load, fewer CAPTCHA problems.
• Expect churn after upstream changes. If a major provider adjusts its markup, every SearXNG operator sees errors at once, and a fix usually lands quickly. Patience plus an update is usually the whole remedy.

This is the genuine maintenance cost of metasearch, and it's small but non-zero. Anyone promising a self-hosted search engine with zero upkeep is describing something else.

Related

• Headscale: The Open-Source Tailscale Control Server That Puts Your Mesh VPN Back in Your Hands — run SearXNG on your tailnet so only your devices can reach it.
• Traefik: The Reverse Proxy That Configures Itself While You Sleep — put TLS in front of your search instance without hand-editing configs.
• changedetection.io: Watch Any Web Page Change Without Telling a Third Party What You're Watching — the other half of private web interaction: watching pages, not just searching them.