u14app/deep-research: a self-hosted deep research app that works with any LLM

The gap u14app/deep-research fills: deep research without a vendor lock

Commercial deep research modes live inside one vendor's product. If your team standardises on Anthropic or a local Ollama instance, or if you want to route tasks through OpenRouter, those modes are not available to you. u14app/deep-research is a web application you host yourself that runs the deep research workflow against whichever model you configure. The README lists Gemini, OpenAI, Anthropic, Deepseek, Atlas Cloud, Grok, Mistral, Azure OpenAI, OpenRouter, Ollama and any OpenAI Compatible LLM as supported providers, and the dependency list confirms this with AI SDK provider packages such as @ai-sdk/google, @ai-sdk/anthropic, @ai-sdk/deepseek, @ai-sdk/mistral, @ai-sdk/xai and @ai-sdk/openai-compatible.

The intended audience is engineers and analysts who already have API keys and want a research interface they can modify. The README describes the output as an in-depth research report generated in roughly two minutes, produced by pairing a Thinking model with a Task model plus web search. The project is not a library you import into an existing pipeline; it is a full application with a UI, a Docker image and an API surface. If you need a research capability embedded in another product, the SSE API and MCP server are the parts to look at first.

How the Thinking and Task model split works

The README does not publish a sequence diagram, but the architecture is visible from the feature list and the package manifest. Research runs against two model roles: a Thinking model and a Task model. The README states this pairing exists to balance depth and speed, and that the research model can be switched. A separate search layer sits in front of the models, with support for Searxng, Tavily, Firecrawl, fastCRW, Exa, Bocha and Brave. That layer matters because it lets a model without native browsing participate in the same workflow.

The README also describes further research: you can refine or adjust content at any stage and re-run research from that stage rather than starting over. Reports are editable in two modes, WYSIWYM and Markdown, with controls for reading level, article length and full-text translation. A knowledge graph can be generated from the report in one click, and uploaded text, Office and PDF files can be turned into a local knowledge base.

Where the data goes is the design decision worth pausing on. The README says all data is processed and stored locally, and that data is stored in the browser. That is a privacy property and a persistence constraint at the same time. Reports and history survive in that browser profile; they do not follow you to another device, and clearing site data removes them. The README does not document an export or backup path for research history, so treat browser storage as the system of record unless you verify otherwise.

Installing u14app/deep-research and running a first research task

The README recommends a one-click deploy to Vercel or Cloudflare for the fastest path, but local installation is documented and is the better way to inspect what the app does. Node.js 18.18.0 or later is recommended, along with pnpm, npm or yarn.

Clone the repository and install dependencies:

git clone https://github.com/u14app/deep-research.git
cd deep-research
pnpm install

Next, create the environment file. The repository ships env.tpl, and the README gives separate copy commands for development and production:

# For Development
cp env.tpl .env.local
# For Production
cp env.tpl .env

Start the development server and open the app:

pnpm dev

The README says to visit http://localhost:3000 in your browser. In the running app, set your LLM API key, and set the LLM API base URL only if your provider needs one. Pick a search engine from the supported list, choose your Thinking and Task models, then submit a research topic. The README's expected result is a report in about two minutes.

If you prefer containers, the repository includes a Dockerfile and a docker-compose.yml. The compose file maps host port 3333 to container port 3000 and reads variables from .env:

services:
  deep-research:
    build:
      context: .
      dockerfile: Dockerfile
    image: deep-research
    container_name: deep-research
    env_file:
      - .env
    ports:
      - "3333:3000"

One configuration detail is easy to miss. The README states that a custom model list works only in proxy mode, and that it is set through an environment variable named NEXT_PUBLIC_MODEL_LIST in the .env file or the environment variables page. Models are separated by commas, and a model can be disabled by prefixing its name with a minus sign.

Where u14app/deep-research stops being the right tool

The browser-local storage model is the sharpest limitation. Research history and knowledge base files live in the browser, so a report produced on a laptop is not visible from a desktop, and nothing in the README describes server-side report storage or a shared team workspace. If your requirement is that a finished report be retrievable by a colleague or an automated process, you are responsible for that yourself.

The second constraint is operational. A deep research run consumes model tokens and search quota, and the app needs both an LLM provider and a search provider to be configured. The README lists the supported search engines but does not document rate limits, cost estimates or retry behaviour, so budgeting is on you. Multi-key payload support is mentioned as a way to improve API response efficiency, which suggests the project expects users to manage several keys rather than a single pooled credential.

The third is maturity of the API surface. The README states that you can use the project as a deep research service through the SSE API or in other AI services through the MCP server, but it does not document authentication, versioning or error semantics for those interfaces. Treat them as integration points to evaluate, not as a stable contract you can build a product on without reading the source.

u14app/deep-research compared with hosted deep research modes

The obvious alternative is a hosted deep research mode from a model vendor. The difference is not report quality, which this material does not let me compare. It is control. A hosted mode picks the model, the search index and the retention policy for you, and you get whatever interface the vendor ships. u14app/deep-research inverts that: you choose the provider, you choose the search backend, and the report stays in your browser.

That inversion has a cost. A hosted mode is available the moment you log in. u14app/deep-research requires a deployment, an API key, a search engine configuration and, if you want to restrict which models appear, a NEXT_PUBLIC_MODEL_LIST entry. You also inherit the maintenance of a Next.js application, which the Dockerfile builds with the standalone output mode and runs via node server.js on port 3000.

A second comparison is against building the workflow yourself on top of an AI SDK. u14app/deep-research already wires the Thinking and Task model split, the search adapters, the editing modes, the knowledge graph and the MCP server. Rebuilding that is weeks of work. The trade is that you accept the project's choices about storage and interface instead of defining your own.

Maintenance, upgrades and the MIT licence in practice

The repository is not archived, and the last push was on 2026-06-18. The most recent release listed is v0.11.0 from 2026-02-10, while package.json carries version 0.11.1, so the version field runs slightly ahead of the tagged releases. The release line shows a long gap between v0.10.0 in September 2025 and v0.11.0 in February 2026, which is worth knowing if you depend on a steady cadence.

Upgrade cost is mostly dependency churn. The app is built on Next.js 15, the AI SDK v4 provider packages and a large Radix UI component set, and the README notes Next.js 15 and Shadcn UI as the foundation. Major version bumps in any of those will require testing the research flow, the editor and the MCP server together. The Dockerfile pins node:18-alpine as the base image, so container users should plan for that base image to age independently of the application code.

The licence is MIT. That permits commercial use, modification and redistribution, and the README explicitly states the project is open-source and freely available for personal and commercial use under the MIT License. MIT does not grant rights to the model providers, search APIs or any hosted deployment platform you use alongside it, and it comes with no warranty. That is a description of the licence text, not legal advice; check the LICENSE file in the repository for the binding terms.

Editorial conclusion

Adopt u14app/deep-research if you want a deep research interface you control, with per-user API keys, local report storage and a choice of model provider. Skip it if you need a hosted service with document-level access controls or a fixed vendor stack. Before committing, verify three things: that your chosen provider and search engine are both configured, that you have set NEXT_PUBLIC_MODEL_LIST in proxy mode if you need to restrict models, and that browser-local storage matches your retention policy.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. u14app/deep-research on GitHub