Search without
being the product.

Commercial search is an advertising business wearing a search interface. Results are shaped by who paid, queries are attached to a profile, and the interface increasingly answers a question you did not ask. For technical work specifically, the good sources — documentation, source repositories, standards references — are frequently pushed below content optimised to rank rather than to be correct.

Existing self-hosted metasearch projects solve the privacy half but bring a Python runtime, a dependency tree and an ongoing maintenance surface. For something you want to run permanently on a small box, that is a poor trade.

Ultra Search fans a query out to seventeen engines concurrently — Google, Bing, Brave, DuckDuckGo, Startpage, Qwant, Ecosia, Mojeek, Marginalia, Stract, Yep, RightDao, plus dedicated news, scholar and video sources — and merges the responses. Because no single upstream sees the full picture and none of them sees a user identity, federation delivers both better coverage and privacy as a side effect of the architecture.

Results are then re-ranked locally using signals the engine controls rather than accepting any upstream's ordering. On top of that, a post-search layer scrapes the sources that matter for technical queries — docs.rs, GitHub, MDN, Stack Exchange — and lifts the relevant fragment into the result, so the answer appears without a click.

A significant fraction of queries never need an upstream at all. Eleven instant-answer modules handle arithmetic and unit conversion, currency, dictionary and thesaurus lookups, timezone conversion, weather, IP and user-agent inspection, colour picking and encyclopaedia summaries — computed in-process, returned immediately.

Rendering uses compile-time HTML templating, so pages are assembled without a template engine at runtime and without shipping a client-side framework. The whole service is one statically-linked binary and a TOML config.

1. Seventeen scrapers that all break independently Every upstream changes its markup without notice. Each engine is an isolated module with its own parser, so a break degrades that one source instead of failing the query — the user still gets results from the other sixteen.
2. Latency is bounded by the slowest upstream, unless you design for it Queries are issued concurrently with per-engine timeouts, and results stream as they arrive rather than blocking on a full set. One slow engine cannot hold the page hostage.
3. Merging rankings that have no common scale Each engine returns its own ordering with no comparable score. Combining them into one list that is better than any individual source — rather than an average that is worse than all of them — is the genuinely interesting problem in metasearch.
4. Scraping upstreams that don't want to be scraped User-agent rotation and careful request shaping are needed to keep engines responding, without crossing into abusive volume.
5. Sanitising everything that comes back Content from seventeen third parties is rendered into a page. All of it passes through HTML sanitisation, because a metasearch engine that faithfully renders whatever an upstream returns is an XSS vector by design.

A search service that runs on a small VPS or a home server, starts instantly, uses very little memory, and needs no database, migration or scheduled job. Deployment is copying a binary.

For technical queries the federated result set plus source-aware enrichment is genuinely better than any single engine — the docs.rs or MDN answer surfaces directly instead of being three clicks past a content farm.

The engineering value beyond the tool itself is the pattern: fan-out to unreliable third parties, degrade per-source rather than globally, normalise heterogeneous responses, and ship it as one artefact with no operational tail. That is the same shape as most enterprise integration work, done in the open.