SearXNG

Last reviewed Aug 24, 2026 · 649 words

SearXNG puts a search box on your own server that queries Google, Bing, DuckDuckGo, Wikipedia, and 70-odd other engines simultaneously, merges the results, and hands them over with no tracking, no profile, no ad auction, and no search history stored anywhere. It's the rare privacy tool with an upgrade attached: multi-engine results are genuinely good, and bang shortcuts (!yt, !gh, !w) make it faster than the search engines it replaces. Running it is easy; running it well is three configuration decisions and one browser-integration session.

The install, and the key you must change

services:
  searxng:
    image: searxng/searxng:latest
    ports:
      - "8080:8080"
    environment:
      - SEARXNG_BASE_URL=https://search.example.com/
    volumes:
      - ./searxng:/etc/searxng
    restart: unless-stopped

First boot writes settings.yml into the volume; before the instance goes anywhere near exposure, replace the default secret_key (openssl rand -hex 32 output) — it signs image proxy URLs and forms, and the default value is public knowledge. Set base_url to the real public URL or redirects misbehave. Formats note: enable the json format in settings if you plan to wire SearXNG into other tools — Open WebUI's web search integration expects it, and that pairing (private search feeding private AI) is one of self-hosting's best combos.

Private instance or public-ish: pick, then configure the limiter

A personal/household instance behind Tailscale or your proxy's auth is the sweet spot: you can disable the bot-detection limiter entirely (it exists to protect public instances from scrapers) and searches stay instant. If the instance is reachable by strangers, keep the limiter on with its Valkey/Redis backend — an open, unlimited SearXNG will be found by bots, hammered, and burn through the goodwill of the upstream engines on your IP's behalf. There's no good middle: exposed-but-unlimited is the one configuration to avoid.

When results vanish: the engine-rate-limit reality

The catalogue's listed con is the one operational truth to internalise: upstream engines rate-limit and CAPTCHA aggressive sources, and your server's IP is a single, easily-noticed source. When Google starts refusing your instance (it happens, especially from VPS IP ranges), SearXNG degrades gracefully — other engines keep answering — but result quality dips until the cooldown passes. Mitigations, in order of effort: rely on a broader engine mix rather than Google alone (the default mix is sensible; resist disabling everything but Google); prefer a home IP over a datacenter IP for the instance; and know that occasional engine suspensions are normal weather, not a broken install. The engines page in preferences shows per-engine status when you're wondering why a category went quiet.

Making it your actual default

The migration succeeds or fails in the browser, not the server. Desktop: add the instance as a custom search engine and set default (Chromium browsers pick up the OpenSearch descriptor from the instance page; Firefox needs the add-search-engine click). Mobile: Firefox accepts custom engines cleanly; iOS Safari can't set a custom default, so use a shortcut or a different browser. Then teach two habits: bangs for direct-to-site searches, and preferences → engines to tune your mix (turning on the dedicated categories — images, IT, science — is where SearXNG starts beating single-engine search rather than matching it). The de-Google map rates search as one of the highest-impact swaps precisely because it's the one you use fifty times a day.

What I'd do

Private instance on the home box, tailnet-only, limiter off, secret key rotated, JSON enabled and wired into Open WebUI, default engine on every browser and phone in the house, bangs in muscle memory within the week. Cost: 256 MB of RAM and one Sunday hour. Return: the single most-used service in the homelab, and a search history that exists nowhere at all.