Deep Research Web UI: a self-hosted research agent that shows its citations

What Deep Research Web UI does that a chat window does not

A chat assistant answers from what it already knows. Deep Research Web UI is built around the opposite assumption: the answer has to be retrieved, and the retrieval has to be visible. The README describes it as turning a research question into a cited report by planning searches, browsing the web and verifying findings against real source pages. Every claim in the finished report carries a numbered citation, and clicking a [1]-style marker opens a panel with the source, retrieval time and a matched excerpt.

The audience is narrow but real. It suits an analyst or engineer who wants a research run they can audit rather than a paragraph they have to trust. It also suits a small team that wants one shared deployment with keys configured server-side, so colleagues do not each paste an API key into a settings dialog. The README states that history is stored in the browser, which tells you the intended unit of use is one person and one browser profile, not a shared organisational archive.

The research loop: queries, filters, page reads and a token budget

The mechanism is a loop with a budget attached. A run separates the query text from time and source filters, checks result relevance, and retries once with a revised query when the evidence is insufficient. That retry limit is a design decision worth noting: it bounds cost, but it also means a topic with poor search coverage fails after a single correction attempt rather than grinding away.

When search snippets are not enough, the agent fetches full source pages to extract verbatim evidence, and the README says this shares a token and request budget across the whole research run. So full-page reading competes with everything else for the same allowance. A run that reads many pages will have less room for follow-up work.

The UI reflects this with a tree structure showing the research process, and the app streams model responses in real time. Under the hood the package.json points to the Vercel AI SDK (@ai-sdk/openai, @ai-sdk/deepseek, @openrouter/ai-sdk-provider), @tavily/core and @mendable/firecrawl-js, with @vue-flow/core and @dagrejs/dagre handling the search tree layout. The README makes a deliberate compatibility choice here: it uses plain prompts rather than Structured Outputs, so providers that have not implemented the newest OpenAI features still work. That trades some output reliability for a wider provider list.

Installing Deep Research Web UI with Docker and running a first follow-up

The fastest path is the published image in Server Mode, where keys live in environment variables and users never see them. The README gives this command, which maps port 3000 and sets the AI and search keys along with the provider and model names.

docker run -p 3000:3000 \
  -e NUXT_PUBLIC_SERVER_MODE=true \
  -e NUXT_AI_API_KEY=your-ai-api-key \
  -e NUXT_WEB_SEARCH_API_KEY=your-search-api-key \
  -e NUXT_PUBLIC_AI_PROVIDER=openai-compatible \
  -e NUXT_PUBLIC_AI_MODEL=gpt-4o-mini \
  -e NUXT_PUBLIC_WEB_SEARCH_PROVIDER=tavily \
  anotia/deep-research-web:latest

If you prefer a file, the README suggests copying .env.example to .env, editing it, and passing it with --env-file. The example file documents the keys you are most likely to touch: NUXT_PUBLIC_AI_CONTEXT_SIZE defaults to 128000, NUXT_PUBLIC_WEB_SEARCH_CONCURRENCY_LIMIT defaults to 2 with a recommended range of 1 to 5, and NUXT_PUBLIC_WEB_SEARCH_SEARCH_LANGUAGE accepts en, zh or nl.

cp .env.example .env
docker run -p 3000:3000 --env-file .env anotia/deep-research-web:latest

Open http://localhost:3000, submit a question, and wait for the report. Then click a citation marker, or the Inspect evidence and follow up button, and enter something like the README's own example: "Find the latest official pricing and confirm the eligibility terms." A follow-up searches at most two directions in one round and rewrites only the Markdown blocks citing that finding. On success the result is saved as a separate history entry, so the original report stays intact.

For a static deployment instead, the README points at EdgeOne Pages or pnpm generate, with users entering their own keys in the browser.

Where the design bites: browser history, static hosting and unstated licensing

The most concrete limitation is stated plainly in the README: history is stored in your browser, and you should export research you want to keep. Clear a browser profile or move to another machine and the trail is gone. There is no server-side history store described, so a shared deployment still gives each user an isolated, fragile archive.

Server Mode and static hosting are mutually exclusive. The README says Server Mode requires an SSR/Nitro runtime such as the Docker image and is not available in purely static deployments. If your constraint is a static host with no Node process, you are pushed back to Client Mode, where every user supplies their own keys. That is a reasonable privacy property and an awkward onboarding story for a team.

The README also adds a caution about its own evidence panel: a matched excerpt does not by itself prove the finding, and search summaries and page text are labeled separately, so you still have to read the excerpt in context. The tool narrows the verification work rather than removing it.

Licensing is the sharpest gap. The repository metadata carries no licence identifier, and the README does not state one. For a self-hosted deployment inside a company, that is a question to settle before rollout, not after.

How it compares with running a research agent from a Python script

The obvious alternative is a Python agent you assemble yourself, which is what the search phrase "deep research python github" points at. The difference is where the work lives. A Python script gives you the loop as code: you choose the search client, the scraping library, the model call and the stopping rule, and you can log whatever you want. Deep Research Web UI gives you that loop as a running application, with a tree view, streaming output, PDF and Markdown export, and an evidence panel already wired to the citations.

What you give up with the script is the inspection surface. Rebuilding clickable citations that map back to matched excerpts, plus follow-up rounds that rewrite only the affected Markdown blocks, is real work. What you gain is control over the budget and the failure path, which the web UI exposes only through environment variables like NUXT_PUBLIC_WEB_SEARCH_CONCURRENCY_LIMIT. If your research needs custom post-processing, a scheduled pipeline, or a store of past runs, the script wins. If a person needs to read a report and check the sources, the UI is the shorter path.

A second reference point is the OpenAI deep research mode, which people also search for. That is a hosted product; this project is the self-hosted counterpart, and the README's provider list (OpenAI compatible, DeepSeek, OpenRouter, Ollama, LiteLLM and others) is the evidence that it is meant to run against whatever model you already pay for.

Maintenance, upgrades and what the release history shows

The repository is not archived, and its last push was on 2026-09-08. The release history is uneven: v1.1.9 on 2025-04-06, v1.2.0 on 2025-07-23, then v1.2.1 on 2026-09-07. That gap between minor releases suggests the project moves in bursts rather than on a schedule, so pinning a Docker tag rather than tracking latest is the safer default for a production deployment.

The upgrade surface is mostly the environment variables and the provider integrations. Because the app depends on @ai-sdk packages, @tavily/core and @mendable/firecrawl-js, provider API changes can force a version bump even when the UI is unchanged. A rebuild from source goes through pnpm build:optimize, and the Dockerfile sets NODE_OPTIONS to --max_old_space_size=2048 for the build stage, which tells you the build is memory-hungry relative to a small Alpine container.

On licensing, no licence identifier appears for the repository or the container image. That is a fact about the project, not a legal opinion: if you need a known licence before adopting, this page cannot supply one.

Editorial conclusion

Adopt Deep Research Web UI if you want a browser-visible research trail and can supply keys for an OpenAI-compatible model plus Tavily, Firecrawl, fastCRW or Google PSE. Skip it if you need a supported licence or a purely static deployment with server-side keys, since Server Mode requires an SSR/Nitro runtime. Before deploying, confirm the repository licence and check that your chosen search provider has credits, because the README gives no fallback when search fails.

Frequently asked questions

Official sources

1. AnotiaWang/deep-research-web-ui on GitHub
2. Issues
3. Project website
4. README
5. Releases