Self-host SearXNG on a VPS that asks for nothing

SearXNG is a metasearch engine: it forwards your query to other search services and merges what comes back. The project calls it "a free internet metasearch engine which aggregates results from up to 269 search services. Users are neither tracked nor profiled" (SearXNG documentation). None of that needs a server. Not wanting to use a stranger's instance is what needs a server.

Self-hosting moves the trust, it does not delete it. On a public instance "the user of the public instance does not know whether their requests are logged, aggregated, and sent or sold to a third party", while on your own "everything is in their control: the source code, logging settings and private data" (Why use a private instance?). What no config file fixes is the layer underneath: the address your queries leave from belongs to a machine somebody rents to you, under a name almost everywhere.

Which is what this host is for. A Servury account is a 32-character credential: no email, no phone, no name, no ID. Payment is Monero, Bitcoin and six other coins processed on Servury's own nodes, cards through Stripe, or cash by mail. servury.com keeps no access logs and runs no analytics. More on the no-KYC VPS page.

The hardware question is easy. There is no index to size a disk for: SearXNG keeps no crawl of its own, and upstream publishes no hardware floor in its installation guide. You are sizing two containers, a Python web service and Valkey. A personal instance is a small job: the two containers idle in a few hundred megabytes, and a 2 GB plan carries them with room for a reverse proxy, WireGuard and a Tor daemon beside it. Blackbox Core, 2 vCPU and 4 GB for $9.99, is more than the job needs, and the standard line covers 8 locations if you would rather sit near yourself than near Montreal.

The egress question is the real one. Engines judge the address requests come from, and hosting ranges start out suspect. Google is actively blocking SearXNG instances, and once an engine starts challenging your address, more retries are often just self-harm. A refusal benches that engine on a timer set under search.suspended_times in the upstream settings.yml, from 180 seconds to 15 days; the published settings page still lists older figures. The one lever you get is outgoing.source_ips, which takes IPv4 or IPv6 addresses in plain or CIDR form (outgoing settings). A Blackbox ships one IPv4 plus a routed /64 to spread across; the standard line is IPv4 only. No honest page promises that this changes an engine's mind.

Where the machine sits matters most when the instance shares a box with something that holds secrets. Blackbox guests run under AMD SEV-SNP with debug disabled, carry no guest agent, and can hand you a CPU-signed attestation report before you type a disk passphrase: see the SEV-SNP VPS page and the measured boot guide. The onion front above is the standard two-directive setup from the Tor Project onion service guide. The everyday companions are a tunnel and a resolver: WireGuard so only your devices reach the instance, Pi-hole for the DNS beside it. A search instance is an ordinary workload under the terms. Cryptocurrency mining beside it is not.