Search1API as LobeHub’s search provider
Search1API is built into LobeHub as both a search provider and a page crawler. On a self-hosted deployment you point three environment variables at it and LobeHub's native Web Search starts finding current sources and reading the pages behind them.
What it turns on
Current sources in chat
LobeHub's Web Search skill finds live results instead of relying on what the model already knows.
Reading the result pages
Search1API also serves as the crawler, so LobeHub can pull the readable text of a result rather than working from the snippet.
No plugin to install
The provider slot already exists in LobeHub. Configuration is environment variables on the server, not a marketplace install.
Configure the server
Add these to the environment of your LobeHub server, then restart or redeploy so the process picks them up.
Server environment — bash
Worth knowing
This applies to self-hosted LobeHub. LobeHub Cloud manages its own search infrastructure, so these variables do not apply there.
Keep the key on the server. It should not reach browser code or a repository.
CRAWLER_IMPLS lists crawlers in order, so "search1api,naive" falls back to the built-in crawler if a page cannot be retrieved.
If you want Search1API as a separate set of agent tools rather than the built-in Web Search, use the MCP server instead.
What people use it for
A self-hosted assistant that answers with current sources and links them.
Internal deployments that need search without sending traffic through a vendor cloud.
Reading a page a user pasted into the conversation, in full.
FAQ
Does this work on LobeHub Cloud?
No. These variables configure a self-hosted deployment. LobeHub Cloud runs its own search infrastructure and does not read them.
What does CRAWLER_IMPLS do?
It lists which crawlers LobeHub may use when it reads a result page, in order. Setting it to search1api,naive uses Search1API first and falls back to the built-in crawler.
Is this the same as installing the MCP server?
No. This fills LobeHub's built-in Web Search slot, so search happens inside that feature. The MCP server instead gives the model a separate set of callable tools. Pick the first if you want LobeHub's own search to work well, the second if you want tools.