finance puts a search API behind a chat interface for financial work

The data is the hard part, so the search API is the backbone

The pitch in the repository description is that this is the world's most powerful open-source financial AI assistant, with institutional-grade financial data, complex analyses and visualizations through natural conversation. The blunt version of that claim is in the README header: bloomberg-grade data behind a chat interface, open sourced, with the backend being one search API. That search API is Valyu, and the data it reaches is what separates this from a chat wrapper over a general web search. The listed sources are live global market data with real-time prices, volumes and technical indicators across 50 or more global exchanges, an SEC filings index covering 10-Ks, 10-Qs, 8-Ks, proxy statements and insider trading reports, a patent database across jurisdictions, academic research including arXiv papers and Wiley finance journals, and web search for real-time news, social sentiment and market analysis. The framing sentence in the README is the one worth remembering. Your AI's search is only as good as the data it's searching over. The tools built on top of that data are the reason this is more than a search box. Financial statements with automatic calculations, insider and institutional transaction tracking, SEC filing analysis, real-time and historical prices, news with market impact assessment, Python code execution for financial models and ML algorithms, interactive charts, and export to share an analysis. The audience is a financial analyst or researcher who wants to interrogate market data in plain language, and a developer who wants the same stack to run on their own machine.

Self-hosted mode replaces the hosted stack with SQLite and a fake login

There are two ways to run the application, and the second one is what the project recommends. Setting NEXT_PUBLIC_APP_MODE to self-hosted switches the app into a mode with no external dependencies beyond the two core APIs, Valyu and Daytona. The README lists what that buys: local development with no Supabase setup, offline work with all data stored locally in SQLite, testing features with unlimited queries and no billing, privacy through local Ollama models with no cloud LLM needed, and quick prototyping with no authentication or rate limits. The mechanics are concrete. A local SQLite database at /.local-data/dev.db is created automatically on first run, and it stores chat sessions, messages, charts and CSVs with a schema matching the production Supabase tables, so it can be inspected with the sqlite3 command line. Authentication is mocked, with an automatic login as dev@localhost, so there is no sign-up and no sign-in, and the account gets the unlimited tier with all features. There are no rate limits, no usage tracking and no billing integration. That schema parity is the part with lasting value. Because the local database has the same shape as the hosted one, the application code does not need a separate data path for development, and a developer can query the local file directly. The consequence to keep in mind is that the data access itself is not local. Self-hosted mode removes the account layer and the billing layer, not the paid search API behind the queries.

Two paid services still sit behind the free tier

Self-hosted mode is free in the sense that it has no billing integration, but it is not free in the sense that it needs no credentials. The prerequisites list Node.js 18 or later, pnpm, a Valyu API key from platform.valyu.ai, a Daytona API key from app.daytona.io for secure sandboxed Python code execution, and optionally Ollama or LM Studio installed. Daytona is the more interesting of the two. The advanced analytics feature is described as executing Python code in secure Daytona sandboxes for ML models, backtesting and custom analysis, and the Daytona SDK appears in the dependency list. So the tool calling that runs a financial model is not running on your machine, it runs in a remote sandbox, which is the only sensible way to run arbitrary model code against a server-side API without handing a shell to the browser. The cost of that design is a network round trip for every analysis and a second paid service to manage. The local model path is the part that removes that dependency for the language model. The LLM selection is ordered: Ollama models are used first if installed, unlimited and free, LM Studio models are the alternative local option with a GUI, and OpenAI is the fallback when no local models are available. The Ollama provider appears in the dependencies as ollama-ai-provider-v2, alongside the OpenAI provider from the AI SDK. So there are three costs to think about: the Valyu search API, the Daytona sandbox, and whichever model you point the chat at.

Running it locally: clone, install, set the environment, start the server

The quick start is five steps and the environment file is where most of the work goes.

git clone https://github.com/yorkeccak/finance.git
cd finance

pnpm install

Then a .env.local file in the root directory, and the .env.example template in the repository explains what each block does. The required part is small.

