Self-hosting a Perplexity alternative,
end to end.

Three ways to self-host

“Self-hosted” covers a wide range. At one end you run the app and rent everything it calls; at the other, no query, page or token leaves hardware you control. Most deployments sit in one of three places.

Paths A and B use the same Fireplexity app, so you can start on A and move pieces to B later. Path C is a different app: it searches through a metasearch engine rather than scraping full pages for each query. Our comparison of Fireplexity, Vane and the other alternatives covers that difference. This page is about running them.

What one query actually does

Costs follow from the code, so start there. Fireplexity's whole backend is one file, app/api/fireplexity/search/route.ts. For each question it:

• Makes one call to Firecrawl's /v2/search, asking for web, news and image results with limit: 6 and each result scraped to markdown. With several sources, Firecrawl applies the limit per source type, so that is up to 18 results. Search costs 2 credits per 10 results, so 4 credits, and each scraped page 1 more: 6 for the web results, and up to 6 more if news results are scraped too. 10–16 credits in all.
• Trims every scraped page to about 2,000 characters around the question's keywords, then streams an answer from the model. That is roughly 4,000 tokens in and 800 out.
• Makes a second model call to write five follow-up questions, from the first 500 characters of the answer and the source titles. Roughly 500 tokens in and 100 out. It is easy to miss, and it means every question is two model requests.

There is no database, queue or cache. Two environment variables and a Node process are the whole deployment, which is the reason it is easy to self-host and also the reason it has none of the protection a public service needs (more on that below).

Path A: Fireplexity on managed APIs

This is the repo as shipped, with one fix. Groq retired the Kimi K2 model the code names; openai/gpt-oss-120b is the replacement it recommends, and the code calls the model twice, so the change has to catch both.

$ git clone https://github.com/firecrawl/fireplexity.git && cd fireplexity
$ npm ci
$ cp .env.example .env.local      # set FIRECRAWL_API_KEY and GROQ_API_KEY
$ perl -pi -e 's#moonshotai/kimi-k2-instruct#openai/gpt-oss-120b#g' \
    app/api/fireplexity/search/route.ts
$ npm run build && npm start     # port 3000; put Caddy or nginx in front for TLS

Or push the repo to Vercel, which needs no build configuration. Both work; the choice turns on who is going to use it.

Where to host the app

Function time is not a problem on either Vercel plan. With Fluid compute, which is on by default, functions run for up to 300 seconds on Hobby and up to 800 on Pro. A streamed answer finishes in a fraction of that. The constraint on Hobby is the licence, not the runtime: an internal tool at your company counts as commercial use.

The free tier, and where it stops

Firecrawl's free plan gives 1,000 credits a month, refreshed monthly, with no card. At 10–16 credits a query that is 60 to 100 questions. Groq's free tier allows 30 requests a minute but only 8,000 tokens a minute and 200,000 a day for gpt-oss-120b. One Fireplexity question uses about 5,400 tokens across its two calls, so the free tier manages one question a minute and about 37 a day. A second person asking in the same minute gets a rate-limit error.

For one person, that is a perfectly usable search engine at no cost. For two or more, plan to pay.

Paid, at three usage levels

Credits are sold in plans, not by the query, so real monthly cost moves in steps:

Two things stand out. The team row costs a little more than five $20 Perplexity Pro seats, for a much smaller product, so a team should self-host for control or privacy, not to save money. The product row works out at about 1.5¢ a query. Billing Firecrawl annually ($83 for Standard, $333 for Growth) takes about a sixth off the Firecrawl line. Perplexity's Sonar API, the metered option you would otherwise build on, comes to roughly 1.9–2.7¢ a query for Sonar Pro, so self-hosting is cheaper there, but not by a wide margin.

Path B: Fireplexity, fully local

Moving to Path B means taking Firecrawl and Groq out of the loop. Both are possible, neither is a setting, and each costs you something.

1. Run Firecrawl yourself

Firecrawl's engine is open source under AGPL-3.0. Running it unmodified for yourself is straightforward. If you change it and offer it to others over a network, the AGPL requires you to publish your changes. Fireplexity itself is MIT, so its licence does not change.

The repo's Docker Compose file starts seven services: the API and its workers, a Playwright browser service, Redis, RabbitMQ, Postgres and FoundationDB (with a separate init container). Only port 3002 is exposed. The file caps the API at 4 CPUs and 8 GB and Playwright at 2 CPUs and 4 GB. Firecrawl says those caps are not tested minimums and publishes no recommended host size. Our estimate is a 16 GB machine such as Hetzner's CX43 at €15.99 a month, and you should check it against your own load.

What you lose is the part that makes scraping work on hard sites. The self-hosted docs say Fire-engine is not included, so pages load through the bundled Playwright with a basic fetch fallback. Screenshots, page actions and advanced anti-bot handling depend on Fire-engine. Expect sites behind aggressive bot protection to come back empty.

Search works differently too. The self-hosted /search tries Fire-engine if it is configured, then SearXNG if you set SEARXNG_ENDPOINT, and otherwise falls back to DuckDuckGo. If a search errors it returns an empty list, not an error. Fireplexity then answers from no sources, and nothing tells you why. Run your own SearXNG and set the endpoint (the SearXNG section below covers the catch). Fireplexity also asks for news and image results. Check what your self-hosted search returns for those before you rely on them.

