Deploy and Host search2ai on Railway

search2ai is a self-hosted search gateway for AI agents. It exposes unified web search, news search and page extraction over a REST API and a remote MCP server, tries your configured providers (Search1API, Tavily, Serper, SerpAPI, Brave, Exa, SearXNG and more) in order with automatic fallback, and also offers drop-in compatible endpoints for Tavily, Exa, SearXNG, Search1API and Firecrawl clients.

About Hosting search2ai

This template runs:

One stateless search2ai service built from the official repository Dockerfile (Node 22), listening on port 3014 behind a public Railway domain
No database and no volume: all configuration comes from variables
A generated gateway key in AUTH_KEYS (format sk- plus 48 hex characters)
Bearer authentication enforced on /v1/search, /v1/news, /v1/crawl, /mcp and all /compat endpoints; only the info endpoints (/, /v1/health, /openapi.json) are public

After deploy:

Open the search2ai service, go to Variables and copy the value of AUTH_KEYS. Send it as Authorization: Bearer with every request.
Add at least one search provider key (for example SEARCH1API_KEY, TAVILY_KEY or SERPER_KEY) in Variables, or set SEARCH_SERVICE to keenable for keyless, IP rate-limited search. Without any provider, search requests return a 503 "no provider configured" error.
Check https://YOUR-RAILWAY-DOMAIN/v1/health to see which providers and fallback chains are active.
Test a search: POST https://YOUR-RAILWAY-DOMAIN/v1/search with JSON body {"query": "railway"} and the Bearer header.
Connect an MCP client (Claude, Cursor and others) to https://YOUR-RAILWAY-DOMAIN/mcp using the same Bearer header.
To give out more keys, append them to AUTH_KEYS separated by commas and redeploy.

Common Use Cases

Give AI agents and MCP clients one authenticated search, news and crawl tool backed by several providers
Replace direct Tavily, Exa or SearXNG API usage with a self-hosted gateway that adds fallback between providers
Centralize search provider API keys on a server instead of distributing them to every client
Feed retrieval-augmented generation pipelines with search results and extracted page content

Dependencies for search2ai Hosting

Source: the fatwang2/search2ai GitHub repository (MIT license), built from its Dockerfile
At least one search provider: an API key for Search1API, Tavily, Serper, SerpAPI, Brave, Exa or Google, a SearXNG URL, or a keyless provider (keenable, parallel) in SEARCH_SERVICE

Deployment Dependencies

https://github.com/fatwang2/search2ai
https://s1.dev/open-source/search2ai
https://github.com/fatwang2/search2ai/blob/main/.env.template (full list of supported variables)

Implementation Details

Built from the repository Dockerfile because no official prebuilt image is published.
PORT is pinned to 3014 and the public domain targets that port; the healthcheck uses /v1/health.
AUTH_KEYS is optional upstream (the gateway is open when it is empty); this template always generates a key so a fresh deployment is never an unauthenticated public API.
Provider keys are optional so the service deploys in one click; add them later in Variables. Other supported variables (GOOGLE_KEY, GOOGLE_CX, FIRECRAWL_KEY, MAX_RESULTS, CACHE_TTL and more) can be added from the upstream .env.template.

Why Deploy search2ai 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 search2ai 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.