Know the request path
Your instance sends queries to configured engines and returns results to the user. Upstreams may restrict or rate-limit requests. Self-hosting does not guarantee every search engine will accept the traffic indefinitely.
Keep the interface controlled
Use HTTPS and decide whether the instance is private, authenticated or public. A public search endpoint needs abuse controls and capacity planning. Protect settings and administrative access separately.
Minimise query retention
Search queries can be sensitive. Review reverse-proxy, application and system logs and avoid keeping query strings without a defined need. Explain external result and image requests that can contact other parties.
Maintain and observe
Track supported releases, response errors and upstream changes. Restrict expensive requests and keep a clear fallback for unavailable engines. Back up configuration without exposing secret tokens.
Make the container and proxy boundaries visible
A supported container deployment still needs a persistent configuration, private secrets and an intentional network exposure. Put the application behind an appropriate TLS proxy and review rate limits before opening it to the public. Check the current official deployment instructions rather than reusing an old compose file indefinitely.
Official documentation: SearXNG container installation
Separate search from an AI layer
If you add a tool such as Perplexica or another model-assisted interface, the query and retrieved text may also be sent to a model provider. Review that new data path and its cost, authentication and retention. A private metasearch instance does not automatically make the added AI service private.
Choose who may use the search endpoint
A private SearXNG instance can use a tunnel or an authenticated access boundary. A public instance needs a different capacity and abuse plan. Its upstream search engines still receive requests from your hosting path and can return limits or CAPTCHAs; a new IP is not a guaranteed bypass. Use the supported container instructions, persist settings and generate a private instance secret. Keep the application behind the intended TLS proxy.
- Choose a small initial set of engines you are permitted to query.
- Keep configuration/secrets off the public file path.
- Check whether optional external image or icon fetching changes the privacy boundary.
Official documentation: SearXNG container installation
Make the limiter see the real client
Current SearXNG limiter documentation uses Valkey for dynamic state. Configure it privately and enable the limiter when that is part of the instance design. Proxy trust is critical: if every visitor appears to be the proxy, one visitor can affect everyone’s limit; if arbitrary forwarded headers are trusted, a visitor can misrepresent an address. Set trusted proxy ranges to the actual deployment, then test the resulting behaviour before publishing the endpoint.
Official documentation: SearXNG limiter and trusted proxies
Test browser use and an engine failure
Run an ordinary search, a query containing non-ASCII text, a search against one configured engine and an intentionally unavailable engine. Verify that a failed upstream does not make the whole service unusable. Add the tested instance as a browser search provider using that browser’s supported settings. For an AI layer such as Perplexica, separately review authentication, model-provider data sharing, spending limits and source attribution: the metasearch frontend does not control those added services.
- Check result links and redirects from a fresh browser profile.
- Check whether search terms appear in proxy access logs or analytics.
- Test the private access boundary from an unauthorised network.
Repair upstream failures without evading restrictions
When only one engine fails, inspect its error and current adapter compatibility before changing the whole deployment. A CAPTCHA or rate-limit response is an upstream policy signal, not permission to automate around it. Repeated HTTP429 responses can also come from your own limiter/proxy configuration. Keep a fallback engine and an update rehearsal, preserve the small configuration backup, and avoid permanent query logs simply because troubleshooting once required them.