Then point Fireplexity at it. The Firecrawl address is hardcoded, and the route refuses to run without a key, so give it a placeholder:

- const searchResponse = await fetch('https://api.firecrawl.dev/v2/search', {
+ const searchResponse = await fetch(`${process.env.FIRECRAWL_API_URL}/v2/search`, {

# .env.local
FIRECRAWL_API_URL=http://localhost:3002
FIRECRAWL_API_KEY=local      # any value; the route only checks that one is set

2. Serve the model yourself

Ollama exposes an OpenAI-compatible API on port 11434, so the change is a provider swap. Keeping the variable name means the two model calls further down work unchanged:

- import { createGroq } from '@ai-sdk/groq'
+ import { createOpenAICompatible } from '@ai-sdk/openai-compatible'

- const groq = createGroq({ apiKey: groqApiKey })
+ const groq = createOpenAICompatible({ name: 'ollama', baseURL: 'http://localhost:11434/v1' })

  // and in both calls: groq('gpt-oss:20b')
  // GROQ_API_KEY still has to be set to something: the route checks for it

The model is the real cost. Ollama's gpt-oss:20b is a 14 GB download that runs in about 16 GB of memory. gpt-oss:120b is 65 GB and wants a single 80 GB GPU. On 16–24 GB consumer cards such as an RTX 4080 or 4090, community benchmarks put the 20b model at roughly 60–140 tokens a second, depending on context length and drivers. That is slower than Groq, but fine for an 800-token answer. The 20b also writes weaker answers than the 120b Path A uses, and that shows on questions that need several sources combined.

Path C: Vane with a local model

If what you need is a private Perplexity alternative to use, rather than code to build on, Vane is less work than Path B. It is one container with SearXNG bundled, MIT licensed, and at about 37,000 GitHub stars it is the most widely used project of its kind. The repository moved from Perplexica to ItzCrazyKns/Vane, and the old address redirects.

$ docker run -d -p 3000:3000 -v vane-data:/home/vane/data \
    --name vane itzcrazykns1337/vane:latest
# Linux, with Ollama on the host: add --add-host=host.docker.internal:host-gateway
# and use http://host.docker.internal:11434 as the Ollama URL in Vane's settings

Its README names Ollama, OpenAI, Anthropic, Gemini and Groq as providers. That gives Path C a cheap middle option: Vane on an €8.49 VPS with a Groq key. Groq is the only metered part, since SearXNG is free, so the bill is the server plus fractions of a cent per query. No other option here is cheaper for something more than one person can use. For an existing SearXNG instance there is a slim image that takes SEARXNG_API_URL. That instance needs the JSON output format and the Wolfram Alpha engine enabled.

The catch with SearXNG

Paths B and C both depend on SearXNG, and SearXNG does not have its own index. It forwards your query to Google, Bing, DuckDuckGo and others from your server's IP address. A single data-centre IP sending steady automated traffic gets blocked, and SearXNG's own defaults assume it. When an engine returns a CAPTCHA, SearXNG suspends that engine for a day. For a Google reCAPTCHA it is seven days, for a Cloudflare challenge fifteen, and for a 429 an hour.

In practice, a self-hosted answer engine can get worse over a week without telling you. Google drops out, then another engine, and answers start coming from whichever engines are still responding. Three things help:

• Turn on the limiter (server.limiter: true, backed by Valkey) so bots hitting your instance don't get your IP banned upstream. It reads client IPs from X-Forwarded-For, so set up your reverse proxy properly or every user looks like the same person.
• Enable JSON output. It is off in the default settings.yml, and both Firecrawl and Vane need it.
• Watch the engine stats. SearXNG reports suspended engines. Check them weekly rather than waiting for users to notice answers getting thinner.

Path A doesn't leave this to you. Keeping search working is Firecrawl's job there, and that is a large part of what the credits pay for.

Before you put it on the internet

Every path above gives you an app that does no access control. Fireplexity in particular was published as a demo. If you deploy it publicly as it is, strangers' queries run on your API keys. The minimum before a public URL:

• Put it behind a login. For an internal tool, your SSO proxy or Cloudflare Access in front of the whole app is less work than adding auth to the code.
• Rate-limit the search route per user or IP. Upstash's free Redis tier (500,000 commands a month) is enough for @upstash/ratelimit at small scale.
• Remove the key pass-through. The route uses a firecrawlApiKey from the request body if one is sent. It is harmless, but it is an input you don't need, and a public deployment shouldn't accept it.
• Cap spend upstream. On Firecrawl the free plan stops at its limit and pay-as-you-go lets you set a monthly ceiling. Set one. A crawler looping on your search box costs real money in a few hours.
• Treat scraped pages as untrusted input. Page text goes straight into the prompt. A page can contain instructions aimed at your model, and the bigger risk is that it quietly changes the answer. Remember this before you give the model any tools.

And keep checking answers. Self-hosting changes who runs the system, not whether the citations are right. The failure modes in our guide to checking AI search citations apply to every path here.

So which path

Path B is for the narrower case where the code has to be Fireplexity's and nothing can leave the network: a regulated environment, a corpus you can't send to a third party, or a product whose customers require it. It is the most work and, unless you own the hardware, the most expensive. When it is a hard requirement, though, none of the other options here meet it.

Common questions