Deploy and Host SearXNG on Railway

SearXNG is a free, open-source metasearch engine: it forwards a query to dozens of upstream search services, merges and re-ranks the results, and returns them without logging the query or building a profile. This template ships it as a working JSON search API — the endpoint an LLM agent, RAG pipeline or Open WebUI web-search backend actually calls — on one service, with the concurrency ceiling raised off its stock value of four.

About Hosting SearXNG

Two things decide whether a self-hosted SearXNG is usable as an API, and neither is visible until after the deploy.

The JSON API is off by default. SearXNG's own defaults set search.formats: [html], so /search?q=…&format=json answers 403 Forbidden on a stock instance — the exact call every agent framework makes. There is no environment variable for it: searx/settings_loader.py reads only SEARXNG_SETTINGS_PATH, so the format list can only be widened inside settings.yml. This template's image bakes formats: [html, json, csv, rss] into the settings file, and repairs the list in place if a volume from an earlier deploy still carries the stock value.

A stock instance serves exactly four concurrent searches, on any plan. The server is Granian, whose --workers defaults to 1, and the upstream image bakes GRANIAN_BLOCKING_THREADS=4. Four slots is the whole capacity; the fifth caller queues. A SearXNG request spends nearly all its time blocked on upstream engines, so the fix is threads rather than worker processes — measured on a 4-vCPU container against a deterministic 2-second search, 64 concurrent requests took 32082 ms stock and 2392 ms at 64 blocking threads, for +11 MiB of RSS. Reaching the same capacity with four worker processes instead cost 3.2× the memory (95.6 MiB → 307.9 MiB) and was no faster.

This template's entrypoint sizes the thread count from the container's own /sys/fs/cgroup/cpu.max rather than from nproc, which inside a container reports the host's core count. The reference deploy logs cpu=8 blocking_threads=64 — 16× the stock ceiling.

It also hands Railway's injected $PORT to the server, which the upstream entrypoint does not do (it maps only SEARXNG_PORT), and pins the upstream image to 2026.8.3-aa059419f instead of tracking a :latest tag that changes daily.

Why Deploy SearXNG on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying SearXNG on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

The API answers on the first deploy — format=json returns results instead of 403, with no config file to go and edit.
16× the concurrent searches — thread pool sized to the container instead of a fixed four.
One service to pay for — no Redis. SearXNG consumes a valkey/redis connection only through its limiter and bot-detection layer, and searx/limiter.py returns before installing anything while the limiter is off, so a private instance never touches one.
Pinned — the same SearXNG version on every deploy.

Common Use Cases

Search tool for an LLM agent — a JSON endpoint your agent can call for live web results, with no per-query search-API bill.
RAG retrieval front end — one HTTP call that fans out across dozens of engines and returns merged, ranked results.
Private everyday search — an ad-free, trackerless search page for a person or a small team.

Dependencies for SearXNG Hosting

SearXNG runs as a single service and needs no database. A volume at /etc/searxng (included) keeps settings.yml — and any engine changes you make in it — across redeploys.

Deployment Dependencies

SearXNG — upstream metasearch engine (AGPL-3.0)
SearXNG documentation — configuration and admin reference
bon5co/searxng-railway — the Railway-tuned image this template deploys, and the measurements behind it

Implementation Details

Open the public URL for the search UI. The API needs no further configuration:

# JSON results — works on the first deploy
curl 'https:///search?q=railway&amp;format=json'

# CSV and RSS are enabled too
curl 'https:///search?q=railway&amp;format=csv'

SEARXNG_SECRET is generated per deploy and SEARXNG_BASE_URL is wired to your Railway domain, so nothing needs to be filled in on the deploy form. The healthcheck is /healthz. Set SEARXNG_BLOCKING_THREADS to override the automatic thread sizing.

Engines, categories and languages are configured in /etc/searxng/settings.yml on the volume; restart the service to pick up changes.

One caveat worth knowing before you deploy, and it applies to every self-hosted SearXNG rather than to this template: several large engines block datacenter IP ranges. Measured from this template's own Railway deployment, brave, duckduckgo and startpage returned rate-limit or CAPTCHA errors while google cse returned a full page of results. Check /stats on your instance to see which engines are erroring, and disable or replace them in settings.yml.