OpenTerminal assembles a trading desk from free public market endpoints

A dashboard that treats data providers as infrastructure

Most retail finance tools hide where their numbers come from. OpenTerminal, at version 0.2.0, puts the plumbing on the front page: a data source table naming every provider, primary and fallback, for every widget. The application itself is a Next.js and TypeScript front end over an Express API, MIT licensed, self-hosted, with quotes and indexes refreshing about every second.

The problem it solves is access, not alpha. Professional terminals price their feeds at four figures a month, freemium sites rate-limit the useful parts, and single-source hobby dashboards die when one endpoint changes. OpenTerminal's answer is redundancy over free endpoints plus local ownership: no signup, no keys, no demo tier, and a workspace that runs on your machine.

The fallback table is the real spec

Read the table and you know exactly what the app is. Stock quotes and historical candles come from Nasdaq's public APIs with Yahoo Finance and then Stooq behind them. The full-market screener, the heatmap and fundamentals come from TradingView's scanner API with no fallback at all. News aggregates Yahoo Finance RSS with Google News RSS behind it, and crypto quotes use CoinGecko with Binance's public API as backup, while crypto candles are Binance klines only.

Macro data comes from FRED, the economic calendar schedule from Forex Factory, with actual printed values for Fed, ECB, CPI and NFP releases pulled from FRED, and earnings estimates and history from TradingView and Nasdaq. Cached responses use a stale-while-revalidate strategy, so a provider outage fades instead of blanking the UI. Each provider is a module in server/src/providers, which makes the table honest: you can read the code behind every row.

Two ways to boot it

The root package.json defines server and web workspaces and wires both dev servers through concurrently:

npm install
npm run dev

That is the development path, with the web UI and API expected on ports 3000 and 4000 respectively, per the compose file. The containerized path reads the same ports from docker-compose.yml:

docker compose up

The compose file binds both services to 127.0.0.1, mounts a terminal-data volume at /app/data, and accepts an optional ANTHROPIC_API_KEY used only by the AI assistant widget; leave it unset and the rest of the terminal works. If API_KEY is unset, a fresh key is generated per container and stored at /app/data/.api-key, which the web service reads through API_KEY_FILE.

Inside the workspace

The layout is a react-grid-layout canvas you rearrange and the app remembers. Cmd+K searches stocks, ETFs and crypto. Charts run on TradingView's lightweight-charts: candlesticks, bars, line and area across eight timeframes, with SMA, EMA, VWAP, Bollinger Bands, RSI and MACD and a hover legend that lists OHLC, volume and every active indicator at the cursor.

Around the chart: a quote panel with fundamentals down to beta and shares outstanding, a deduplicated news feed with per-symbol filtering, a sortable full-market screener, a sector treemap sized by market cap and colored by daily change, an options chain with in-the-money highlighting, and a crypto board with dominance figures and seven-day sparklines. The portfolio tracker records trades and computes realized and unrealized P&L in SQLite. Version 0.2.0 swapped Time and Sales for a two-tab calendar covering economic releases and per-symbol earnings history with next-day price moves.

Indicative prices are the price of free

The README's warning block says it directly: these are public endpoints, not officially licensed feeds, and prices should be treated as delayed and indicative, not execution-grade. Every limit in the project follows from that sentence. Several rows in the source table have no fallback, fundamentals, screener, heatmap, crypto candles, macro series and calendar actuals each hang on one provider, so a format change at TradingView or FRED reaches the UI directly.

Some sources are described as reverse-engineered but widely used, which is a polite way of saying they can change without warning. The AI assistant needs your own ANTHROPIC_API_KEY and stays optional. The portfolio persists locally in SQLite with no sync, so the terminal is single-machine by design. None of this is a flaw against the project's own goals; it is the honest boundary of building on free data, and the README draws it rather than hiding it.

What to stack it against

Three alternatives define the edges. A professional terminal sells licensed feeds, support and execution integration, and costs four figures a month; if you trade size, that is the correct product and OpenTerminal is not trying to be it. Freemium web dashboards, TradingView's site being the obvious case and also one of OpenTerminal's own providers, are zero-maintenance and rate-limited, with the good screens behind tiers.

The third alternative is building your own single-source dashboard, which is what OpenTerminal would look like before the fallback chains, the provider modules and the widget set. Its niche is the developer-investor who wants that layer done, readable, and local, and who accepts maintenance when a public endpoint shifts. The moment your use case needs guaranteed data or execution, every column of this comparison flips.

Defaults that protect the operator

The compose file documents a security posture worth keeping. Both services publish to 127.0.0.1 only, and the inline comments state that wider exposure requires rebinding plus an explicit API_KEY. TRUST_PROXY is deliberately unset unless you front the stack with a trusted reverse proxy, because a caller could forge X-Forwarded-For to slip past the /api/ai rate limit. WEB_ORIGIN defaults to http://localhost:3000.

These are the settings a hurried operator weakens first, which is presumably why the comments argue against it in place. The pattern generalizes: the project treats its own configuration as documentation, from the provider table down to port bindings, and reading those defaults tells you more about the author's intent than any feature list.

Editorial conclusion

OpenTerminal fits a developer who watches markets, wants a dense local workspace, and accepts indicative numbers from public endpoints with their occasional breakage. It is the wrong tool for execution-grade feeds, supported fundamentals, or anything mobile; a paid terminal or a freemium web dashboard covers those. First verification after boot: leave it running for ten minutes, watch the change flashes and the calendar tabs, then open server/src/providers and confirm the sources you care most about have the fallbacks you expect.

Frequently asked questions

Official sources

1. ErTasselli/OpenTerminal on GitHub
2. Issues
3. License: MIT
4. README
5. Releases