# Enable Self-Hosted Mode (No Supabase, No Auth, No Billing)
NEXT_PUBLIC_APP_MODE=self-hosted

# Valyu API Configuration (Required)
VALYU_API_KEY=your-valyu-api-key

# Daytona Configuration (Required for Python execution)
DAYTONA_API_KEY=your-daytona-api-key
DAYTONA_API_URL=https://api.daytona.io  # Optional
DAYTONA_TARGET=latest  # Optional

The local model and fallback keys are optional.

# Local LLM Configuration (Optional - for unlimited, private queries)
OLLAMA_BASE_URL=http://localhost:11434   # Default Ollama URL
LMSTUDIO_BASE_URL=http://localhost:1234  # Default LM Studio URL

# OpenAI Configuration (Optional - fallback if local models unavailable)
OPENAI_API_KEY=your-openai-api-key

The template also carries NEXT_PUBLIC_APP_URL, with http://localhost:3000 for local development, and a note that .env.local must not be committed to version control. Then the dev server and the browser.

pnpm dev

The script runs next dev with turbopack, and the application is at http://localhost:3000. The README says you are automatically logged in as dev@localhost with no sign-up required, which is the mock authentication in action.

The container image installs Chromium because the charts are rendered by a browser

The Dockerfile shows a detail that explains several dependencies in package.json.

FROM node:20-slim

# Install Chromium and dependencies for Puppeteer
ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium

# Don't download Chromium during npm install (we installed it above)
ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true

The image installs Chromium with its shared library dependencies, then points Puppeteer at the system binary through PUPPETEER_EXECUTABLE_PATH and skips the Chromium download that Puppeteer would otherwise perform during npm install. Puppeteer is in the dependency list, along with html2canvas and html-to-image. Those three together explain how the interactive charts work. The application renders the chart markup in a headless browser, captures it as an image, and can then export it, which is also why jspdf is a dependency for producing a PDF. @sparticuz/chromium is present as the serverless-friendly build of the same browser. The rest of the image is a standard Next.js production build: copy the package files, run npm ci, copy the application code, run npm run build, expose port 3000 and start with npm start. The visual stack in the package is worth noting for anyone extending the app: Radix UI primitives for the component layer, Tailwind with the typography plugin, shadcn style configuration in components.json, lucide-react and react-icons for icons, framer-motion and motion for animation, KaTeX for formula rendering, and drizzle-orm with better-sqlite3 for the local database.

MIT licensed, no tagged releases, and a hosted demo alongside the repo

The licence is MIT, with the LICENSE file at the root of the repository and a licence badge in the header. That is the easy case for adoption. An MIT licence lets you run this commercially, modify it and redistribute it, with only the obligation to keep the copyright notice. For an application that talks to two commercial APIs and stores research results, that permissiveness is what makes a fork practical. What is not included is a guarantee about the data. The README links to a comparison of Valyu against other search APIs and points at independent benchmarks, but the repository itself publishes no benchmark of its own, so the claim that the underlying search is stronger than an alternative is a claim about Valyu rather than something this codebase demonstrates. The repository has no GitHub releases. The last push was on 2026-09-09 and the repository is not archived, so work continues, but there is no tagged version to pin to. The package.json version is 0.1.0 and the package is marked private, which is consistent with a project that expects to be run rather than consumed as a library. Alongside the code there is a hosted demo at finance.valyu.ai, which is the fastest way to see whether the search returns what you need before you spend a Valyu credit on it.

Editorial conclusion

Adopt finance if you want a chat interface over financial filings, market data and research for internal analysis, and you are ready to hold Valyu and Daytona API keys and to run the Next.js app yourself. Do not adopt it if you need the financial data itself to be free, because the search API is the paid dependency in every mode, including self-hosted. Before you rely on it, check which LLM the app actually selects in your setup, since Ollama and LM Studio are used before the OpenAI fallback, and pin a commit rather than a tag, since the repository publishes no releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. yorkeccak/finance on GitHub